1575315 - FF appears frozen while examining fonts loading smile.amazon.com (looking for codepoint U+FFFE)

Status: RESOLVED FIXED

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

Description

[Randell Jesup [:jesup] (needinfo me)]

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

I have evidence from a former coworker that when he visits smile.amazon.com the content process apparently is locked for 30s (profile to come after it's scrubbed), all doing gfxFontFamily::FindFontForChar \uffe <fontname> -> gfxMacFontFamily::FindStyleVariation <fontname>. Times per font range from 4ms (Oriya Sangam MN) to 1.6s (Callum) - and this is probably missing a lot of the fonts; the profile only caught the last 17s of the load.

https://perfht.ml/2Z6e4iT

jfkthame said in https://bugzilla.mozilla.org/show_bug.cgi?id=1567718#c8
"It appears he's loading a page at startup that include U+FFFE, which is a Unicode non-character codepoint that has no good reason to be present on a web page. Possibly an encoding error, or binary junk being treated as text content, or something like that.

This is causing us to search every font on the machine (and he has lots of fonts installed!) trying to find one that supports this codepoint. Maybe we should check for noncharacter codepoints and just bail out of even trying to render anything for them."

Vague recollection that windows Notepad(?) was inserting FFFE's at the start of html documents eons ago (and notepad hasn't really ever changed until very recently). Perhaps something like https://devblogs.microsoft.com/oldnewthing/20040324-00/?p=40093

More relevant from the WIkipedia page for BOM:
"Microsoft compilers[9] and interpreters, and many pieces of software on Microsoft Windows such as Notepad treat the BOM as a required magic number rather than use heuristics. These tools add a BOM when saving text as UTF-8, and cannot interpret UTF-8 unless the BOM is present or the file contains only ASCII. Google Docs also adds a BOM when converting a document to a plain text file for download. "

I think we should at least filter BOMs from lookup, even if we don't filter others.

Comment 1

[Jonathan Kew [:jfkthame]]

The other thing we could do here, if we have contacts at Amazon, is to ask why they're trying to do anything with U+FFFE on a web page.

I think we should at least filter BOMs from lookup, even if we don't filter others.

Just FTR, the codepoint in question here isn't a BOM (U+FEFF), it's a noncharacter (U+FFFE).

In a UTF-16 world, U+FFFE could arise if a UTF-16 stream were being interpreted with the wrong endianness; but if that were happening, every other character in that text stream would also be garbage (U+0041 'A' would be seen as U+4100 '䄀', etc). But in UTF-8 (which is what smile.amazon.com is using), they're simply different byte sequences: BOM (U+FEFF) is xEF xBB xBF, while U+FFFE is xEF xBF xBE.

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1575315 - Add noncharacter codepoints to those for which we never attempt font fallback. r=dholbert

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #0)

I have evidence from a former coworker that when he visits smile.amazon.com the content process apparently is locked for 30s (profile to come after it's scrubbed), all doing gfxFontFamily::FindFontForChar \uffe <fontname>

I guess he must have a lot of fonts installed. On my MBPro, I see just under one second there if I load smile.amazon.com in a newly-launched browser. (Or could there be something -- e.g. antivirus software -- that's causing disk access to be very slow for him?)

Anyhow, the patch above basically eliminates all this FindFontForChar stuff from the loading of smile.amazon.com in my testing.

Comment 4

[Michael Sinz]

(In reply to Jonathan Kew (:jfkthame) from comment #3)

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #0)

I have evidence from a former coworker that when he visits smile.amazon.com the content process apparently is locked for 30s (profile to come after it's scrubbed), all doing gfxFontFamily::FindFontForChar \uffe <fontname>

I guess he must have a lot of fonts installed. On my MBPro, I see just under one second there if I load smile.amazon.com in a newly-launched browser. (Or could there be something -- e.g. antivirus software -- that's causing disk access to be very slow for him?)

Anyhow, the patch above basically eliminates all this FindFontForChar stuff from the loading of smile.amazon.com in my testing.

I do have a reasonable number of fonts installed - I use this Mac for some design work in addition to coding. Across User and System fonts, there are over 2700, but that counts things such as different weights, strokes, and obliques. (For example, my professional fonts tend to come with 12 to 16 variations just due to the mix)

It is worst if it is the first time after a reboot since the OS has not cached that much of the system yet. (I have found other programs that, for some unknown reason, fully load all fonts at the start just in case they would like to customize something - in all but one case there was zero need for that and yet it would make program startup take nearly 30 seconds and on fast MacBookPro with a very fast SSD)

I keep wondering if I could sequester those fonts and only "install" them when doing design work but then I think that it should not be up to me to work around poor software but to get the software to be better. (PS - I like your patch - that will help in all but the worst cases of rarely use UNICODE code points such as some of the newly designed ones)

Comment 5

[Michael Sinz]

(In reply to Michael Sinz from comment #4)

(In reply to Jonathan Kew (:jfkthame) from comment #3)

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #0)

I have evidence from a former coworker that when he visits smile.amazon.com the content process apparently is locked for 30s (profile to come after it's scrubbed), all doing gfxFontFamily::FindFontForChar \uffe <fontname>

I guess he must have a lot of fonts installed. On my MBPro, I see just under one second there if I load smile.amazon.com in a newly-launched browser. (Or could there be something -- e.g. antivirus software -- that's causing disk access to be very slow for him?)

Anyhow, the patch above basically eliminates all this FindFontForChar stuff from the loading of smile.amazon.com in my testing.

I do have a reasonable number of fonts installed - I use this Mac for some design work in addition to coding. Across User and System fonts, there are over 2700, but that counts things such as different weights, strokes, and obliques. (For example, my professional fonts tend to come with 12 to 16 variations just due to the mix)

It is worst if it is the first time after a reboot since the OS has not cached that much of the system yet. (I have found other programs that, for some unknown reason, fully load all fonts at the start just in case they would like to customize something - in all but one case there was zero need for that and yet it would make program startup take nearly 30 seconds and on fast MacBookPro with a very fast SSD)

I keep wondering if I could sequester those fonts and only "install" them when doing design work but then I think that it should not be up to me to work around poor software but to get the software to be better. (PS - I like your patch - that will help in all but the worst cases of rarely use UNICODE code points such as some of the newly designed ones)

PS - I just noticed this happens even when not first starting the browser - I just had not been on Amazon.com for a few hours and I opened new tab on Amazon and again a many (20+) second such delay. Switching tabs gets the tab to be blank and just the rotating circle in the middle.

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to Michael Sinz from comment #5)

I do have a reasonable number of fonts installed - I use this Mac for some design work in addition to coding. Across User and System fonts, there are over 2700, but that counts things such as different weights, strokes, and obliques. (For example, my professional fonts tend to come with 12 to 16 variations just due to the mix)

If that's the total of all faces, not just font families, it doesn't seem excessive to me. I'm not involved in design-type work, but Font Book says I have over 500 font families, although quite a few of them (maybe 50-plus) are currently disabled. Still, with multiple styles per family in many cases, I'm sure there are well over 1000 individual faces....

It is worst if it is the first time after a reboot since the OS has not cached that much of the system yet. (I have found other programs that, for some unknown reason, fully load all fonts at the start just in case they would like to customize something - in all but one case there was zero need for that and yet it would make program startup take nearly 30 seconds and on fast MacBookPro with a very fast SSD)

....yet I don't see programs taking anywhere near that amount of time to load fonts; not more than a second or so. (Which is still an undesirable delay, especially if it blocks loading a web page or something like that.) I do wonder, therefore, whether there's something about your system configuration that is making it substantially slower to read the fonts.

I keep wondering if I could sequester those fonts and only "install" them when doing design work but then I think that it should not be up to me to work around poor software but to get the software to be better. (PS - I like your patch - that will help in all but the worst cases of rarely use UNICODE code points such as some of the newly designed ones)

Right, it'll still be possible to hit this issue, if a page includes a valid Unicode character that is not actually supported by any available font. That's fairly rare on modern OSes, which ship a pretty extensive set of preinstalled fonts, but it'll still happen sometimes.

PS - I just noticed this happens even when not first starting the browser - I just had not been on Amazon.com for a few hours and I opened new tab on Amazon and again a many (20+) second such delay. Switching tabs gets the tab to be blank and just the rotating circle in the middle.

That doesn't surprise me; the new tab may be running in a new content process which hasn't yet loaded all the font data. This will improve once the shared font-list is enabled (you can set gfx.e10s.font-list.shared = true in about:config if you want to try it out), as the fonts will no longer need to be enumerated separately by each process.

Comment 7

[Michael Sinz]

(In reply to Jonathan Kew (:jfkthame) from comment #6)

(In reply to Michael Sinz from comment #5)

PS - I just noticed this happens even when not first starting the browser - I just had not been on Amazon.com for a few hours and I opened new tab on Amazon and again a many (20+) second such delay. Switching tabs gets the tab to be blank and just the rotating circle in the middle.

That doesn't surprise me; the new tab may be running in a new content process which hasn't yet loaded all the font data. This will improve once the shared font-list is enabled (you can set gfx.e10s.font-list.shared = true in about:config if you want to try it out), as the fonts will no longer need to be enumerated separately by each process.

That did make a difference once I restarted Firefox (must be a restart required type of change).

Plus, just in quick browsing across the tabs I had open (and now reloaded), the browser seems to be faster (maybe less RSS memory - but that is hard to check in such a quick thing - especially since I was not looking to investigate that)

But the good thing is that after the first visit to smile.amazon.com (or amazon.com) I can now open a new tab, go to smile.amazon.com and then type into the page's search text box right away and not many seconds later. (Albeit the first connection did still cost quite a bit)

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3ba2717d59ff
Add noncharacter codepoints to those for which we never attempt font fallback. r=dholbert

Comment 9

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/3ba2717d59ff