1744456 - Font dialog changes size while opening causing issues for those who prefer reduced motion

Status: NEW

(Toolkit :: Preferences, defect, P5)

Description

[MarjaE]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

Open about:preferences.

Search "font."

Find "Fonts and Colors," and click "Advanced."

Actual results:

The modal slides text down as it loads.

Expected results:

Modals should not animate as they load, especially not modals for accessibility preferences.

Using Mozregression with my profile starts flashing and quits just before here:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8c5f9b08938ed193c756b6bc9884a353b796a55f&tochange=f3da8ae9d1a3e74cd273746da51a035ddc572bee

Using Mozregression without any profile makes it harder to see, the problem doesn't show up early 2021, and it gradually worsens, making bibisection impossible.

That suggests font size settings may affect this.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Hiroyuki Ikezoe (:hiro)]

I don't see any animation in the dialog. But I can see each select combo box slightly is changed to the selected value. Is that the animation you meant?

Comment 3

[MarjaE]

Attachment: This animation.

I used Mozregression to get the default settings. I click on Advanced, the modal appears, it animates resizing, then it loads the font names.

Comment 4

[Jonathan Kew [:jfkthame]]

I'm seeing a regression at https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a30e7b8011ccf4336515884e8294e7355dbf32af&tochange=1bd69e1e04cedd0aaf300ec6ab0c76e32fd02a27.

Prior to this, the Advanced dialog appears with its controls in their "correct" final positions (although initially the values are defaults -- e.g. the sizes initially show "9", and then they get updated a moment later to "16" and "13").

After that push (presumably it's bug 1704113 that is responsible), it looks like the <menulist> elements initially appear with a larger height, and then they shrink and therefore things shift upwards slightly as the values are populated. More specifically, I think it's the three <menulist>s that are initially blank (the Serif, Sans-serif, and Monospace font choices) that resize themselves.

Poking with the Inspector, it appears that these menulist elements have a height of 32px, which leads to the enclosing hbox (grid item) being 40px high; but if I remove the menupopup> child from one of them, its height increases to 34.1667px, and the enclosing box becomes 42.1667px. I guess when the panel is initially displayed, we haven't yet created the menupopup children of these menulists (because the list of font names is fetched asynchronously), and when that child is missing, the enclosing item gets a different height.

This seems like more of a front-end issue; moving component to Toolkit:Preferences.

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

Thank you for filing and apologies for the pain it has caused you. As this is a seldom used part of the browser, and typically only accessed once per install if any, I'm going to mark this as S4.