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

Status: RESOLVED DUPLICATE of bug 451426

(Core :: Graphics, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Need to investigate whether this was fixed by bug 451426.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It appears that it was.