Found in

• Firefox 109.0a1

Affected versions

• Firefox 108.0b9
• Firefox 109.0a1

Tested platforms

• Affected platforms: macOS 13.0.1
• Unaffected platforms: Windows, Ubuntu

Preconditions

• Have VoiceOver active

Steps to reproduce

1. Launch Firefox
2. Access about:preferences#general
3. Scroll to Fonts category (have to be on the lower side of the page)
4. Open the list to change the font

Expected result

• The list has no visible glitches

Actual result

• The list jumps out of its place and gets cut on the lower side and voiceover selections are out of place

Regression range

• Will see for a regression

Additional notes

• The issue can be seen in the following attachment
• This issue only reproduces if Fonts is on the lower side of the about:preferences page, so the list opens in the upper part of the view

Looked for regression and it seems it was introduced on 97.0a1 between 2021-12-14 and 2021-12-15).

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f0cad1d9e20e16f6cacd1a3c01f52fdca226c5b5&tochange=67d5d9f8377572a37548555fe9c9a7d508c39514

Bug 1400420 - fix tabbing backwards in prefs to not hide items behind the search/policies sticky header, r=preferences-reviewers

Gijs, is this something you can take a look at?

This smells like a layout/a11y bug to me because AIUI the ensureScrollPadding function gets called on pageload, so the scroll padding isn't changing between the dropdown opening in the with/without voiceover case. I'm hoping Emilio has some clue about what might be going on here.

Yeah that smells like the a11y tree coordinates being wrong or somesuch.

Yep this is a bounds bug, thanks :)
:csasca it'd be helpful to know if this is a regression related to enabling the accessibility cache (accessibility.cache.enabled) or if it was broken somewhere else

It seems like this reproduces both with and without the cache, so it's a true regression.
On the video in #c0, the dropdown scrolls the entire page when its opened. I noticed it doesn't happen when activated with the mouse. I think this is probably the root of the bounds issue here (so maybe it's an action-related issue instead?)

:gijs are there functions that get called when this menu in particular opens? I noticed that this issue doesn't occur for other menus on the page, like the font size menu or default zoom. Poked around preferences.js, fonts.js, and main.js but didn't find anything about setting the default font, only reading from the preference (and I assume the code that associates preferences with particular menulists is common, not specific this menu).

(In reply to Morgan Reschenberg [:morgan] from comment #6)

It seems like this reproduces both with and without the cache, so it's a true regression.
On the video in #c0, the dropdown scrolls the entire page when its opened. I noticed it doesn't happen when activated with the mouse. I think this is probably the root of the bounds issue here (so maybe it's an action-related issue instead?)

:gijs are there functions that get called when this menu in particular opens?

I don't see anything in the DOM. I checked using the devtools inspector which shows "event" bubbles next to DOM nodes. I don't see anything relevant on either that menulist or its ancestors, only ones that are coming from the menulist custom element and are thus the same for all the dropdowns.

I noticed that this issue doesn't occur for other menus on the page, like the font size menu or default zoom.

Hm. Is it possible that it's just about the size (number of items) of the menu? That would be a good thing to try out, anyway.

Poked around preferences.js, fonts.js, and main.js but didn't find anything about setting the default font, only reading from the preference (and I assume the code that associates preferences with particular menulists is common, not specific this menu).

Menulists tend to be built on a per-pref basis because you cannot deduce the non-selected options from any pref (and anyway the label doesn't necessarily correspond 1:1 to the value).

fonts.js only gets loaded in the fonts dialog, so we can ignore that.

https://searchfox.org/mozilla-central/rev/abf6758ed833c203f84703aa2e3e3d317571b1e9/browser/components/preferences/main.js#479-482 adds a change event listener to the font pref that forces a rebuild of the dropdown. There is also some funky stuff going on inside that rebuild function: https://searchfox.org/mozilla-central/rev/abf6758ed833c203f84703aa2e3e3d317571b1e9/browser/components/preferences/main.js#1681-1690 . The meat of the creation of the contents of the font dropdown is in https://searchfox.org/mozilla-central/source/toolkit/mozapps/preferences/fontbuilder.js .

In what way is VO activation different from a click? It might be easiest to just add a bunch of logging around this code to try to spot differences between the VO activation and the click activation...

FWIW the most suspect code I can think of here is the popup positioning code. I wonder if bug 1805414 fixes this too.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

FWIW the most suspect code I can think of here is the popup positioning code. I wonder if bug 1805414 fixes this too.

just tested with your patch locally :) yes it does fix it

Should be fixed then, but reopen if it isn't for some reason :)

I have reproduced this issue using Firefox 109.0 on macOS 10.15.
I can confirm this issue is fixed, I verified using Firefox 111.0a1 (2023.01.22) and Firefox 110.0b4 on macOS 10.15.