1659259 - Internal font-list changes should not trigger frame reconstruction for print/preview documents

Status: RESOLVED FIXED

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

Description

[Jonathan Kew [:jfkthame]]

If there's a change to the font list, we trigger frame reconstruction here. But in the case of a static-clone document used for printing or print-preview, this is undesirable because the nsPrintJob is holding weak refs to frames that will get blown away unexpectedly by this reconstruction.

Better to have the prescontext for print/preview docs just ignore the font-list update and keep its existing frame tree.

(I'm not sure it makes sense for print/preview docs to pay attention to any of the prefs changes here, really, but that's a wider question; the font-list update frame reconstruction is the most immediate concern because this can cause failures in some of our print reftests, if the post-startup deferred font info loader happens to complete, triggering a font-list refresh, at exactly the wrong moment during the test.)

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1659259 - Don't reconstruct frames as a result of font-list refresh if we're in a printing or print-preview context. r=emilio

Depends on D87176

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ac29f8757e96
Don't reconstruct frames as a result of font-list refresh if we're in a printing or print-preview context. r=emilio

Comment 3

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/ac29f8757e96