Skip to content

Conversation

@liyuqian
Copy link
Contributor

@liyuqian liyuqian commented Apr 29, 2020

Description

We add clipBehavior to

  1. Flex
  2. FittedBox
  3. UnconstrainedBox
  4. Wrap
  5. Stack
  6. EditableText
  7. ListWheelScrollView
  8. SingleChildScrollView
  9. NestedScrollView
  10. ShrinkWrappingViewport

Eventually, the first 4 of them will be default to Clip.none while the remaining 6 of them are default to Clip.hardEdge.

In the current PR, all of them are still default to Clip.hardEdge to not break some Google usages. Once we've updated the code inside Google, we'll update the clipBehavior.

Related Issues

This is a continuation of #18057, and this fixes #21830

Tests

Unit tests added to each modified widget and render object.

Breaking Change

@liyuqian liyuqian added the c: API break Backwards-incompatible API changes label Apr 29, 2020
@liyuqian liyuqian requested review from Hixie and goderbauer April 29, 2020 18:41
@fluttergithubbot fluttergithubbot added the framework flutter/packages/flutter repository. See also f: labels. label Apr 29, 2020
@skia-gold
Copy link

Gold has detected one or more untriaged digests on patchset 9.
Please triage them at https://flutter-gold.skia.org/search?issue=55977.

@liyuqian liyuqian force-pushed the clip branch 2 times, most recently from 6223a26 to 9b1569d Compare April 29, 2020 19:01
@fluttergithubbot
Copy link
Contributor

Golden file changes have been found for this pull request. Click here to view and triage (e.g. because this is an intentional change).

Changes to golden files are considered breaking changes, so consult Handling Breaking Changes to proceed. While there are exceptions to this rule, if this patch modifies an existing golden file, it is probably not an exception. Only new golden file tests, or downstream changes like those from skia updates are considered non-breaking.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Changes reported for pull request #55977 at sha 9b1569df6c88349372787e7df5597b8d83582942

@fluttergithubbot fluttergithubbot added the will affect goldens Changes to golden files label Apr 29, 2020
@goderbauer
Copy link
Member

This appears to be breaking some tests (see cirrus).

@liyuqian
Copy link
Contributor Author

@goderbauer : thanks! Just fixed them.

@skia-gold
Copy link

Gold has detected one or more untriaged digests on patchset 10.
Please triage them at https://flutter-gold.skia.org/search?issue=55977.

@fluttergithubbot
Copy link
Contributor

Golden file changes are available for triage from new commit, Click here to view.

Changes reported for pull request #55977 at sha dc4ed1291ab026257428c0d631709e60802b3f84

@fluttergithubbot
Copy link
Contributor

Golden file changes are available for triage from new commit, Click here to view.

Changes reported for pull request #55977 at sha c2e2ad91876e292dfc598b71e8226569b34a2bfe

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering whether we really need this class. The renderobjects in question could just use the mixin directly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added ClippableRenderBox for SingleChildScrollView respects clipBehavior test: https://github.com/flutter/flutter/pull/55977/files#diff-dc4070bb6bd99e8491da558051581285R45. Its render object _RenderSingleChildViewport is private so I have to create a parent render object class for testing... I'd love to remove ClippableRenderBox if there's another way to test it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you re-write the test as follows:

    final dynamic renderObject = tester.renderObject.where((RenderObject o) => o.runtimeType.toString() == '_RenderSingleChildViewport');
    expect(renderObject.clipBehavior, equals(Clip.hardEdge));

Note the cast to dynamic which should allow you to call whatever you want on it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we definitely shouldn't add to our public API surface just to work around Dart testability limitations. Better to just go fix Dart.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's strange that there are two flags here to control whether to clip or not. clipToSize and clipBehavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd love to remove clipToSize and overflow! My previous concern was how it affects our breaking change migration. My old post https://groups.google.com/g/flutter-dev/c/XMHE0XdsXxI/m/nonrNQpbBAAJ seems to still cover this PR if I don't remove clipToSize and overflow. But after a second thought, I think it's better to remove them immediately so the old code would result in compile errors instead of runtime errors saying that clipToSize/overflow is incompatible with the default clipBehavior. My next patch will remove them, and I'll write a new breaking change announcement with migration suggestions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, it's strange that there are two flags to control clipping.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will remove.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ClippableRenderBox claims that the default is none.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean that the auto-generated API doc for RenderViewportBase will say that the default is Clip.none instead of Clip.hardEdge because ClippableRenderBox defaults it to Clip.none? Some ClippableRenderBox subclasses default to Clip.none while some default to Clip.hardEdge. I'd like to know if there's a way to specify/modify in each subclass.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think dartdoc provides any affordances for this, but I am no dartdocs expert.

But the auto-generated documentation for all classes that extend ClippableRenderBox or mixin the mixin and set the default to something other then "none" will have incorrect documentation with the current approach.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't bother with the mixin. Just inline the duplicate code. It's not complex logic, and it might not be identical everywhere (as shown by the different defaults, for one).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the constructor its set to hardEdge

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(This comment applies to some other places in the PR as well)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! Forget to change after copy/paste... Fixed for all 5 widgets now.

@goderbauer
Copy link
Member

Can you please fill out the PR template. The section about breaking changes would be most relevant.

What's the plan to make this breaking change? Will this not break many customers in unsuspecting ways?

Copy link
Contributor Author

@liyuqian liyuqian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filled out the PR template with the breaking change section. I'll come up with a design doc with the new template, contact the DevRel team, and send out an updated migration guide (the old one is https://groups.google.com/g/flutter-dev/c/XMHE0XdsXxI/m/nonrNQpbBAAJ) to flutter-dev or flutter-announcement.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added ClippableRenderBox for SingleChildScrollView respects clipBehavior test: https://github.com/flutter/flutter/pull/55977/files#diff-dc4070bb6bd99e8491da558051581285R45. Its render object _RenderSingleChildViewport is private so I have to create a parent render object class for testing... I'd love to remove ClippableRenderBox if there's another way to test it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd love to remove clipToSize and overflow! My previous concern was how it affects our breaking change migration. My old post https://groups.google.com/g/flutter-dev/c/XMHE0XdsXxI/m/nonrNQpbBAAJ seems to still cover this PR if I don't remove clipToSize and overflow. But after a second thought, I think it's better to remove them immediately so the old code would result in compile errors instead of runtime errors saying that clipToSize/overflow is incompatible with the default clipBehavior. My next patch will remove them, and I'll write a new breaking change announcement with migration suggestions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will remove.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean that the auto-generated API doc for RenderViewportBase will say that the default is Clip.none instead of Clip.hardEdge because ClippableRenderBox defaults it to Clip.none? Some ClippableRenderBox subclasses default to Clip.none while some default to Clip.hardEdge. I'd like to know if there's a way to specify/modify in each subclass.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! Forget to change after copy/paste... Fixed for all 5 widgets now.

@skia-gold
Copy link

Gold has detected one or more untriaged digests on patchset 12.
Please triage them at https://flutter-gold.skia.org/search?issue=55977.

1 similar comment
@skia-gold
Copy link

Gold has detected one or more untriaged digests on patchset 12.
Please triage them at https://flutter-gold.skia.org/search?issue=55977.

@fluttergithubbot
Copy link
Contributor

Golden file changes are available for triage from new commit, Click here to view.

Changes reported for pull request #55977 at sha 89c34d5e5e0838c47963bcdf9989d231326e327a

@skia-gold
Copy link

Gold has detected one or more untriaged digests on patchset 13.
Please triage them at https://flutter-gold.skia.org/search?issue=55977.

@fluttergithubbot
Copy link
Contributor

Golden file changes are available for triage from new commit, Click here to view.

Changes reported for pull request #55977 at sha 8367ad27807951a25080410411a91bf8c124367f

liyuqian added a commit to liyuqian/website that referenced this pull request May 7, 2020
sfshaza2 pushed a commit to flutter/website that referenced this pull request May 7, 2020
@goderbauer
Copy link
Member

Does this change cause any trouble when rolled into google3?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this doesn't belong in object.dart. It's way too specific.

Is there any reason we wouldn't just duplicate this code everywhere rather than using mixins? Mixins aren't free (they add more classes to our class hierarchy, etc). I don't know how well they interact with tree shaking either. We don't have any trouble duplicating other fields. Why is this one special?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That will also fix the documentation trouble I mentioned in the other comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the Mixin. BTW, I'm curious if we had any experiments on the Mixin's impact on app size? For example, what's the Flutter gallery's size difference between (1) copying a small piece of code dozens of times and (2) defining a small mixin which is reused dozens of times?

@liyuqian liyuqian merged commit cd593da into flutter:master May 29, 2020
mehmetf added a commit that referenced this pull request May 31, 2020
mehmetf added a commit that referenced this pull request May 31, 2020
liyuqian added a commit to liyuqian/flutter that referenced this pull request Jun 17, 2020
liyuqian added a commit that referenced this pull request Jun 17, 2020
#59364)

* Revert "Revert "Add clipBehavior to widgets with clipRect (#55977)" (#58344)"

This reverts commit 1d395c5.

* Add missed Overflow
zljj0818 pushed a commit to zljj0818/flutter that referenced this pull request Jun 22, 2020
…r#55977" (flutter#59364)

* Revert "Revert "Add clipBehavior to widgets with clipRect (flutter#55977)" (flutter#58344)"

This reverts commit 1d395c5.

* Add missed Overflow
@urusaich
Copy link

urusaich commented Aug 11, 2020

Good feature.
But what about ScrollView and its children (ListView)?

@liyuqian
Copy link
Contributor Author

@urusai88 : they're being added in #63147

mingwandroid pushed a commit to mingwandroid/flutter that referenced this pull request Sep 6, 2020
…r#55977" (flutter#59364)

* Revert "Revert "Add clipBehavior to widgets with clipRect (flutter#55977)" (flutter#58344)"

This reverts commit 1d395c5.

* Add missed Overflow
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

c: API break Backwards-incompatible API changes c: contributor-productivity Team-specific productivity, code health, technical debt. f: material design flutter/packages/flutter/material repository. framework flutter/packages/flutter repository. See also f: labels. will affect goldens Changes to golden files

Projects

None yet

Development

Successfully merging this pull request may close these issues.

clipBehavior is not sent to pushClipRect/ClipRectLayer in some places

9 participants