[hardware error] crashes in dwrite.dll used via Skia during text-decoration rendering
Categories
(Core :: Graphics: Text, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox110 | --- | fixed |
People
(Reporter: jfkthame, Assigned: jfkthame)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
From https://support.mozilla.org/en-US/questions/1401188#answer-1557276:
bp-3c0b8913-94c4-4e7a-89cd-6defe0230102
bp-db6956a1-85f0-489d-b23c-2c81f0230102
bp-20217111-ae1f-4230-9ec1-ff3890230102
bp-107d0b45-b632-43f9-b77d-150f80230102
bp-5d584392-38f5-444b-af25-957160230102Just some of many.
Also to note- the issue is not present when using DuckDuckGo, but is present with the Tor browser.
The crash reports here are happening when Skia uses DirectWrite to get glyph outlines and compute decoration-line intercepts.
The reporter notes that it happens when hovering over a link (that'll be because of the underline that appears) and also that it doesn't happen on DuckDuckGo (that'll be because DDG uses a webfont, not whichever system font is encountering a disk read failure).
And the Tor browser presumably blocks webfonts, so then the hover-underlines on DDG do hit the same failure.
We can try catching the exception and just not doing the skip-ink thing in this case, and maybe that'll help. In general it seems likely some other operation with the same font (such as actually rendering it) will then hit the same problem, but we've been adding exception handling around many of those, too.
Ultimately, if the font is unusable we should fall back to another font from the list, which will be better than crashing the tab.
Assignee | ||
Comment 1•2 years ago
|
||
Better to just draw an unbroken underline than to crash the tab, in the event a Windows exception
occurs from deep inside skia/directwrite.
Updated•2 years ago
|
Comment 3•2 years ago
|
||
bugherder |
Description
•