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

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

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

Need to investigate whether this was fixed by bug 451426.

It appears that it was.