Entries from Fonts menu do a refresh every time the menu is opened

NEW
Unassigned

Status

()

defect
P5
normal
2 years ago
2 years ago

People

(Reporter: bogdan_maris, Unassigned)

Tracking

(Blocks 1 bug, {regression})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox56 unaffected, firefox57 wontfix, firefox58 wontfix, firefox59 ?)

Details

(Whiteboard: [photon-preference])

Attachments

(1 attachment)

[Affected versions]:
- Firefox 57 beta 9
- latest Nightly 58.0a1

[Affected platforms]:
- macOS 10.12.6
- Ubuntu 16.04 32bit
- Windows 10 64bit

[Steps to reproduce]:
1. Start Firefox
2. Visit about:preferences#general
3. Click Advanced under Language and Appearance.

[Expected result]:
- There is no visual issue when fonts menu opens.

[Actual result]:
- Various values of font, size refresh when clicking Advanced.

[Regression range]:
- This is a recent regression, here is the output of mozregression:

Last good revision: e58e11f74cc02a5aec2b4588190385b1980654e0
First bad revision: f255ec4e8c361e4526b7bfb1083cecb41fabbdd1
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e58e11f74cc02a5aec2b4588190385b1980654e0&tochange=f255ec4e8c361e4526b7bfb1083cecb41fabbdd1

Culprit: f255ec4e8c36  Myk Melez — Bug 1375978 - enumerate fonts asynchronously; r=jfkthame,nhnt11

[Additional notes]:
- Screencast showing the issue attached.
- I'm not sure this is the wanted behavior though, so I thought I would log a bug to answer this.
Flags: needinfo?(myk)
Blocks: 1375978
Priority: -- → P3
(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #0)

> [Steps to reproduce]:
> 1. Start Firefox
> 2. Visit about:preferences#general
> 3. Click Advanced under Language and Appearance.
> 
> [Expected result]:
> - There is no visual issue when fonts menu opens.
> 
> [Actual result]:
> - Various values of font, size refresh when clicking Advanced.

Previously, the Fonts dialog implementation would enumerate fonts synchronously before populating the font menus and displaying the dialog.  This meant that the font and size menus wouldn't refresh after the dialog appears, but the dialog would take longer to appear (janking the browser in the meantime).

With my fix for bug 1375978, the dialog implementation enumerates fonts asynchronously, which means that the dialog appears immediately, and the font/size menus are populated after enumeration is completed. That's what causes this visual issue.

(It also causes a related functional issue, which is that on a system that is pathologically slow to load fonts, it's possible for the user to race font enumeration by trying to open a font menu before enumeration completes, which won't work.)


> - I'm not sure this is the wanted behavior though, so I thought I would log
> a bug to answer this.

It isn't wanted behavior, but neither is it wanted for the dialog to take a long time to appear in the event of slow font enumeration.  And unfortunately font enumeration is inherently slow on some systems due to reasons beyond our control (slow OS APIs, especially when there are many fonts installed), so we're forced to make a tradeoff.

For the "default font" preference on the main preferences page, async font enumeration is a clear win: the default font is only one of many preferences on that page, and it's often below the fold; so font enumeration shouldn't block display of that page.

For the Fonts dialog, the tradeoff is trickier.  A user who opens that dialog clearly wants to manage fonts, so it's arguably preferable to delay displaying the dialog until fonts are enumerated, since the user can't manage fonts until then anyway.  That would make the dialog feel slow to open again in some cases (janking the browser in the process), but it would avoid this visual issue (and the related functional one).

A third, hybrid approach would be to synchronously populate each menu with an item representing the default font and then add items for the rest of the fonts after async enumeration completes.  That should avoid this visual issue (although not the related functional one) while still enabling the dialog to load quickly (assuming default font retrieval is quick, which I think is the case).  It's more complicated to implement, as it would require refactoring FontBuilder.buildFontList; but it should be possible.


Ultimately, this is a UX question.  Given the constraint (inherently slow font enumeration on some systems), do we want to optimize for rapid display of the Fonts dialog (at the cost of the visual/functional issues), or do we want to optimize for displaying the Fonts dialog only once all of its menus have been populated (at the cost of browser jank)?

I chose the former over in bug 1375978, but I don't have strong opinions about it, and I'm certainly open to reversing that decision.
Flags: needinfo?(myk)
Whiteboard: [photon-preference][triage]
Priority: P3 → P5
Whiteboard: [photon-preference][triage] → [photon-preference]
You need to log in before you can comment on or make changes to this bug.