[Windows] should fall back through multiple downloadable fonts in 'font-family' property reliably (now works randomly)

RESOLVED DUPLICATE of bug 451426

Status

()

Core
Graphics
P3
normal
RESOLVED DUPLICATE of bug 451426
9 years ago
9 years ago

People

(Reporter: dbaron, Assigned: jtd)

Tracking

Trunk
x86
Windows XP
Points:
---
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
Right now, on windows, font fallback through more than one downloadable font only works some of the time.

Steps to reproduce:
   1. copy layout/reftests/fonts/ and layout/reftests/font-face/ to a Web server (right now, I have them on http://dbaron.org/tmp/reftest/font-face/ if you want to use that copy).  (This is required because of security restrictions on cross-directory loads for file: URLs.  The reftest harness runs them as HTTP reftests.)
   2. load layout/reftests/font-face/multiple-in-family-1.html (e.g., at http://dbaron.org/tmp/reftest/font-face/multiple-in-family-1.html ) and then reload it a bunch of times

Expected results: All the As and Bs should be replaced by a glyph of three rectangles on top of each other (smallest at the top).

Actual results:  The As are always replaced.  However, on some of the reloads the Bs are replaced and on some they are not.



When you're testing this bug, I recommend putting "patch 8" from bug 457821 (currently attachment 348597 [details] [diff] [review]) in your tree, because that bug can cause other confusion.


When this bug is fixed, we should be able to remove all of the "random-if(MOZ_WIDGET_TOOLKIT=="windows") markings from layout/reftests/font-face/reftest.list.  (Note that some of the cases where that marking is present involve multiple @font-face rules that are defining the same font descriptors other than 'src' (where the behavior is still somewhat controversial), and some involve multiple distinct font families listed in the 'font-family' property (where the behavior is already precisely defined).  However, given that we don't yet support the 'unicode-range' descriptor I feel pretty strongly that we need to use both of the @font-face rules when a pair of @font-face rules differ only by 'src'.)
(Reporter)

Updated

9 years ago
Flags: blocking1.9.1?
(Reporter)

Comment 1

9 years ago
(In reply to comment #0)
> (Note that some of the cases where
> that marking is present involve multiple @font-face rules that are defining the
> same font descriptors other than 'src' (where the behavior is still somewhat
> controversial), and some involve multiple distinct font families listed in the
> 'font-family' property (where the behavior is already precisely defined). 
> However, given that we don't yet support the 'unicode-range' descriptor I feel
> pretty strongly that we need to use both of the @font-face rules when a pair of
> @font-face rules differ only by 'src'.)

Er, sorry, that's actually not the case.  I'll file a separate bug on those issues.
(Reporter)

Updated

9 years ago
Summary: [Windows] should fall back through multiple downloadable fonts reliably → [Windows] should fall back through multiple downloadable fonts in 'font-family' property reliably (now works randomly)
(Reporter)

Comment 2

9 years ago
(I filed it as bug 465414, which is somewhat related.  It might even be fix-both-at-the-same-time level of related.)
(Assignee)

Updated

9 years ago
Assignee: nobody → jdaggett
(Assignee)

Updated

9 years ago
Priority: -- → P3
(Reporter)

Comment 3

9 years ago
Need to investigate whether this was fixed by bug 451426.
(Reporter)

Comment 4

9 years ago
It appears that it was.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 451426
Flags: blocking1.9.1? → blocking1.9.1+
You need to log in before you can comment on or make changes to this bug.