Consider optimizing changes from/to overflow: hidden better.
Categories
(Core :: Layout, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox95 | --- | fixed |
People
(Reporter: emilio, Assigned: emilio)
References
Details
Attachments
(3 files)
Right now they always have to reframe, because we optimize the scrollbars away for overflow: hidden / scrollbar-width: none.
This causes a lot of work when you toggle overflow a lot. For example, the Youtube notification popup goes from overflow: hidden to overflow: auto on hover, which is slow if you have a ton of notifications.
I think a good approach to preserve the optimization but avoid silly work would be something like what we do for the root element but conditionally.
For example. If you get a frame with overflow: hidden / scrollbar-width: none, we don't create scrollbars (as we do now). When you toggle to other sorts of scrollable overflow, we reframe, and create scrollbars. But from then on we don't need to reframe at all. We have scrollbars and can handle all scrollable overflow like we do for the viewport.
Is there any reason why this wouldn't work? Seems like extending ScrollbarChange to deal with this should be somewhat straight-forward.
|
Assignee | |
Comment 1•6 years ago
|
||
Daniel, wdyt about this, since you implemented the initial implementation of bug 1344398?
|
||
Comment 2•6 years ago
|
||
So with overflow: hidden we have a scrollframe, but just no scrollbars? And instead we could have a scrollframe but hidden scrollbars on the scrollframe and just unhide if it changes to "auto"? And we'd still reframe on changes to/from "visible"?
|
|
Assignee | |
Comment 3•6 years ago
|
||
(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #2)
So with
overflow: hiddenwe have a scrollframe, but just no scrollbars? And instead we could have a scrollframe but hidden scrollbars on the scrollframe and just unhide if it changes to "auto"? And we'd still reframe on changes to/from "visible"?
Yes, that'd be the proposal. We already need to handle the "hidden overflow but has scrollbars" for the viewport. And yeah, changes from visible / -moz-hidden-unscrollable would reframe to create the scrollframe and all that dance.
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 6•4 years ago
|
||
This prevents jank when switching from overflow: auto -> hidden or such.
|
|
Assignee | |
Comment 7•4 years ago
|
||
No behavior change.
|
||
Comment 9•4 years ago
|
||
Backed out for causing failures at scrollbar-width-paint-001.html.
Backout link: https://hg.mozilla.org/integration/autoland/rev/76fc25abc32021eecf95bb270a711acec0739c3a
Failure log: https://treeherder.mozilla.org/logviewer?job_id=354812116&repo=autoland&lineNumber=3953
|
|
Assignee | |
Comment 10•4 years ago
|
||
This was pre-existing but caught by some scrollbar-width tests. A
test-case that reproduces on current nightly:
data:text/html,<html style="overflow: scroll; scrollbar-color: red red; scrollbar-width: thin">
Toggling the scrollbar-width declaration on devtools doesn't change
the effective scrollbar width. Ensure we correctly reflow the scrollbars
in this case.
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
Assignee | |
Updated•4 years ago
|
|
||
Comment 11•4 years ago
|
||
|
|
||
Comment 13•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/1492d117aca4
https://hg.mozilla.org/mozilla-central/rev/cb21a032e4ad
https://hg.mozilla.org/mozilla-central/rev/16504649f489
Description
•