1656156 - Significant delay on page loading (with "no response" on window title)

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[blinky]

+++ This bug was initially created as a clone of Bug #1648355 +++

I can still reproduce bug 1648355 using the STR in comment 8.

Steps to reproduce:

1. Download and install all Google Noto Fonts.
2. Download Font Loader.
3. Download Franklin Gothic Book Regular.ttf.
4. Open the Font Loader, Click on the Add Fonts button, Select the font file Franklin Gothic Book Regular.ttf then click Open.
5. Click on the Load button.
6. Open attachment 9159611 [details].

Note the issue happens because of the 🏴 emoji.

Profiler data https://share.firefox.dev/3fbwWjQ

Comment 1

[blinky]

This also happens on startup.

Steps to reproduce 2:

1. Download and install all Google Noto Fonts.
2. Open Firefox.
3. Open attachment 9159611 [details].

Profiler data https://share.firefox.dev/2X4BSRh

Comment 2

[blinky]

Looks bug 1648355 fix this issue only on Windows 10 VM. Profiler data https://share.firefox.dev/3ilQJyI

Comment 3

[Jonathan Kew [:jfkthame]]

I suspect bug 1658207 may help here. Let's see how it looks after that lands.

Comment 4

[blinky]

I can still reproduce this bug after land bug 1658207. Profiler data https://share.firefox.dev/2FhbAVS

Comment 5

[blinky]

I can not reproduce this after remove 🏴 emoji. Profiler data https://share.firefox.dev/2XSwReQ

Comment 6

[Jonathan Kew [:jfkthame]]

It looks like the delays in the recent profiles are much shorter than we originally saw in comment 0, but still a lot more than we'd like. The issue is triggered by the flag emoji sequence that includes "tag" characters, which aren't supported by any available font on Windows; these trigger an exhaustive search of all the fonts, and with so many fonts installed, that's slow.

There are a couple of things we may be able to do here, but also, could you please take a similar profile of loading the example in a newly-launched browser, with the gfx.e10s.font-list.shared disabled, for comparison? Thanks.

Comment 7

[blinky]

Attachment: testcase

I can also reproduce in this test case with the steps in comment 0 and comment 1. Profiler data https://share.firefox.dev/2DNPmKL

Comment 8

[blinky]

Profiler log with gfx.e10s.font-list.shared disabled https://share.firefox.dev/2XS3jyb.

Comment 9

[Jonathan Kew [:jfkthame]]

Thanks. Yeah, that example has a codepoint (U+0378) that is unassigned in Unicode, so unsurprisingly, no font supports it; but we try really hard to find one that does.

So your profiles show that with gfx.e10s.font-list.shared enabled, the reflow is a lot better (8.9s) than it was using the old back-end (52.5s). So that's somewhat encouraging, but I'd still like to improve things further.

Comment 10

[Jonathan Kew [:jfkthame]]

There are several things we can do in the font-matching code to mitigate this, by short-circuiting the expensive search in cases where it's not actually useful:

• Trailing codepoints in a cluster that are default-ignorable can just be assigned to the same font as the base character.
• Unassigned Unicode codepoints should be treated like Private Use characters: we allow them to work, but only using a font that is explicitly specified in the font-family list. Doing a system-wide fallback for codepoints that have no standardized, interoperable meaning isn't really valid. If the author wants to use such a codepoint, they need to be explicit about the font that's expected to handle it.
• In general, default-ignorable characters can be assigned the font of the surrounding text; as they're not going to be visibly rendered, it doesn't matter if the font does not explicitly support them.

These tweaks make it less likely that we'll end up in the worst-case of searching (in vain!) through all the installed fonts (although it's still possible to construct examples that'll hit it).

Comment 11

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1656156 - Skip the font-matching algorithm for cluster-extender codepoints that are default-ignorable, as there's no benefit to potentially switching fonts here. r=m_kato

Comment 12

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1656156 - Don't do font fallback for unassigned Unicode codepoints; like Private Use characters, only allow these with an explicitly-specified font. r=m_kato

Depends on D86943

Comment 13

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1656156 - Don't do font fallback for default-ignorable characters that won't be visibly rendered anyway. r=m_kato

Depends on D86944

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1643d98700b9
Skip the font-matching algorithm for cluster-extender codepoints that are default-ignorable, as there's no benefit to potentially switching fonts here. r=m_kato
https://hg.mozilla.org/integration/autoland/rev/52e87432fb01
Don't do font fallback for unassigned Unicode codepoints; like Private Use characters, only allow these with an explicitly-specified font. r=m_kato
https://hg.mozilla.org/integration/autoland/rev/25eb83f06bda
Don't do font fallback for default-ignorable characters that won't be visibly rendered anyway. r=m_kato

Comment 15

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/1643d98700b9
https://hg.mozilla.org/mozilla-central/rev/52e87432fb01
https://hg.mozilla.org/mozilla-central/rev/25eb83f06bda