Last Comment Bug 494360 - [@font-face] font family names should hide platform fonts, even when errors occur
: [@font-face] font family names should hide platform fonts, even when errors o...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Jonathan Kew (:jfkthame)
:
Mentors:
http://people.mozilla.org/~jdaggett/f...
Depends on: 623711
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-22 01:29 PDT by John Daggett (:jtd)
Modified: 2011-07-06 00:07 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
reftests (10.39 KB, patch)
2009-05-22 01:40 PDT, John Daggett (:jtd)
no flags Details | Diff | Review
reftests, updated (11.01 KB, patch)
2011-07-01 06:19 PDT, Jonathan Kew (:jfkthame)
jd.bugzilla: review+
Details | Diff | Review

Description John Daggett (:jtd) 2009-05-22 01:29:01 PDT
When an @font-face face fails to load for a font family that matches an existing platform font we load the platform font instead of falling back to the next font in the fallback list.

For example:

@font-face {
  font-family: Arial;
  src: url(font.ttf);
}

body { font-family: Arial, serif; }

In this situation, text on the page should *never* display with Arial, it should either display with font.ttf or with a serif font.  The testcase URL includes @font-face rules with intentionally bad URL's, so the text should appear using a serif face.

The root of the problem here is that the user font set lookup only returns yes/no for whether a font is loaded.  It should return not-found, found-loaded and found-not-yet-loaded.  In the found-not-yet-loaded, the font lookup should skip the platform font lookup.
Comment 1 John Daggett (:jtd) 2009-05-22 01:40:39 PDT
Created attachment 379080 [details] [diff] [review]
reftests

Reftests for testing this, with and without URL's that point at valid font data.
Comment 2 Frank Wein [:mcsmurf] 2009-05-22 05:11:43 PDT
Why was I CCed to this bug here? Does this bug here have something to do with another bug?
Comment 3 Jonathan Kew (:jfkthame) 2011-02-24 02:33:57 PST
I've been working on a patch for bug 623711 that should also fix this.
Comment 4 Jonathan Kew (:jfkthame) 2011-07-01 06:19:08 PDT
Created attachment 543410 [details] [diff] [review]
reftests, updated

The primary bug here was fixed in bug 623711, but the original reftests didn't quite work as written; updated them so as to pass reliably.

Note that bug 668758 also interacts with this issue (and is one reason for problems with the original tests here); that needs an additional patch and its own tests, but I'd like to go ahead and land these tests and resolve this bug.
Comment 5 Jonathan Kew (:jfkthame) 2011-07-06 00:07:14 PDT
Landed tests:
http://hg.mozilla.org/mozilla-central/rev/7daa4cc9fb07

Marking this as Fixed now that we have tests in place (the actual code fix happened in bug 623711).

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