You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sticky_header: Fix hit-testing when header overflows sliver
When the sticky header overflows the sliver that provides it -- that
is, when the sliver boundary is scrolled to within the area the
header covers -- the existing code already got the right visual
result, painting the header at its full size.
But it didn't work properly for hit-testing: trying to tap the
header in the portion where it's overflowing wouldn't work, and
would instead go through to whatever's underneath (like the top of
the next sliver). That's because the geometry it was reporting from
this `performLayout` method didn't reflect the geometry it would
actually paint in the `paint` method. When hit-testing, that
reported geometry gets interpreted by the framework code before
calling this render object's other methods.
Specifically, this sliver was reporting to its parent that its
paint region (described by `paintOrigin` and `paintExtent`) was
the same as the child sliver's paint region. In reality, this
sliver in this case will paint a larger region than that.
Fix by accurately reporting this sliver's paint region (via
`paintOrigin` and `paintExtent`), while adjusting `headerOffset`
to be relative to the new truthful paint region rather than the
old inaccurate one.
This fix lets us mark a swath of test cases as no longer skipped.
On the other hand, this change introduces a different bug in this
overflow case: the child sliver is now painted in the wrong place if
_headerAtCoordinateEnd(). (It gets lined up with the inner edge of
the header, even though it's too short to reach the viewport edge
from there.) That bug is latent as far as the Zulip app is concerned,
so we leave it for now with a TODO.
Other than that, after this fix, sticky headers overflowing into
the next sliver seem to work completely correctly... as long as
the viewport paints the slivers in the necessary order. We'll
take care of that in an upcoming PR.
0 commit comments