Scroll position back to previous position, or sometimes, flicker page.
Categories
(Core :: Layout: Scrolling and Overflow, defect, P3)
Tracking
()
Webcompat Priority | P3 |
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox65 | --- | unaffected |
firefox66 | --- | affected |
firefox67 | --- | affected |
People
(Reporter: alice0775, Unassigned)
References
(Depends on 1 open bug, Blocks 2 open bugs)
Details
(Keywords: regression, webcompat:platform-bug)
Reproducible: always
Steps To Reproduce:
- Open https://gluonhq.com/products/
- Rotate the mouse wheel by one notch
- Rotate the mouse wheel in the opposite direction by one notch
Actual Results:
Once the page scrolls to a expected position, it will revert back to its previous position.
Sometimes, flicker page.
Expected results:
Once the page scrolls to a expected position. i,e page should be top.
Disable scroll anchor will fix the issue.
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Comment 1•6 years ago
|
||
screencast https://www.youtube.com/watch?v=CH2O9VxFMSM
Comment 2•6 years ago
|
||
I can reproduce this, not sure what's going on.
Comment 3•6 years ago
|
||
I know a bit more about what's going on. Not a full picture yet.
The page is emulating 'position: sticky' with a fixed position nav-bar, and a spacer div underneath with margin sized to the height of the nav-bar.
When the page is scrolled to a certain height, a timeout is queued to transition to 'sticky-enabled' which relayouts the nav-bar, changing its height, and consequently resizing the spacer div.
The code to resize the spacer div triggers a synchronous layout at a point when the spacer has been sized to 0. This causes us to perform a scroll adjustment because the whole page has been shifted upward. The code will continue and restore the size of the spacer div. We then perform a scroll adjustment because the whole page has been shifted downward.
In the end, these adjustments should cancel themselves out. But oddly enough sometimes they don't. This happens infrequently, so I'm guessing we might have a scroll event & timeout race, or some race with APZ.
It should also be noted that Chrome is affected by this as well, but not as severely.
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 4•6 years ago
|
||
Users are reporting a similar issue on 'https://www.tweaktown.com/'.
Comment 6•6 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 7•6 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Comment 8•5 years ago
|
||
This seems to be working for me now, mind confirming?
Reporter | ||
Comment 9•5 years ago
|
||
Build ID 20190724220024
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
I can still reproduce the issue with Latest Nightly70.0a1 windows10 with STR comment#0.
Comment 10•5 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Comment 11•5 years ago
|
||
What about now? Bug 1561450 should've helped. I can't repro now but it seems I couldn't repro before either so...
Reporter | ||
Comment 12•5 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)
What about now? Bug 1561450 should've helped. I can't repro now but it seems I couldn't repro before either so...
I can reproduce the issue on Nightly71.0a1 Windows10.
Build ID 20190926094200
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
Comment 13•5 years ago
|
||
:(
Updated•5 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•8 months ago
|
Updated•7 months ago
|
Updated•3 months ago
|
Description
•