2063751 - Download button on toolbar has weird sideways movement as the download animation progresses/completes, at certain fractional desktop scale factors (e.g. 133%, 166%, 250%)

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect, P1)

Description

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug

STR:

1. Download a file. e.g. choose one of the download options from https://www.firefox.com/en-US/thanks/
2. Watch the download icon on your toolbar carefully, as it animates to show download progress and then the completed download.

ACTUAL RESULTS:
The animation has some parts where it "slides sideways" a bit and then snaps back into place. When it slides sideways, it reveals a little bit of a different phase of the animation that looks like it shouldn't be visible.

EXPECTED RESULTS:
No such sideways sliding.

I'm using Nightly 156.0a1 (2026-08-14) (64-bit) on Ubuntu 26.04.

Comment 1

[Daniel Holbert [:dholbert]]

Here's a performance profile that captures the bug -- you can sort-of see it in the screenshots track, but the images are downscaled/compressed so it's a bit garbled in places: https://share.firefox.dev/4wqE17t

Comment 2

[Daniel Holbert [:dholbert]]

Nightly 2026-08-01 shows EXPECTED RESULTS, so this seems to be a regression. I'll track down a regression range...

Comment 3

[Daniel Holbert [:dholbert]]

In bisecting, I found bug 2057645 where it looks like we updated the animations - pretty sure this would be a regression from that.

At first I thought maybe what I was seeing was just the updated design, but I don't think it is -- bug 2057645's phab revision has a screencast of the intended behavior, here:
https://mozphab-phabhost-cdn.devsvcprod.mozaws.net/file/download/hnztffdxjxg6ivocujxk/PHID-FILE-bfhkovz2sqq6v3b4s4cn/video.mp4
...which does not have the sideways motion that I'm seeing locally.

Comment 4

[Daniel Holbert [:dholbert]]

Aha, so this only reproduces if I have a fractional scale value in my Ubuntu system settings. I tested a few different scale options (Ubuntu gives me many choices on my setup):
100%: fine.
125%: fine. (Maybe very slight sideways movement, but I might be imagining it.)
133%: Buggy.
166%: Buggy.
250%: Buggy.
266%: fine.

The "Buggy" zoom levels all look essentially like my screencast, with the icon slipping sideways as it animates and occasionally snapping into place.
I typically run with 166% scale factor, and builds before the regression worked fine at that scale factor.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: longer screencast with a bit more UI visible

(if it helps, here's a screencast where I hit the bug multiple times in a row, with a bit more surroundings visible.)

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #3)

In bisecting, I found bug 2057645 where it looks like we updated the animations - pretty sure this would be a regression from that.

Verified that this was the regressor. Testing with 166% scale factor in my system settings, this is "bad" (the revision for bug 2057645):

mozregression --repo autoland --launch 135fa4853d964edc505b0961c9a085914320a8a0

...whereas this is "good" (bug 2057645's parent revision):

mozregression --repo autoland --launch eef056ac9141ab1c71e1bf1bbd879f583b212661

Comment 7

[Daniel Holbert [:dholbert]]

For completeness, I tested all of the "Buggy" scale factors from comment 4, using the last-good-build (final command in comment 6), and they all look "good" in that build.

So the last-good build was indeed robustly good at all of these scale factors.

Comment 8

[Daniel Holbert [:dholbert]]

[Tracking Requested - why for this release]: visual regression in prominent bit of UI (though fortunately only affecting a subset of users with various fractional scale factors)

Comment 9

[Juliana Gaibler [:juliana]]

oh nooo ˙◠˙

Emilio any idea why this is happening? This is the updated code, but I don't understand how the zoom factor affects the animated offset (and why the new animations have this behavior and the old ones didn't)

Comment 10

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2057645

Comment 11

[Emilio Cobos Álvarez [:emilio]]

175% is also broken.

Comment 12

[Emilio Cobos Álvarez [:emilio]]

I don't think you removed the tracking flag intentionally Juliana, right?

Comment 13

[Emilio Cobos Álvarez [:emilio]]

Attachment: Screenshot if I force-show the images.

I think this is hitting some sort of pixel-snapping issue, the image is mispositioned even when the animation isn't running.

If I remove the transform: translateX(0) from the element it corrects itself, which is a bit sketchy.

Comment 14

[Emilio Cobos Álvarez [:emilio]]

Attachment: notification-finish-animation.svg but without context-fill/stroke.

Comment 15

[Emilio Cobos Álvarez [:emilio]]

Attachment: Test-case

I can reproduce the mispositioning in this test-case. Probably something due to the structure of the SVG then.

Comment 16

[Emilio Cobos Álvarez [:emilio]]

Ok, I got it. I think this is effectively a Gecko bug. We snap image rects in a way that might distort the aspect ratio slightly here. And due to how SVG drawing works (the default preserveAspectRatio) it gets downscaled then centered.

The fix on the asset side is trivial tho.

Comment 17

[Emilio Cobos Álvarez [:emilio]]

Filed bug 2063903 for the Gecko side bug.

Comment 18

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2063751 - Use preserveAspectRatio="none" for download animations. r=#theme

See comment 16 and bug 2063903 for why this fixes the issue.

Comment 19

[Stephen Thompson [:sthompson]]

This is specific to an SVG asset that displays only with browser.nova.enabled, which won't be enabled by default until 157. We would like to fix before 157. Corrected by comment 23

Setting S3 since it's a purely visual glitch, although the additional motion may be disruptive to some users.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/3e6c5d70380a
https://hg.mozilla.org/integration/autoland/rev/f02cd1d3a8cb
Use preserveAspectRatio="none" for download animations. r=desktop-theme-reviewers,sfoster

Comment 21

[Daniel Holbert [:dholbert]]

I just realized that a slightly-simpler solution here would be to just remove the viewBox (in which case we'll get one synthesized for free using the SVG height and width attributes -- which matches the one that we've got hardcoded here -- and we get preserveAspectRatio="none" synthesized for free as well).

I mentioned this on bug 2064177 just now, where we'll likely be fixing up a few other SVG assets. If we remove attributes over there (as I think we should), then we'll likely want to adjust the SVG assets that we just fixed up here, as part of that bug, to remove the viewBox and preserveAspectRatio attributes, for completeness/consistency.

Comment 22

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/f02cd1d3a8cb

Comment 23

[Daniel Holbert [:dholbert]]

(In reply to Stephen Thompson [:sthompson] from comment #19)

This is specific to an SVG asset that displays only with browser.nova.enabled, which won't be enabled by default until 157.

Correction: we show this same download-animation -- and hit the same bug -- even when Nova is switched off. I just double-checked and confirmed that I hit the bug with Nova disabled, in a Nightly from a few days ago.

I just tested beta (Firefox 155.0b1) with a fresh profile, and confirmed it's affected.

--> Restoring firefox155 status to affected. We should request beta uplift. I'll do that over on bug 2064177, since that bug's patches should just get uplifted as a stack with this patch (since bug 2064177 is a simplification on what landed here, plus a fix for more files).

Comment 24

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox155 to wontfix.

For more information, please visit BugBot documentation.

Comment 25

[Emilio Cobos Álvarez [:emilio]]

Fine, fine...

Comment 26

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2063751 - Use preserveAspectRatio="none" for download animations.

See comment 16 and bug 2063903 for why this fixes the issue.

Original Revision: https://phabricator.services.mozilla.com/D318944

Comment 27

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: comment 0
• Code covered by automated testing?: no
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: one-liner
• String changes made/needed?: none
• Is Android affected?: no

Comment 28

[Daniel Holbert [:dholbert]]

Attachment: Bug 2063751 - Use preserveAspectRatio="none" for download animations.

See comment 16 and bug 2063903 for why this fixes the issue.

Original Revision: https://phabricator.services.mozilla.com/D318944

Comment 29

[Daniel Holbert [:dholbert]]

uh oh, I just requested beta uplift too (as part of a stack), sorry if that results in a duplicate uplift-attachment (can clean up)

Comment 30

[Daniel Holbert [:dholbert]]

synced up with emilio; we're using https://phabricator.services.mozilla.com/D319536 as the uplift request here (since it's part of a stack with the patch for followup bug 2064177).

Comment 31

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/f394d973931a
https://hg.mozilla.org/releases/mozilla-beta/rev/94853a37adb9

Comment 32

[Juliana Gaibler [:juliana]]

Thank you so much y'all!
I updated the filmstrip generator to not set viewBox anymore

Comment 33

[Alexandru Trif, Desktop Test Engineering [:atrif]]

.

Comment 34

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello! Reproduced the issue with Firefox 156.0a1 (2026-08-14) on Ubuntu 26 with 133% scale on the test case from comment 15 and with 160% scale on the download button.

Verification results on Ubuntu 26.04 (Scales tested: 100%, 125%, 133%, 150%, 166%, 200%):

• Browser Download Icon: Displays correctly on all tested scales across both Firefox 156.0a1 (2026-08-20) and 155.0b2.
• Test case from comment 15:

1. • Firefox 156.0a1 (2026-08-20): Displays correctly on all scales.
2. • Firefox 155.0b2: Displays correctly on most scales (100%, 125%, 150%, 166%, 200%), but fails to display properly at 133% scale.

Note that Firefox 156.0a1 (2026-08-20) was tested with both Nova on and off.

Do you think we should file a new issue for the 133% display failure on Firefox 155.0b2? Thank you!

Comment 35

[Emilio Cobos Álvarez [:emilio]]

That is odd, yeah, can you file a bug for that one?