Control paint order / z-order of slivers #164818
Conversation
|
This is a fresh copy of #163511, in hopes of getting the infra for running Google tests on PRs to successfully run this one; see #163511 (comment) . |
|
Well: (That's the info that's provided on the GitHub check. I appreciate that it does give that information.) |
|
Yes, can confirm now, this is an issue not specific to this PR and is currently being worked on. Thanks for your patience @gnprice! |
|
I think this is resolved now, rebasing to give it another go! |
09e5816 to
e252330
Compare
|
@Piinks Google testing is marked as failed here but the CL seemed to have no failures on it? Maybe I'm reading something wrong. |
|
Yes, the Google testing shard has been going experiencing multiple infrastructure issues. This did have a failure before that I was not able to investigate before the cl was deleted, which I understand is pretty frustrating. Rebasing again to see if we can get a clean run now. |
Instead of the legacy behavior where the center sliver paints on top, just have the first sliver paint on top. This is quite a bit simpler to document and simpler to implement, and it removes variation between a shrink-wrapped and non-shrink-wrapped viewport. Moreover the new behavior is the same as the old whenever not using the `center` field; and it turns out there are no tests in the tree that notice the difference. So hopefully this won't even be a breaking change.
I took these out as a last-minute simplifying change... and I guess I must not have actually rerun the tests after doing so, oops. Turns out I put them there in the first place for a good reason.
This keeps things a bit cleaner for code that uses this feature.
e252330 to
3ff7d01
Compare
|
If we aren't able to resolve it this time, I recommend rolling back to the non-breaking commit. Then we can consider pursuing the additional change after as a separate change. |
Fixes #145592.
When slivers in a CustomScrollView overlap, this makes it possible to control which of the slivers will sit in front of the other one, meaning that it paints last and gets hit-tested first.
In this version there are two choices: the first sliver paints in front, or the last sliver paints in front. The first sliver in front is the default; it's the behavior needed for SliverAppBar, or other situations where the first sliver is some sort of header.
The existing behavior is actually quite a bit more complicated than that, with the "center" sliver painting in front, plus it varies depending on
shrinkWrap. As far as I can tell this behavior isn't documented anywhere. It's equivalent to first-sliver-in-front wheneverCustomScrollView.centerisn't being used; and in fact there don't seem to be any tests in the tree that notice the difference between the existing behavior and first-sliver-in-front.So although I actually have an implementation that preserves the more complex existing defaults, I'm hopeful we won't need it: if neither google3 nor customer tests are relying on that undocumented distinction either, then we can go ahead and simplify this behavior without a breaking change.
Pre-launch Checklist
///).