Closed Bug 1536875 Opened 9 months ago Closed 5 months ago

FON fonts crash firefox with cairo content backend

Categories

(Core :: Graphics: Text, defect, P5)

66 Branch
x86_64
Windows 10
defect

Tracking

()

RESOLVED WORKSFORME
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)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0

Steps to reproduce:

  1. in about:config set: gfx.content.azure.backends=cairo; close firefox.
  2. 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.
  3. 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)

Can you please post the crash id from about:crashes ?
https://support.mozilla.org/en-US/kb/mozillacrashreporter

Flags: needinfo?(bugzilla.hundreAd)
Flags: needinfo?(bugzilla.hundreAd)
Crash Signature: [@ nsLineLayout::ReflowFrame ]
Component: Untriaged → Layout: Tables
Keywords: crash
Product: Firefox → Core
Component: Layout: Tables → Layout: Text and Fonts

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?

Flags: needinfo?(jfkthame)
Flags: needinfo?(bugzilla.hundreAd)

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

Flags: needinfo?(bugzilla.hundreAd)

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

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

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.

Flags: needinfo?(jfkthame)

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?

Component: Layout: Text and Fonts → Graphics: Text
Flags: needinfo?(lsalzman)

It's basically unsupported. We have been talking about disallowing even configuring it via pref since people really shouldn't be using it anymore.

Flags: needinfo?(lsalzman)

(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

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...

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?

Flags: needinfo?(bugzilla.hundreAd)

(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.

Flags: needinfo?(bugzilla.hundreAd)

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.

OS: Unspecified → Windows
Priority: -- → P5
Summary: FON fonts crash firefox → FON fonts crash firefox with cairo content backend
Whiteboard: [gfx-noted]

(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?

(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.

(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.

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

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

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.

(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?

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

(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.

Status: UNCONFIRMED → RESOLVED
Closed: 5 months ago
Depends on: 1559810
OS: Windows → Windows 10
Hardware: Unspecified → x86_64
Resolution: --- → WORKSFORME

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
You need to log in before you can comment on or make changes to this bug.