2063386 - Size of mathematical expressions on Wikipedia (SVG-as-an-image) changes depending on offsets

Status: VERIFIED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Viktor Jägersküpper]

OS: Arch Linux

Steps to reproduce:

• Visit https://en.wikipedia.org/wiki/Yamabe_problem#The_Yamabe_problem_in_special_cases
• Scroll down/up slowly (step by step)
  -> The SVGs containing the equations are sometimes slightly up-/downscaled.

I ran mozregression and got:
Last good revision: 2a21129467270b93cf6d9584dfece592776bfe52
First bad revision: 35e727d8fda22f3ccfcb1e620484f041002a63c0
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a21129467270b93cf6d9584dfece592776bfe52&tochange=35e727d8fda22f3ccfcb1e620484f041002a63c0

This points to bug 2048146, which enabled layout.disable-pixel-alignment. I could reproduce this issue with the Nightly build 20250606213443 (2025-06-06, version 141), several builds older than that crashed on my PC. The pref layout.disable-pixel-alignment was introduced around that time as far as I can tell.

Comment 1

[Viktor Jägersküpper]

I could reproduce this issue with the Nightly build 20250606213443 (2025-06-06, version 141)

with layout.disable-pixel-alignment enabled.

Comment 2

[Alice0775 White]

I can reproduce the issue on Nightly155.0a1 Windows11.
Screencast: https://youtu.be/BNZnB9MTxGw

Comment 3

[BugBot [:suhaib / :marco]]

:hiro, since you are the author of the regressor, bug 2048146, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

mozregression doesn't work well on my Ubuntu 26.04, in most binaries it fails with "Process exited with code 11". But I got this range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=617bb52d9206cd9b3fa748e908af675559470185&tochange=bfc6a1e723c3790d435849dd8864f799b2ff38a3

https://hg-edge.mozilla.org/mozilla-central/rev/aae96401722b5355aebaf3f2797119751cf2b5a4 looks pretty suspicious, but the function in question no longer exists on our tree.

CCing Glenn.

Comment 5

[Viktor Jägersküpper]

in most binaries it fails with "Process exited with code 11"

I found out that I can work around that with MOZ_ENABLE_WAYLAND=0, i.e. by running on XWayland. It seems the pref name changed during the 141 development cycle, it is called layout.scroll.disable-pixel-alignment before that because layout.disable-pixel-alignment doesn't seem to work. (?)

Version 128 already has this issue. I've just tested version 115 which doesn't even have the pref layout.scroll.disable-pixel-alignment. So I think if it's a regression, it must have been introduced between 115 and 128.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Viktor Jägersküpper from comment #5)

in most binaries it fails with "Process exited with code 11"

I found out that I can work around that with MOZ_ENABLE_WAYLAND=0, i.e. by running on XWayland.

Indeed; this is tracked in bug 2031267. (Also, since we're discussing substantailly older builds - if you hit content-process crashes in older builds, you might also need to run mozregression with --pref "security.sandbox.content.level:0" to turn off sandboxing, due to an incompatibility between old Nightlies and modern linux versions.)

Comment 7

[Viktor Jägersküpper]

I've tracked the issue down to this regression window:
Last good revision: 8e959a7ded5f111e711c06a6728f76d3bd660699 (2023-12-03)
First bad revision: 76f22f29fcf9cd40a92a7bcf6b0a11cc782936b8 (2023-12-04)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8e959a7ded5f111e711c06a6728f76d3bd660699&tochange=76f22f29fcf9cd40a92a7bcf6b0a11cc782936b8

It contains bug 1867425 which enabled the pref layout.scroll.disable-pixel-alignment.

Comment 8

[Viktor Jägersküpper]

The Nightly build 20231204091942 which was built from revision 369922cc5c4efad6c87b13600325eb5a989cde81 (contained in the regression windows above) already has this issue, so this is my final pushlog:
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=8e959a7ded5f111e711c06a6728f76d3bd660699&tochange=369922cc5c4efad6c87b13600325eb5a989cde81

This still contains bug 1867425.

Comment 9

[Botond Ballo [:botond]]

The pref layout.disable-pixel-alignment was indeed added around 2025-06-06, though that was actually just a rename from layout.scroll.disable-pixel-alignment.

With layout.scroll.disable-pixel-alignment=true, I can reproduce the bug as far back as 2023-12-04, which is when that pref was added. So I think this is case of "it has always been broken without pixel alignment".

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: test.svg (resource for use in testcase)

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 12

[Daniel Holbert [:dholbert]]

Testcase attached, so that we're not reliant on Wikipedia to test this. I can reproduce by scrolling this testcase up and down - the SVG gets "squished" or "unsquished" depending on the scroll position.

I wonder if we're sizing it to plus or minus 1 device pixel, or something along those lines?

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: click button to move image

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: click button to move image

Comment 15

[Daniel Holbert [:dholbert]]

Attachment: screencast of testcase 2

Comment 16

[Daniel Holbert [:dholbert]]

(Sorry, that screencast seems to also show a weird artifact where the border changes color between cyan and gray. That's not a real thing that I'm actually seeing; that seems to have been a video encoding/compression artifact in the creation of the screencast.

It does show that the image gets smaller for every ~4th button-press (and then bigger again on the next press); that's what I meant to capture, and that's this bug.

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Daniel, the test case in comment 14 might be over-reduced. I do see the image size change with layout.disable-pixel-alignment=false.

Though I don't see it on Chrome at all so it's a different issue on our end?

Comment 18

[Hiroyuki Ikezoe (:hiro)]

Attachment: WIP: Bug 2063386 - Add reftests for an SVG image being rasterized at a size that depends on its subpixel offset.

The test draws the same SVG image twice, once at a fractional device offset and
once at a whole device offset. Snapping rounds the two opposite corners of the
destination rect independently, so the snapped height differs by one device
pixel, and since the image preserves its aspect ratio the bar is drawn 70px
wider in one case than in the other.

Only a band from the middle of the bar is visible, so the test and its reference
can differ in the bar's width but never in its position. The second test is a
control for that: it shifts the image by a whole pixel, which must not change its
size.

Comment 19

[Hiroyuki Ikezoe (:hiro)]

It's not over-reduced, it has narrowed down the root cause. I mean, the bug has been there regardless of layout.disable-pixel-alignment is true or false. With diisable-pixel-alignmen=true, it does often happen.

I just uploaded reftests to see this issue.

Comment 20

[Daniel Holbert [:dholbert]]

Thanks! Yeah, I think this is the root cause (prodded at without scrolling involved, and hence without layout.disable-pixel-alignment being relevant, since that pref is mostly used for scrolling-related stuff. Pixel-alignment just happens to paper over this specifically for scrolling.)

Thanks for writing the reftest!

I think this is really an imagelib bug, since it's about the size of the pixel-snapped region that we give the image to draw into (and then the SVG image is dutifully/correctly drawing into whatever area we give it).

Comment 21

[Daniel Holbert [:dholbert]]

Though I guess that's arguably Layout:Images, since this the relevant code to do that mostly lives in nsLayoutUtils, IIRC. :)

Comment 22

[Daniel Holbert [:dholbert]]

[ni=me to poke a bit more and hopefully come up with an idea for a fix here...]

Comment 23

[Viktor Jägersküpper]

layout.disable-pixel-alignment is not enabled yet on beta and release (see bug 1946610), so the status for Firefox 154/155 should be disabled.

Comment 24

[Viktor Jägersküpper]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #19)

the bug has been there regardless of layout.disable-pixel-alignment is true or false. With diisable-pixel-alignmen=true, it does often happen.

(In reply to Viktor Jägersküpper from comment #23)

layout.disable-pixel-alignment is not enabled yet on beta and release (see bug 1946610), so the status for Firefox 154/155 should be disabled.

Sorry, wontfix might be the better (correct) choice.

Comment 25

[Daniel Holbert [:dholbert]]

I think bug 2063903 is basically the same root cause as this bug (though there's no scrolling involved there; it's getting at the root cause in a scroll-independent way as with comment 19 here).

Comment 26

[Emilio Cobos Álvarez [:emilio]]

I confirmed that the patch I submitted for bug 2063903 fixes this.

Comment 27

[Emilio Cobos Álvarez [:emilio]]

That said, maybe our snapping code could be a bit cleverer?

Comment 28

[Hiroyuki Ikezoe (:hiro)]

I think this was fixed by bug 2063903. I am going to close this bug.

Emilio, if you have an idea to make the snapping code cleverer, feel free to open a new bug. Thanks!

Comment 29

[Timea Zsoldos [:tzsoldos], Desktop QA]

I've reproduced this issue using Firefox 156.0a1 (2026.06.13) following the STR from description on Windows 11.
Verified as fixed on the latest Nightly 157.0a1 (2026.09.07) and on Firefox 156.0b4, using Windows 11 and macOS 12 where the issue no longer persists, tested with wikipedia link and with both attached testcases.