Closed
Bug 668758
Opened 13 years ago
Closed 13 years ago
@font-face rules can interfere with generic-font prefs
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jfkthame, Assigned: jfkthame)
References
Details
Attachments
(3 files, 2 obsolete files)
809 bytes,
text/html
|
Details | |
3.29 KB,
patch
|
jtd
:
review+
|
Details | Diff | Splinter Review |
12.36 KB,
patch
|
jtd
:
review+
|
Details | Diff | Splinter Review |
CSS generics such as 'serif' are mapped to (language-dependent) font family names on the platform via the font preferences such as font.default.serif.x-western.
However, if a @font-face rule happens to use the same family name as was used in the font prefs, the downloaded font will be used instead of the original platform font.
Is this expected behavior? It seems wrong to me; I'd expect the mapping of generics to platform fonts via the preferences to be unaffected by @font-face usage on the page.
Assignee | ||
Comment 1•13 years ago
|
||
This demonstrates the unexpected interaction on OS X, and should work similarly on Windows AFAICS.
Assignee | ||
Comment 2•13 years ago
|
||
Attachment #543384 -
Attachment is obsolete: true
Assignee | ||
Comment 3•13 years ago
|
||
Assuming the current behavior is not actually wanted, here's an attempt to fix it by passing a flag in gfxFontGroup::ForEachFontInternal to tell it whether it should be checking the user font set or not.
Assignee: nobody → jfkthame
Attachment #543419 -
Flags: review?(jdaggett)
Assignee | ||
Comment 4•13 years ago
|
||
Attachment #543420 -
Flags: review?(jdaggett)
Assignee | ||
Comment 5•13 years ago
|
||
Updated to fix build failure on Linux.
Attachment #543419 -
Attachment is obsolete: true
Attachment #543525 -
Flags: review?(jdaggett)
Attachment #543419 -
Flags: review?(jdaggett)
Comment 6•13 years ago
|
||
Comment on attachment 543525 [details] [diff] [review]
patch, don't look up prefs font families in the user font set
Looks good but we really need to clean up the generic family code at some point, it's somewhat silly that we're parsing "serif" at this level. dbaron and I talked about this briefly in the past, I think we should be passing in a font list in an array with generics as special tokens, since the style system has already resolved these. But that's going to take a lot of effort to untangle existing code across platforms.
Attachment #543525 -
Flags: review?(jdaggett) → review+
Updated•13 years ago
|
Attachment #543420 -
Flags: review?(jdaggett) → review+
...which is bug 280443 (at least mostly).
Assignee | ||
Comment 8•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/51b49a7cf2e4 (patch)
http://hg.mozilla.org/mozilla-central/rev/fe33af7f6fa9 (test)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•13 years ago
|
||
Argh, this caused a build failure in gfxFT2Fonts on Android.
Backed out:
http://hg.mozilla.org/mozilla-central/rev/854daee4377c
http://hg.mozilla.org/mozilla-central/rev/84bc1d07bacc
http://hg.mozilla.org/mozilla-central/rev/931f06b80727
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 10•13 years ago
|
||
Re-landed, with the android bustage fixed:
http://hg.mozilla.org/mozilla-central/rev/812aa60517a7
http://hg.mozilla.org/mozilla-central/rev/64ee37ef692e
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•