1681918 - Abandon use of shared font list if GetSystemFontCollection fails

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Jonathan Kew [:jfkthame]]

I've seen some Win7 content-process crashes on tryserver where it appears that DirectWrite in the content process starts failing, despite having initially worked at startup.

When a font-list reinitialization event happens (because the font info loader completes and triggers a global update -- or it could happen at arbitrary times if the user installs/removes a font), we have to re-fetch the system font collection in each process. But sometimes this fails:

https://treeherder.mozilla.org/logviewer?job_id=324150232&repo=try&lineNumber=23455-23457

That's bad news; we think we've got a usable shared font list (because the parent process successfully initialized it), but the child will crash as soon as we try to resolve a family/face record against its (non-existent) copy of the system font collection in gfxDWriteFontList::CreateFontEntry.

We should at least cleanly delete the shared font list in this case, and let the content process do its best to manage its own in-process list. (This may also fail, of course; if DirectWrite doesn't recover, we're pretty much doomed, as the content process will be unable to use any fonts.)

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1681918 - Don't try to use the shared font list in a content process if DWrite failed to get a reference to the system font collection. r=lsalzman

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0528806ca4a0
Don't try to use the shared font list in a content process if DWrite failed to get a reference to the system font collection. r=lsalzman

Comment 3

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/0528806ca4a0