User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20100101 Firefox/16.0 Build ID: 20121024073032 Steps to reproduce: Just launched new website and used Google webfonts (Courgette ant Dosis latin-ext). Chrome renders all characters normally, including Lithuanian ones. FF somehow display just the latin font, not the latin extended part. Website test.tmlicejus.lt Actual results: Firefox does not display correct international webfont. Expected results: It should be displayed normally.

Do you have a testcase or an url where this can be seen?

Do you have a testcase or an url where this can be seen?

the url is http://test.tmlicejus.lt

(Note: that testcase exhibits the same problem on Chrome, because it only loads a subsetted, Latin-1-only version of the font; it's not comparable to the original site.) The problem on the http://test.tmlicejus.lt/ site is that it includes multiple calls to the Google Fonts APIs, requesting different versions of the font. First, near the beginning of the page, there's: <link href='http://fonts.googleapis.com/css?family=Dosis:400,700|Courgette&subset=latin-ext,latin' rel='stylesheet' type='text/css'> which requests all three webfonts, and specifies the latin-ext subset in addition to the basic latin subset. This works fine, and if that were the ONLY Google Fonts call, all would be well. However, later on the page, there are additional links: <link id='courgette' href='http://fonts.googleapis.com/css?family=Courgette' rel='stylesheet' type='text/css' /> <link id='dosis' href='http://fonts.googleapis.com/css?family=Dosis' rel='stylesheet' type='text/css' /> that re-specify the same font families, but do not request the latin-ext subset; as a result, these load the default (latin-1-only) subsets. Because of bug 465414 and bug 465450, Firefox only uses the last-specified of the multiple definitions for Courgette and Dosis Regular (note that the later link didn't ask for Dosis Bold, and so if there were any Dosis Bold text on the site - I didn't notice any - that would actually work as its font face hasn't been re-defined). So while I believe this behavior is indeed a bug (and have a patch in bug 677900 that would fix it, though doubtless it's bit-rotted badly by now...), the site is constructed in a less-than-ideal way, and causes Chrome (etc) to actually download two copies of each of these fonts, one that includes the extra Lithuanian characters *and* one that doesn't (which is redundant). The workaround for the site is to remove the extra Google Fonts links that don't include the latin-ext subset request.

(In reply to Jonathan Kew (:jfkthame) from comment #5) > > So while I believe this behavior is indeed a bug (and have a patch in bug > 677900 that would fix it, though doubtless it's bit-rotted badly by now...), Could you poke someone with the review right to quickly review the related patches of bug 677900? Why did they let a bunch of more than 1 year old patches getting bit rotted? This just wasted developers effort. I can see that the related webkit's effort also got wasted. I18n are always the 2nd citizens...

Testcase that demonstrates the problem as described in comment 5; renders correctly in Chrome and Safari, fails in Firefox.

IE8 & IE9 also renders perfectly, just Firefox fails.

No longer a problem, AFAICT. Presumably this got fixed as part of adding unicode-range support.