Open Bug 1526776 Opened 6 years ago Updated 3 months ago

Scroll position back to previous position, or sometimes, flicker page.

Categories

(Core :: Layout: Scrolling and Overflow, defect, P3)

66 Branch
x86_64
Windows 10
defect

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:

  1. Open https://gluonhq.com/products/
  2. Rotate the mouse wheel by one notch
  3. 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.

Summary: Scroll position back to previous position → Scroll position back to previous position, or sometimes, flicker page.

I can reproduce this, not sure what's going on.

Assignee: nobody → rhunt

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.

Depends on: 1529702
Priority: -- → P3
Whiteboard: [webcompat]

Users are reporting a similar issue on 'https://www.tweaktown.com/'.

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

This seems to be working for me now, mind confirming?

Flags: needinfo?(alice0775)

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.

Flags: needinfo?(alice0775)

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

What about now? Bug 1561450 should've helped. I can't repro now but it seems I couldn't repro before either so...

Flags: needinfo?(alice0775)

(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

Flags: needinfo?(alice0775)
Webcompat Priority: ? → revisit
Webcompat Priority: revisit → P3
Severity: normal → S3
No longer duplicate of this bug: 1531653
Blocks: 1891489
Whiteboard: [webcompat]
Assignee: rhunt → nobody
You need to log in before you can comment on or make changes to this bug.