(In reply to Dragan from comment #26) > Maybe that explain some things, but not everything. If portals in Serbia have some special characters, websites from America don't, but there is still problem with different look. And the biggest question - why FF sees Arial in one case, and Helvetica in other, depending if it's true, or false? Looks like Jonathan addressed the Helvetica-vs-Arial thing in comment 19 -- that was an intentional behavior change as part of this feature, and the default pref value (i.e. `true`) makes us honor the website's requested font more-often (using Helvetica in this case). It's interesting/odd that Chrome is *not* honoring the website's request, though. In Jonathan's notes on this behavior in bug 1716433 comment 2, it sounds like we thought other browsers were doing roughly the same thing (but this seems like a case where Chrome is rejecting your Helvetica font and swapping in Arial instead, based on your Chrome screenshots in your original zip). > That's it guys, hope that you have some answers now, but if you don't, just give me another job to do! Until our final victory:-) I think the only unresolved thing now is the `[ ]` substitutions. As Jonathan said, we may've just landed a fix on Nightly (bug 1759891) that could help there - could you try downloading a Nightly build of Firefox at https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly and see if that substitution problem still happens in that build? (Note: nightly uses a separate profile [preferences/history/cookies/etc.] from regular Firefox, so no need to worry about it messing up your regular Firefox data.)
Bug 1721824 Comment 27 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Dragan from comment #26) > Maybe that explain some things, but not everything. If portals in Serbia have some special characters, websites from America don't, but there is still problem with different look. And the biggest question - why FF sees Arial in one case, and Helvetica in other, depending if it's true, or false? Looks like Jonathan addressed the Helvetica-vs-Arial thing in comment 19 -- that was an intentional behavior change as part of this feature, and the default pref value (i.e. `true`) makes us honor the website's requested font more-often (using Helvetica in this case, where previously [and with the pref set to False] we'd substitute Arial instead.) It's interesting/odd that Chrome is *not* honoring the website's request, though. In Jonathan's notes on this behavior in bug 1716433 comment 2, it sounds like we thought other browsers were doing roughly the same thing (but this seems like a case where Chrome is rejecting your Helvetica font and swapping in Arial instead, based on your Chrome screenshots in your original zip). > That's it guys, hope that you have some answers now, but if you don't, just give me another job to do! Until our final victory:-) I think the only unresolved thing now is the `[ ]` substitutions. As Jonathan said, we may've just landed a fix on Nightly (bug 1759891) that could help there - could you try downloading a Nightly build of Firefox at https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly and see if that substitution problem still happens in that build? (Note: nightly uses a separate profile [preferences/history/cookies/etc.] from regular Firefox, so no need to worry about it messing up your regular Firefox data.)