Twitter unexpectedly changes scroll position when clicking photos
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox78 | --- | unaffected |
firefox79 | --- | unaffected |
firefox80 | --- | disabled |
firefox81 | --- | fixed |
People
(Reporter: saschanaz, Assigned: tnikkel)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
- Enable
apz.allow_zooming
- Access https://twitter.com/Haiganon/status/1286415015713497088
- Click the photo
- See it changes scroll position, in other words, whether closing the photo shows the same screen as it was.
Expected: No change
Actual: It scrolls up
Assignee | ||
Comment 2•4 years ago
•
|
||
In ScrollFrameHelper::ReflowFinished the patch changes us from using GetVisualScrollRange to using GetScrollRangeForUserInputEvents. When the photo is open the page sets overflow-y: hidden. This makes GetScrollRangeForUserInputEvents return a 0 scroll range because it looks at overflow hidden (GetVisualScrollRange does not). Then I assume that makes us scroll to 0.
Assignee | ||
Comment 3•4 years ago
•
|
||
When the slider frame gets notified about the max/min pos change in nsSliderFrame::AttributeChanged and notices that the curpos is not between it, it scrolls the scrollframe.
Assignee | ||
Comment 4•4 years ago
|
||
This is tricky because we want the scrollbar attrs to match what the user can scroll, but this bug indicates one way that the scrollbars are strongly linked to (ie they can change instead of the other way around) the actual layout scroll position.
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Set release status flags based on info from the regressing bug 1651332
Comment 6•4 years ago
|
||
Should we even be having a scrollbar if overflow-y:hidden is set? Presumably this is not zoomed in so maybe the scrollbars shouldn't even be active.
Assignee | ||
Comment 7•4 years ago
|
||
Root scroll frames always get scroll bars so we can toggle overflow quickly (like this page does), the scroll bars are just hidden (by moving them off to the side of the frame, out of view) when they shouldn't be visible. I'm pretty sure that optimization is important enough that we want to keep it.
Assignee | ||
Updated•4 years ago
|
Comment 8•4 years ago
|
||
Ok, fair enough. But maybe they should check whether they're visible or not before the fiddle with the scroll offset?
Assignee | ||
Comment 9•4 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #8)
Ok, fair enough. But maybe they should check whether they're visible or not before the fiddle with the scroll offset?
Yeah, that was a thought I had. But another thought I had was that GetScrollRangeForUserInputEvents returning the rect (0,0,0,0) is logically wrong for overflow hidden scroll frames whose scroll position isn't (0,0). It should probably be returning (scrollpos.x, scrollpos.y, 0, 0), I can get this approach to fix this bug but it causes other problems I haven't investigated yet.
Comment 10•4 years ago
|
||
It should probably be returning (scrollpos.x, scrollpos.y, 0, 0),
Also a good point
Assignee | ||
Comment 11•4 years ago
|
||
UpdateScrollbarPosition and ReflowFinished both use the scroll range for this. It usually doesn't matter, but the next patch will make it important.
Updated•4 years ago
|
Comment 13•4 years ago
|
||
Pushed by tnikkel@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/475381b12bd5 ScrollFrameHelper::CurPosAttributeChanged should be using the scroll range not the scroll rect. r=kats https://hg.mozilla.org/integration/autoland/rev/f2886b1341e7 Make ScrollFrameHelper::GetScrollRangeForUserInputEvents return a range that encompasses the visual viewport offset even if we are overflow: hidden. r=kats
Comment 14•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/475381b12bd5
https://hg.mozilla.org/mozilla-central/rev/f2886b1341e7
Updated•4 years ago
|
Updated•4 years ago
|
Description
•