Internal font-list changes should not trigger frame reconstruction for print/preview documents
Categories
(Core :: Layout: Text and Fonts, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox82 | --- | fixed |
People
(Reporter: jfkthame, Assigned: jfkthame)
References
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
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.)
Assignee | ||
Comment 1•4 years ago
|
||
Depends on D87176
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 3•4 years ago
|
||
bugherder |
Description
•