FON fonts crash firefox with cairo content backend
Categories
(Core :: Graphics: Text, defect, P5)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr60 | --- | disabled |
| firefox-esr68 | --- | disabled |
| firefox67 | --- | disabled |
| firefox68 | --- | disabled |
| firefox69 | --- | unaffected |
People
(Reporter: bugzilla.hundreAd, Unassigned)
References
Details
(Keywords: crash, regression, Whiteboard: [gfx-noted])
Crash Data
Attachments
(3 files)
debug output window for crash
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Steps to reproduce:
- in about:config set: gfx.content.azure.backends=cairo; close firefox.
- under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes" add "Segoe UI" (REG_SZ); set data value to a FON font, e.g. "Courier" (NOT "Courier New" which is a TTF); sign out or reboot for windows to process font registry settings.
- launch firefox; trying to use the url line (typing, clicking the "show history" dropdown button) causes an immediate crash.
Actual results:
crash
Expected results:
no crash
this font issue is NOT limited only to the url line. for example, try saving the following as .HTML and loading it:
<html><title>דילים למסעדות, עיצוב וכושר, נופש ותיירות, מוצרים, ספא ויופי ועוד | גרו (גרופון)</title></html>
the above comment will reproduce the crash once steps 1+2 are followed (in effect, an alternative to step 3)
|
||
Comment 3•5 years ago
|
||
Can you please post the crash id from about:crashes ?
https://support.mozilla.org/en-US/kb/mozillacrashreporter
id = f05372c2-2281-4272-867c-1bc830190321 (https://crash-stats.mozilla.com/report/index/f05372c2-2281-4272-867c-1bc830190321)
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
||
Comment 5•5 years ago
|
||
The STR are a bit mysterious to me as a non-Windows user. Maybe Jonathan has a better idea?
Is there any chance you can try a debug build from taskcluster, like: https://queue.taskcluster.net/v1/task/GEiPRZgzS92gOy80WsdsHw/runs/0/artifacts/public/build/target.zip
And attach the debug output of the program?
i have no idea what STR means, but i have installed the version from your link and reproduced the bug. however, on crash the debug window closes as well... eventually i did manage to get a screen capture (attached) showing the last lines of the debug output
i have no idea what STR means, but i have installed the version from your link and reproduced the bug. however, on crash the debug window closes as well... eventually i did manage to get a screen capture (see attachment) showing the last lines of the debug output
|
|
||
Comment 8•5 years ago
|
||
STR means "steps to reproduce", sorry. Thanks for that, it's useful :)
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)
The STR are a bit mysterious to me as a non-Windows user.
as a different way to perform step #2, save the following as a .REG file and load it (don't forget to sign out or reboot afterwards):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]
"Segoe UI"="Courier"
that's it for windows, the rest is purely firefox
|
||
Comment 10•5 years ago
|
||
Yes, I can confirm forcing the use of the cairo backend + bitmap (.fon) Courier in place of Segoe UI as default UI font, as described, leads to a crash.
Given that this involves tweaking both the Windows registry and Firefox about:config settings, I doubt it's really a high priority issue in itself, but it may indicate a more general bug (e.g. in the GDI fonts backend) that could occur in other circumstances as well.
|
|
||
Comment 11•5 years ago
|
||
Looking at the crash report, there are a bunch of GraphicsCriticalError messages recorded, e.g.
|[0][GFX1-]: Invalid target in gfxContext::CreateOrNull 000001F85705E8E0 (t=81.1766)
|[32][GFX1-]: DrawTargetCairo::Snapshot with bad surface 000001F857068A40, context 000001F858010800, status 0 (t=174.297)
etc.
Lee, what's the status of the cairo backend these days - is it supposed to be working? Could users potentially run into this even without tinkering with prefs in about:config?
|
||
Comment 12•5 years ago
|
||
It's basically unsupported. We have been talking about disallowing even configuring it via pref since people really shouldn't be using it anymore.
|
Reporter | |
Comment 13•5 years ago
|
||
(In reply to Lee Salzman [:lsalzman] from comment #12)
people really shouldn't be using it anymore.
sadly, only cairo results in crisp -- rather than horribly blurry -- fonts (see attachment). skia simply cannot (afaik) be made to respect the text rendering used by windows:
- advanced system settings->performance->smooth edges of screen fonts = enabled
- cleartype = disabled
|
|
||
Comment 14•5 years ago
|
||
Looks like with these settings, the cairo backend is snapping glyph positions to pixels, whereas skia is not. That may mean skia gives more even spacing overall (?), but at the cost of less consistent rendering of the individual glyphs because they may not be aligned to the pixel grid.
IIRC, gfxFont::GetRoundOffsetsToPixels is supposed to tell the text shaping code whether to snap glyphs to pixel offsets, but I don't know how this interacts with different gfx backends...
|
|
||
Comment 15•5 years ago
|
||
Does setting the "gfx.font_rendering.cleartype_params.rendering_mode" pref to the value 2 allow things to look better when ClearType/Skia are enabled?
|
|
Reporter | |
Comment 16•5 years ago
|
||
(In reply to Lee Salzman [:lsalzman] from comment #15)
Does setting the "gfx.font_rendering.cleartype_params.rendering_mode" pref to the value 2 allow things to look better when ClearType/Skia are enabled?
not really...
skia's rendering_mode mainly affects text width, so that a value of 2 will render identically to cairo as far as width is concerned; compare top/center to bottom -- the "be" is wordwrapped to the next line.
however, cleartype antialiasing is used regardless; compare the crisp top to the blurry center/bottom -- zooming to ~400% makes the differences obvious (i'm using Minimum font size of 20).
all this is of course not directly related to the ff-crashing-bug, although if i were able to use skia the issue would of course be sidestepped.
|
|
||
Comment 17•5 years ago
•
|
||
I tried following the STR and was not able to reproduce this. Though there was a change in the rendering, and I was indeed using the Cairo content backend, no crash occurred.
|
|
Reporter | |
Comment 18•5 years ago
|
||
(In reply to Lee Salzman [:lsalzman] from comment #17)
I tried following the STR and was not able to reproduce this. Though there was a change in the rendering, and I was indeed using the Cairo content backend, no crash occurred.
did you try Comment 1?
|
||
Comment 19•5 years ago
|
||
|
|
||
Comment 20•5 years ago
|
||
The tab will crash when open the page https://onedrive.live.com/download?cid=F96BA52A2AF70D03&resid=F96BA52A2AF70D03%211493&authkey=ABl5QN3bz-_RxyM.
Crash report: bp-711bc518-971e-42c6-85f0-297980190425
|
|
||
Comment 21•5 years ago
|
||
(In reply to blinky from comment #20)
The tab will crash when open the page https://onedrive.live.com/download?cid=F96BA52A2AF70D03&resid=F96BA52A2AF70D03%211493&authkey=ABl5QN3bz-_RxyM.
Crash report: bp-711bc518-971e-42c6-85f0-297980190425
Tried with this testcase as well, still no crash even with the pref and registry settings.
|
|
Reporter | |
Comment 22•5 years ago
|
||
(In reply to Lee Salzman [:lsalzman] from comment #21)
(In reply to blinky from comment #20)
The tab will crash when open the page https://onedrive.live.com/download?cid=F96BA52A2AF70D03&resid=F96BA52A2AF70D03%211493&authkey=ABl5QN3bz-_RxyM.
this does NOT crash ff not me, just the tab.
Tried with this testcase as well, still no crash even with the pref and registry settings.
if everything is set correctly, you should be seeing ff using courier (NOT courier new) as its font
also, did you try Comment 1?
i have reproduced it on 2 different computers plus a virtual machine (i.e.: no changes from default windows 10 installations except for STR); also confirmed by Jonathan Kew (:jfkthame) in Comment 10.
|
|
Reporter | |
Comment 23•5 years ago
|
||
nightly 2017-11-23 WORKS
nightly 2017-11-24 CRASHES
build_date: 2017-11-24
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2017/11/2017-11-24-22-03-17-mozilla-central/firefox-59.0a1.en-US.win64.zip
changeset: e8ce4865e42125850e6371eba3c5e71cf5ab6d29
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4cdfb92b93e1c51402aac4a4637c4798f5358d25&tochange=e8ce4865e42125850e6371eba3c5e71cf5ab6d29
|
|
Reporter | |
Comment 24•5 years ago
|
||
build_date: 2017-11-23
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2017/11/2017-11-23-22-01-10-mozilla-central/firefox-59.0a1.en-US.win64.zip
changeset: 0bb0f14672fdda31c19aea1ed829e050d693b9af
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0bb0f14672fdda31c19aea1ed829e050d693b9af&tochange=e8ce4865e42125850e6371eba3c5e71cf5ab6d29
|
|
||
Comment 25•5 years ago
|
||
That checkin look suspicious
Jonathan Kew — Bug 1403302 - patch 3 - Remove direct cairo dependency from gfxTextRun and gfxGlyphExtents. r=bas
Jonathan Kew — Bug 1403302 - patch 2 - Fix mixed-up glyph bounding box coordinates in ScaledFontDWrite::GetGlyphDesignMetrics. r=bas
Jonathan Kew — Bug 1403302 - patch 1 - Add missing return statement to ScaledFontBase::GetGlyphDesignMetrics, so that its cairo-based code path actually works. r=bas
|
|
||
Comment 26•5 years ago
|
||
Yes, that certainly seems a plausible culprit. I wonder if ScaledFontBase::GetGlyphDesignMetrics fails in the .fon bitmap-font case, or something like that. A stack from a debug build might give more details of exactly where the failure is happening.
|
|
Reporter | |
Comment 27•5 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #26)
A stack from a debug build might give more details of exactly where the failure is happening.
isn't the attachment from Comment 6 (https://bugzilla.mozilla.org/attachment.cgi?id=9058834) what you need?
|
|
Reporter | |
Comment 28•5 years ago
|
||
possibly the problem is that when characters that are NOT included in the .FON (e.g., non-english chars) are required, windows will fallback to other, .TTF fonts -- at which point GetCharWidth32 fails because GetCharWidth32 cannot be used on TrueType fonts according to the api reference
|
||
Comment 29•5 years ago
|
||
(Jonathan Kew (:jfkthame) from comment #10)
Yes, I can confirm forcing the use of the cairo backend + bitmap (.fon) Courier in place of Segoe UI as default UI font, as described, leads to a crash.
This crash should be prevented by:
Bug 1559810 - disallow Cairo as content/canvas backend. r=jrmuizel
See also bug 1557961 comment 8.
|
|
||
Comment 30•5 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Description
•