Found in

• 109.0a1 (2022-11-17)

Affected versions

• 109.0a1 (2022-11-17)

Tested platforms

• Affected platforms: Windows 10x64, Ubuntu 20.04
• Unaffected platforms: macOS 11

Steps to reproduce

1. Open a random Bugzilla issue on a new Firefox profile (e.g. bug 1800140).
2. Click on People, References, and Details to expand them.
3. Click and hold the scrollbar and scroll to the bottom of the page.
4. Release the mouse click and observe the page elements.

Expected result

• Page content is not moved.

Actual result

• Page content is moved.

Regression range

• Pushlog: Last good revision: 61377e7604a69e7f3f385506db84b398ccfbd62d
  First bad revision: 248c025cb922254392e9e53311edae245284f740
  Pushlog:
  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=61377e7604a69e7f3f385506db84b398ccfbd62d&tochange=248c025cb922254392e9e53311edae245284f740
  Potential regressor: bug 1745969.

Additional notes

• Attached a screen recording.
• The same issue can be seen when performing steps 1 to 4 while scrolling to the top of the page.
• This also happens on regular Firefox profiles.
• I cannot reproduce the issue on macOS 11 using a trackpad.
• Another way to reproduce the issue is by using auto-scroll to go to the bottom of the page, then click inside the page, and press the middle mouse button again.

:hiro, since you are the author of the regressor, bug 1745969, could you take a look?

For more information, please visit auto_nag documentation.

I thought it was caused by the combination of bug 1774315 and bug 1674687. But with fixes for those I can still see this issue locally on my Linux box. After looking at carefully the slight movement, I am ~100% sure that this is the same symptoms of bug 1745969 comment 19. I will probably ask backing out bug 1745969.

Okay what I've found so far is this is somewhat related to overlay scrollbars, enabling "Always show scrollbars" option appears to fix this issue.

I see this issue as well on the Bugzilla page when using the mouse wheel to go to the bottom/ top of the page and move the mouse.

This is also related to APZ paint-skipping (apz.paint_skipping.enabled), if I disabled it, I don't see this issue.

It looks like this issue isn't directly related to the issue in bug 1745969 comment 19 (i.e. blob-fallback-clip.html failure on Windows 10). I pushed a try run with disabling "apz.paint_skipping.enabled", but the reftest still fails.

This isn't limited to Bugzilla, I can see it everywhere. With the overlay scrollbars disabled, I should add. Also, I can reproduce it when scrolling in any way possible (mouse wheel, scrollbar, auto-scroll), even with the keyboard (pgup, pgdown, home, end, maybe not with arrows). For example, while typing this comment, I clicked out of the textarea, then pressed the Home button, then then End button. When I focused again into the textarea, some of the text outside (name of the poster, links to bugs) moved.

I should note, that after I just posted the previous message, trying to reproduce the bug with the home/end buttons and clicking outside and into the textarea as I described, fails.

mozregression --good 2022-01-30 --bad 20230116211903 -a https://hudoc.echr.coe.int/eng#{%22itemid%22:[%22001-222750%22]} --pref general.autoScroll:true

14:55.98 INFO: Last good revision: 61377e7604a69e7f3f385506db84b398ccfbd62d
14:55.98 INFO: First bad revision: 248c025cb922254392e9e53311edae245284f740
14:55.98 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=61377e7604a69e7f3f385506db84b398ccfbd62d&tochange=248c025cb922254392e9e53311edae245284f740

248c025cb922254392e9e53311edae245284f740 Hiroyuki Ikezoe — Bug 1745969 - Stop doing SnapCoord. r=tnikkel
c381bdd1fea3edcf28691a8c9aa4723f1034c6c0 Hiroyuki Ikezoe — Bug 1745969 - Use "MozReftestInvalidate" event instead of onload to wait for ready to be tested. r=tnikkel

I uploaded a workaround for this specific case. That's the best thing what I can do right now, I believe the underlying cause of this bug is in between WebRender and Gecko display items.

Botond realized me that the original workaround I posted doesn't work with touchpad two fingers scrolling because the original change used IsApzAnimationInProgress which is basically false in the case of two fingers scrolling. He suggested me to use scrollend event to tell whether it's time to call SchedulePaint or not.

:hiro could this be assigned?
It has a patch but it's WIP, since it's a recent regression would consider uplift for 111 if it lands in 112?

Yes. Though the patch here will never land. Bug 1817126 should fix this bug.

This repros the bug for me rather easily. I'm trying to repro the issue when scrolling normally but I can't (it only repros when I hit the bottom or top).

So the good thing is that this seems specific to hitting the bottom or top of the page. i.e, regular scrolling doesn't seem to hit this, so this is probably not super-severe... But we should still figure this out

There are definitely multiple source of the problem.

For the border test case Emilio attached in comment 17, using LayoutDevicePoint::FromAppUnits here instead of Rounded one solves the issue as far as I can tell. But it doesn't affect the text case attached in comment 16, or the bugzilla case the STR in comment 0.

I think I found a source of the text shifting problem. That's here in where we are processing display item for text in WR.

So for example

1. on a paint during async scroll is on-going, the text bounds value (info.bounds) is Box2D((-1.0, -781.4), (88.066666, -755.4)) and the current scroll offset.y value is 829.0 (which has been rounded by the function in comment 20). Then the layout.rect value would be rounded to Box2D((-1.0, 48.0), (88.0, 74.0)).

2. on a later paint when the async scroll finished, the current scroll offset.y value is 0, and the text bounds value is Box2D((-1.0, 47.4), (88.066666, 73.4)), it would be rounded to Box2D((-1.0, 47.0), (88.0, 73.0)).

You can see 1px difference between 1) and 2).

I managed to find all sources which cause the text/border 1px shifting issue. Note that the source in comment 21 wasn't peculiarly necessary.

Though D173239 has changes for each sources, I am pretty unsure it's the right thing to do since I don't have any expertise in these relevant area. I hope someone who is an expert about it to take a look at each sources and figure out proper ways to handle the issues.

So, this bug was fixed by bug 1817126 (backing out bug 1745969 which caused this bug), but I'd like to keep this bug open since there are a couple of nice test cases Emilio wrote. I don't want to lose this not being tracked. Putting this into wr-snap dependencies.

Is bug 1817126 we should take on v112 still? We're building the RC on Monday, so time is limited if yes.

I don't think we should this issue had been there in a couple of releases, riding it on v113 would be fine.

I can reproduce it in Nightly 115 using page loaded inside an iframe.