1972014 - position:sticky about:addons sidebar text shifts up/down when scrolling with layout.disable-pixel-alignment=true

Status: VERIFIED FIXED

(Core :: Panning and Zooming, defect, P2)

Description

[Kestrel]

Attachment: Text in sidebar jitters vertically while scrolling

STR:

1. Change layout.disable-pixel-alignment = true.
2. Visit about:addons.
3. Scroll up and down.

Expected:
Text in sidebar remains static while scrolling.

Actual:
Text shifts up and down slightly when scrolling.

Does not happen with layout.disable-pixel-alignment = false.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Looks like it commonly happens on position:sticky elements. I do less see the shifting on about:addons, but I do easier see on https://elixir.bootlin.com/linux/latest/source/MAINTAINERS by dragging scrolling thumb scrolls.

CCing Glenn.

Comment 2

[Hiroyuki Ikezoe (:hiro)]

I do see element shifting in the header on https://wykop.pl/wykopalisko/najnowsze . The header is also position:sticky.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Attachment: Add some reftests for position:sticky which don't fail unfortunately

FWIW, I wrote some reftests involving position:sticky based on the reftests added in bug 1887125. Though these reftest don't catch this bug unfortunately.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

I did audit StickyScrollContainer.cpp that there's no suspicious pixel rounding/alignment code.

Now I realized that the sticky container itself is not shifting, elements inside sticky container are shifting. I did double-check by adding background-color: red to the position sticky element in question to easily tell whether the element is shifting or not.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

IIUC what https://phabricator.services.mozilla.com/D235720 did, I think, for elements inside sticky container;

1. If the sticky container is not stuck, do normalize_rect_scroll_offset
2. If the sticky container is stuck, normalize_rect_scroll_offset is not necessary? (because the container is kinda out-of-flow of the parent scroll container)

I did confirm that we do call normalize_rect_scroll_offset for elements inside a position sticky container while the container is being stuck.

Glenn?

Comment 6

[Hiroyuki Ikezoe (:hiro)]

Well what I saw was normalize_scroll_offset_and_snap_rect.

Comment 7

[Glenn Watson [:gw]]

I'm not sure what the right answer is here without doing some detailed debugging sorry - not sure when I'll have time to come back to this. May be worth raising with Bob to get it on the radar.

Comment 8

[Glenn Watson [:gw]]

I can't reproduce this locally - are you still able to reproduce on current nightly?

Comment 9

[Kestrel]

Yes, I can still repro it on latest Nightly 145.0a1 (2025-09-17).

Comment 10

[Glenn Watson [:gw]]

Perhaps it depends on compositing backend / screen resolution / scaling factor or something like that. Could you attach the content of your about:support output?

Comment 11

[Glenn Watson [:gw]]

I am able to reproduce this locally is I set layout.css.devPixelsPerPx to a high enough value (> 3.4 seems to do it). However, it is also occurring in the same way if I set layout.disable-pixel-alignment back to false and restart.

Comment 12

[Glenn Watson [:gw]]

Note to self when next working on this - frame_rect in StickyFrameInfo is changing by fractional amounts during scrolling with the pref enabled, but is always constant (though not integer) when the pref is disabled.

Comment 13

[Kestrel]

Happens on multiple systems with Ubuntu 25.04 and 24.04 LTS as well as Windows 11 (VirtualBox).

• 100% and 125% display scaling, more noticeable at 100%.
• New profiles with no customization.
• HW-WR and SW-WR.
• Wayland and XWayland.

I don't see it with layout.css.devPixelsPerPx = 1.25 unless layout.disable-pixel-alignment = true. It is more noticeable with this setting than 125% display scaling.

Comment 14

[Glenn Watson [:gw]]

Attachment: 1972014.html

A minimal repro case. With layout.css.devPixelsPerPx set to 1.0, a single mouse wheel down on the page will result in a slight jump after the scroll and the next display list arrives. This may suggest something related to how things are interacting between APZ + new display list arriving when fractional scroll is enabled.

Comment 15

[Glenn Watson [:gw]]

The attachment only reproduces when layout.disable-pixel-alignment is true for me.

Comment 16

[Glenn Watson [:gw]]

Can remove the dependency on mouse wheel with the following adjustment:

        e.onclick = function() {
            window.scrollBy({ left: 0.0, top: 100.0, behavior: "smooth" });
        }

The discrepancy seems to occur after the scroll completes and the next time a new scene build begins.

Comment 17

[Glenn Watson [:gw]]

The sticky position element gets hoisted to be a standalone scroll layer, i.e. a picture tile cache.

The size of the surface allocated remains correct (280 x 100), and the rasterization on the tile cache surface appears correct (the root and prim spatial nodes are the same since the tile cache forms a raster root, thus the rasterization transform is always [correctly] identity).

However, during the scroll the tile cache surface sometimes gets composited at a y-offset of 166.0 and remains there. Other times it gets composited at a y-offset of 167.0, which is where it gets composited after a new scene build and display list is processed.

Comment 18

[Glenn Watson [:gw]]

Attachment: Bug 1972014 - WIP - see what breaks

Comment 19

[Glenn Watson [:gw]]

Attachment: 1972014-2.html

A minimal repro based on the content from https://wykop.pl. Text jitters during autoscroll at 200% display scale, even with the attached WIP patch applied (which does appear to fix jitter on the background sticky layer itself).

Comment 20

[Glenn Watson [:gw]]

There are definitely two similar but unrelated bugs. The attached patch fixes the rounding of placement of sticky position picture caches when the scroll offset flips sign (due to external scroll offset changes). The second bug appears specific to text runs, and may be related to how / when we snap text run offsets during frame building.

Comment 21

[Glenn Watson [:gw]]

The local space offsets of the glyphs that are pushed by Gecko to WR differ in this test case when the preference is flipped (and running at 200% display scale). When fractional scaling is enabled, the glyphs are placed at half-pixel offsets, which doesn't seem right.

Comment 22

[Kestrel]

Fix window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e7d7c86f87480d2c840fc6f86be087f77884cb4b&tochange=2ebfcc945c77078f83d83469a3218c404e15c416

Fixed by Bug 1997483.

Comment 23

[Giorgia Nichita, Release Desktop QA]

Reproduced the issue on an affected Nightly build from 2025-06-13 on Windows 10.
Verified as fixed on Nightly 147.0a1 (20251113163320) and Firefox 146.0b2 (20251112090346) across Windows 10, Ubuntu 22, and macOS 11. No vertical jitter is observed.