See testcase, which crashes in current trunk build. I think this started happening when bug 339553 (which would be obvious), but it's probably a more fundamental cairo issue.

http://crash-stats.mozilla.com/report/index/afba12ca-404a-11dc-b12a-001a4bd46e84 0 _moz_cairo_win32_scaled_font_select_font 1 UniscribeItem::SelectFont() e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\gfx\thebes\src\gfxwindowsfonts.cpp:1126 2 UniscribeItem::Shape() e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\gfx\thebes\src\gfxwindowsfonts.cpp:917 3 gfxWindowsFontGroup::InitTextRunUniscribe(gfxContext*, gfxTextRun*, unsigned short const*, unsigned int) e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\gfx\thebes\src\gfxwindowsfonts.cpp:1542 4 gfxWindowsFontGroup::MakeTextRun(unsigned short const*, unsigned int, gfxTextRunFactory::Parameters const*, unsigned int) e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\gfx\thebes\src\gfxwindowsfonts.cpp:539 5 TextRunWordCache::MakeTextRun(unsigned short const*, unsigned int, gfxFontGroup*, gfxTextRunFactory::Parameters const*, unsigned int) e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\gfx\thebes\src\gfxtextrunwordcache.cpp:428 6 gfxTextRunWordCache::MakeTextRun(unsigned short const*, unsigned int, gfxFontGroup*, gfxTextRunFactory::Parameters const*, unsigned int) e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\gfx\thebes\src\gfxtextrunwordcache.cpp:642 7 gfxTextRunCache::MakeTextRun(unsigned short const*, unsigned int, gfxFontGroup*, gfxContext*, unsigned int, unsigned int) e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\gfx\thebes\src\gfxtextruncache.cpp:89 8 nsCanvasRenderingContext2D::MozTextAlongPath(nsAString_internal const&, int) e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\content\canvas\src\nscanvasrenderingcontext2d.cpp:1655 9 NS_InvokeByIndex_P e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp:101 10 AutoJSSuspendRequest::SuspendRequest() e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\xpconnect\src\xpcprivate.h:3312 11 js_LookupPropertyWithFlags e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\jsobj.c:3213

The problem is that cairo_scaled_font_create() fails when mAdjustedSize==0.0

Comment on attachment 274921 [details] [diff] [review] Patch rev. 1 + cairo_scaled_font_t* scaledFont = mCurrentFont->CairoScaledFont(); ' *' instead of '* ' please in all the instances in the patch.

Nit fixed. Checked in to trunk at 2007-08-06 05:30 PDT. -> FIXED

Mats, this testcase is now hanging for me also with current trunk build, like you mentioned in bug 378716, comment 3. Should this be reopened?

When I tested this (and bug 378716) in a local debug build just a few days ago it didn't hang, so I think some change has occurred (besides my patch) that made it hang. It looks like a mutex problem, I'm looking in to it. We can deal with it on bug 378716.

This fix is good bulletproofing, but we really need to figure out why mAdjustedSize is ending up as 0.0 -- this is going to be a problem across all the font backends in some situations, because a matrix with a 0.0 scale isn't invertible, and that's an error condition for cairo. Ideally, we should never end up with a mAdjustedSize of 0 -- or if we do, we should bail out very early and not do any additional work for that text. Cc'ing roc for thoughts, though maybe we should split this off into a separate bug.

I think it's entirely possible for CSS to specify a zero font-size. I think we should allow zero-sized gfxFont objects but not allow them to instantiate cairo fonts. Wherever we instantiate the cairo font, if it's zero-sized we do something special. For textrun creation we could create a font of size 1px for glyph conversion and then force all the advances, glyph positions and glyph bounds to zero. For drawing we just skip.

We may need to think about the consequences of cairo_scaled_font_create from cairo-1.5.x now returning a special nil font instead of NULL on failure. This seems to be the cause of bug 390787 at least.