Closed Bug 789788 Opened 12 years ago Closed 9 years ago

Not allowing pages to choose their own fonts breaks with icon fonts

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Version:
15 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla41
Tracking Flags:
Tracking Status
firefox41 --- fixed

People

(Reporter: otsaloma, Assigned: jfkthame)

References

(Depends on 1 open bug)

Details

Attachments

(1 file, 3 obsolete files)

Revise the don't-use-document-fonts option so that it will prefer generics (as configured in prefs), but ignoring the 'cursive' and 'fantasy' values, but may still use page-specified fonts if necessary for fallback (e.g. icon fonts)
8.13 KB, patch
dbaron
: review+
Details | Diff | Splinter Review
Some websites have started using fonts to display icons (see e.g. github's octicons [1] and awesome [2]). If having set firefox to not allow pages to use their own fonts, one will see meaningless characters off a bizarre spectrum of unicode in place of those icons; see the images at fixhub [3] for an example. It would be good if the "allow pages to use their own fonts" setting would cover only normal text fonts and these icon fonts would be an exception, that would always use the page-specified font. I know these icon fonts are somewhat of a hack, but they seem to be getting more common and if it's technically feasible to fix this on the browser end, that would be cool. [1] https://github.com/blog/1106-say-hello-to-octicons [2] http://fortawesome.github.com/Font-Awesome/ [3] https://github.com/davidlazar/fixhub
Component: Preferences → Layout: Text
Product: Firefox → Core
Are these icon fonts using the private-use area (PUA), or are they using other Unicode ranges?
Alternatively, perhaps we should have a separate "Allow pages to use webfonts" setting and not overload the existing "Allow pages to use their own fonts" for webfonts?
... though I suppose that would only solve the problem for a subset of users :(
(In reply to David Baron [:dbaron] from comment #1) > Are these icon fonts using the private-use area (PUA), or are they using > other Unicode ranges? They are in the private use area. "We use the Private Use (Unicode) range to avoid conflicts with actual letters." https://github.com/styleguide/css/7.0 "Font Awesome uses the Unicode Private Use Area (PUA) to ensure screen readers do not read off random characters that represent icons" https://github.com/FortAwesome/Font-Awesome/blob/master/less/font-awesome.less
(In reply to Simon Montagu from comment #3) > ... though I suppose that would only solve the problem for a subset of users > :( Any site that's tyring to use a special "icon font" as part of its design really ought to be serving that font as a webfont, otherwise it's likely that many users will not be seeing the intended result.
Here's another one: http://meta.discourse.org/ I wonder if this hack will always come in the form of neatly contained PUA-only fonts. It sounds like Apple puts their logo into regular fonts, for example: https://en.wikipedia.org/wiki/U%2BF8FF#Example_code_point_U.2BF8FF So instead of making exceptions for PUA-only fonts, would it be feasible to allow any webfont specified by the page when it's used for individual characters from the PUA, and use the user-specified fonts otherwise? Either way, the user should be in control of this through some kind of "Allow icon fonts" setting.
(In reply to Alexander Dietrich from comment #6) > Either way, the user should be in control of this through some kind of > "Allow icon fonts" setting. An option like "Allow icon fonts" is basically unimplementable as phrased, because the browser has no way to know whether the glyph images in some arbitrary font are intended to be "icons" or if they're "letters". They're just shapes. In principle, "Allow webfonts for PUA codepoints" (without making assumptions as to whether icons or some other kind of symbols are involved) would be possible - it is at least well-defined what it would mean. But if authors are using webfonts to provide "icon glyphs" that replace arbitrary Unicode characters - which is definitely the case for some of the "icon fonts" out there[1] - there's no way the browser can be expected to magically discern this intention. Either you allow it to use the fonts that the author has specified, or you won't see the symbols the author intended. [1] For example, see http://css-tricks.com/examples/IconFont/
"Allow icon fonts" was just my stab at a user-friendly description of the setting. It's possible that I'm overestimating the accessibility of the term "icon font". "Allow webfonts for PUA codepoints" will be understood by almost nobody, IMHO. Under the hood I'd stick with allowing only PUA codepoints, there's only so much a program can do. Some more label suggestions: - "Allow pages to use symbols from web fonts" - "Allow web fonts for symbols" Not sure about "icon" vs. "symbol" and "web font" vs. "remote font".
(In reply to Alexander Dietrich from comment #6) > Either way, the user should be in control of this through some kind of > "Allow icon fonts" setting. I don't see why there should be a separate setting for this; we should probably just make an exception for the existing "Allow pages to use their own fonts" setting for codepoints in the PUA.
(In reply to David Baron [:dbaron] from comment #9) > I don't see why there should be a separate setting for this; we should > probably just make an exception for the existing "Allow pages to use their > own fonts" setting for codepoints in the PUA. The existing setting doesn't really imply that no external fonts will ever be downloaded, so yeah, that would be even better.
(In reply to David Baron [:dbaron] from comment #9) > (In reply to Alexander Dietrich from comment #6) > > Either way, the user should be in control of this through some kind of > > "Allow icon fonts" setting. > > I don't see why there should be a separate setting for this; we should > probably just make an exception for the existing "Allow pages to use their > own fonts" setting for codepoints in the PUA. To do this in a reasonable way (while avoiding lots of useless downloads in the case where the user has disabled "use their own fonts"), we'll need to ensure that we trigger the webfont download -only- if PUA codepoints are actually used. Currently, unless "use own fonts" is turned off, we will download any webfonts that are called for by the font-family property, regardless of whether they're going to be used for PUA codepoints or for regular text. Bug 754215 would help here, I think.
Depends on: 754215
(In reply to Simon Montagu from comment #2) > Alternatively, perhaps we should have a separate "Allow pages to use > webfonts" setting and not overload the existing "Allow pages to use their > own fonts" for webfonts? This seems like the right approach here. Distinguishing between PUA-only vs. non-PUA webfonts is a fool's errand I think.
(In reply to John Daggett (:jtd) from comment #12) > (In reply to Simon Montagu from comment #2) > > Alternatively, perhaps we should have a separate "Allow pages to use > > webfonts" setting and not overload the existing "Allow pages to use their > > own fonts" for webfonts? > > This seems like the right approach here. Distinguishing between PUA-only > vs. non-PUA webfonts is a fool's errand I think. Is the idea that it would be possible to allow pages to use webfonts without checking the other setting (allow pages to use fonts)? If so, we're going to need to rearchitect the latter setting anyway.
> (In reply to David Baron [:dbaron] from comment #9) > To do this in a reasonable way (while avoiding lots of useless downloads in > the case where the user has disabled "use their own fonts"), we'll need to > ensure that we trigger the webfont download -only- if PUA codepoints are > actually used. Currently, unless "use own fonts" is turned off, we will > download any webfonts that are called for by the font-family property, > regardless of whether they're going to be used for PUA codepoints or for > regular text. I'd suggest the user really doesn't mind the downloading of webfonts when setting "use own fonts", only that page fonts rendering of them as close as possible to his/her settings. For non-PUA codepoints this means their font, and for PUA code points, this means the webfont. I think it's appropriate to think of a PUA codepoints just like an image: they are binary blobs that have no semantics, and hence not translatable into another font. Hence, like an image, they should be used as the website specifies.
Any update on getting this fixed in the next version of Firefox? It's driving me crazy at the moment. Unicode characters show up fine if I allow websites to use their own fonts, but then the actual content is often unreadable (a lot of blogs in particular have started using a particularly terrible light Helvetica font).
For what it's worth, the current work-around I use is to allow pages to use their own fonts, but override them in my userContent.css with a long bunch of programmatically generated rules. @font-face { font-family: "Arial"; src: local("Open Sans"); } @font-face { font-family: "Arial"; font-style: italic; src: local("Open Sans Italic"); } @font-face { font-family: "Arial"; font-weight: bold; src: local("Open Sans Semibold"); } @font-face { font-family: "Arial"; font-style: italic; font-weight: bold; src: local("Open Sans Semibold Italic"); }
(In reply to craigwut from comment #16) > Any update on getting this fixed in the next version of Firefox? It's > driving me crazy at the moment. Unicode characters show up fine if I allow > websites to use their own fonts, but then the actual content is often > unreadable (a lot of blogs in particular have started using a particularly > terrible light Helvetica font). Hmm, not sure this is exactly what this bug is about. Seems like you just want to disable downloadable fonts, no? If that's the case you can set "gfx.downloadable_fonts.enabled" to false.
(In reply to Osmo Salomaa from comment #17) > For what it's worth, the current work-around I use is to allow pages to use > their own fonts, but override them in my userContent.css with a long bunch > of programmatically generated rules. > > @font-face { > font-family: "Arial"; > src: local("Open Sans"); > } Seems like it would be better to do this mapping via fontconfig. https://wiki.archlinux.org/index.php/Font_Configuration#Replace_fonts
(In reply to John Daggett (:jtd) from comment #19) > (In reply to Osmo Salomaa from comment #17) > > For what it's worth, the current work-around I use is to allow pages to use > > their own fonts, but override them in my userContent.css with a long bunch > > of programmatically generated rules. > > > > @font-face { > > font-family: "Arial"; > > src: local("Open Sans"); > > } > > Seems like it would be better to do this mapping via fontconfig. > https://wiki.archlinux.org/index.php/Font_Configuration#Replace_fonts Well, that would affect pretty much everything, right? Long ago I once tried it and PDFs in particular (in evince) looked quite awful since they don't "reflow" to match metrics of the replacement font. Also, for testing purposes I find it good to have another browser that shows web pages as most people see them.
(In reply to John Daggett (:jtd) from comment #18) > (In reply to craigwut from comment #16) > > Any update on getting this fixed in the next version of Firefox? It's > > driving me crazy at the moment. Unicode characters show up fine if I allow > > websites to use their own fonts, but then the actual content is often > > unreadable (a lot of blogs in particular have started using a particularly > > terrible light Helvetica font). > > Hmm, not sure this is exactly what this bug is about. Seems like you just > want to disable downloadable fonts, no? If that's the case you can set > "gfx.downloadable_fonts.enabled" to false. No, the request is basically the opposite of that: use downloadable fonts (in particular, for icon fonts; whether to allow them for non-PUA characters is open to debate), but apart from that, ignore fonts specified by the page's CSS, and use the user's preferred fonts instead. Or in other words, even when "Allow pages to choose their own fonts" is DISabled, still allow webfonts to be used [for PUA/icon codepoints].
(In reply to David Baron [:dbaron] (needinfo? me) (UTC+8) from comment #9) > I don't see why there should be a separate setting for this; we should > probably just make an exception for the existing "Allow pages to use their > own fonts" setting for codepoints in the PUA. Keep in mind that this would leave no setting to opt for not downloading *any* fonts, if that's what the user wants for whatever reason. Mostly, I would just like to see *something* done with this, as it's becoming a usability issue for several sites. The sourceforge wiki also uses this method in it's interface now.
(In reply to yawfle from comment #22) > Mostly, I would just like to see *something* done with this, as it's becoming a usability issue for several sites. The sourceforge wiki also uses this method in it's interface now. Yes, I've noticed it becoming more-and-more of an issue. Using icon fonts is really taking off now and increasingly more sites are using them. I *really* do not want to have to enable sites to be able to use their own fonts, 15+ years of using websites has shown this to be a bad idea. But not being able to see their PUA icons makes the sites unusable.
I also have this issue with coursera.org: on the pages of every class the icons appear as weird symbols if I try to use my own fonts. If not I have the icons and their ugly fonts
Just another vote for this one, it's been infuriating me for a year now and I only just figured out what was going on. +1 for the solution of using the site's font for non-standard unicode ranges even when firefox is set to disallow sites from picking their own fonts (and if anyone really really doesn't want that behaviour, maybe stick a more extreme preference in about:config or something).
This is not Mozilla problem, this is problem of web site developers, which use ugly letters for the rest of page text. They should use symbols from PUA only, but for normal text Arial or Verdana. I do not think mozilla should do anything about it. I think the solution is to disable page fonts, but map icons from PUA to a different font (may be to downloaded Awesome).
(In reply to aerique from comment #23) > I *really* do not want to have to enable sites to be able to use their own > fonts, 15+ years of using websites has shown this to be a bad idea. But not > being able to see their PUA icons makes the sites unusable. +1. I am irritated enough by this to try to fix it myself, but when I finally went to find out the nature of the problem, I expected there to be an extension that would do it. I don't think it's trivial but I admit I don't have any idea how non-trivial it really is. How about ExExceptions, could it be hacked into that? I would like to be able to say "show my specified fonts always, unless the site downloads a font, then only allow it to specify said font" i.e. let me say "let downloaded fonts override my fonts" next to, and independent of, "let sites choose". Plenty of sites ask for ordinary installed fonts (helvetica?) that are no fun to read, but I could still bear to see fancy typefaces here and there, and of course I always want to see those blessed icons. Since I'm making a wish, I would also like to have per-site overrides, for those that use something that looks like garbage if you univerally disabled sub-pixel hinting. But I know, it's just so easy to talk about, hard to do...
I would suggest three radio button options: 1. "Always use downloadable fonts" 2. "Avoid using downloadable fonts" 3. "Never use downloadable fonts" If 1. is selected, then it works the way the current option does when allowing downloadable fonts, and 99% of sites on the web will now be ugly but contain visible icons. If 2. is selected, the wording allows firefox to actually download fonts when it needs to. Whenever the lazy-downloading is implemented, then firefox would "need to" download less frequently. In the meantime, it will actually download always, since it doesn't promise not to. If 3. is selected, then it works the way the current option does when prohibiting downloadable fonts. Since firefox isn't going to use downloadable fonts under any circumstances, it is free to optimize by not downloading them at all. I haven't inspected the firefox sources at all, so this may be very naive. But what might make implementing this easier is to flag the internal font records as having originated from a download. Then, when inspecting the font for glyph presence, apply this logic which defines "need" for now: if(avoid && downloaded && !ispua) return false;
After seeing so many sites with actual glyphs where icons should be, I've started almost appreciating the boxes with hex codes pointing at the PUA or the 7-segment LCD-style debug codes in Bitstream Vera and DejaVu Sans at the beginning of the PUA, because they show at least someone did *something* right. But I'm with Lucas-- I feel these sites ought to be called broken, and I hope this neat trick with fonts is universally deprecated and goes the way of mystery meat navigation, because OH WAIT it *is* mystery meat navigation.
I agree too, they should be considered broken websites. In fact, perhaps a simpler solution for us would be an add-on which detects PUA glyphs being used when the downloadable fonts are disabled and automatically emails webmaster@domain with "Dear webmaster, before reading this email, I suggest you turn off downloadable fonts, because it is riddled with glyphs from an embedded custom font containing many very rude gestures and things you might not want to see at work. When you're ready, scroll down several lines... OK, ready? Now, before we proceed, please visit your domain.com and --wait, what's this? It makes no sense and is totally unusable? That's how it is for me, too. I hope you'll reconsider your use of font icons." When the webmasters are bombarded with half-dozens of emails, maybe they'll change their ways.
Haha, I was thinking about just sending them one by one to a page that says "You're websight iz brokan" at 48px... maybe as a green-on-magenta text region with a black background, followed by a casual "Was that painful to read? now we're even" and a short lecture about what's wrong with this picture. It could have a screenshot of their site in my browser with my preferences, maybe auto-generated. But, I can't afford to grab yourwebsiteisbroken.com, or much of anything other than good-looking free stuff like Firefox and DejaVu Sans. Sad note: When trying out a document-font-toggling extension (which only toggles the browser-wide setting), I saw for the first time that this bug tracker calls for a horribly fuzzy monospace font, too. I learned since my first comment that ExExceptions is really a friendly permissions.sqlite editor, not a security system, so a "download fonts" permission would have to be added to that database, then ExExceptions updated eventually... probably? I don't know how [not] easy it is to update the schema and have everything keep working. I also learned that I could do a lot for myself with userContent.css, but that apparently means knowing domain names and font names beforehand, or trying to match them up according to CSS elements where icons probably live, and I can't (or, I shouldn't expect lots of folks to) maintain personal black- and whitelists like that for the duration. Besides, they'll redesign their site, or grab a different template. This is madness. Standardizing a multi-image container format that uses vector font technology, instead of abusing it, should be easier than this. At least then the browser could *gasp* treat them as images, and the black/whitelist entries & global settings for images would already apply, but they wouldn't *have to*, because the font I want to see won't blow them all out. Because they were images. Neat. Let's see, how many years does that usually take? How long did it take for SVG to become a thing? Yes, I know... more of that "easy to talk about" from over here. I looked. dbaron was right, some things will need to get a bit more complex in order to handle this. Since this is unconfirmed, I suppose that means nobody is on it yet, so I'm going to dig around in nsPresContext.cpp for a while and see if I can see anything else like a way out.
I dont know much about all this but sourceforge at least puts pictos.svg in the long list of fonts it tries very hard to download. There must be some kind of standard for that. I just checked sourceforge and chrome can use the svg if the others are blocked, but firefox can't. For this particular case, the problem could be solved by offering individual control of `downloading` (assuming this includes cases where theyre embedded in the css) for EOT, WOFF, TTF, and SVG formats, since I suspect nobody is likely to use SVG right now for anything but icon fonts. I'm not sure how many sites would get saved by this. I just checked mailinator which uses every format but SVG. github offers the blasphemous octicon in all four formats, so it should be fixed by this. Disabling the EOT, WOFF, TTF, and SVG-font engines individually should be pretty easy to implement as a user preference...
(In reply to Rob Couto from comment #32) > Yes, I know... more of that "easy to talk about" from over here. I looked. > dbaron was right, some things will need to get a bit more complex in order > to handle this. Since this is unconfirmed, I suppose that means nobody is on > it yet, so I'm going to dig around in nsPresContext.cpp for a while and see > if I can see anything else like a way out. The current pref works by converting all page-specified 'font-family' styles to either 'monospace' or whichever of 'serif' or 'sans-serif' is the user's default. This is done in nsRuleNode::ComputeFontData. Fixing the bug would require removing the entire current implementation of the preference and reimplementing it in a different way. I'd suggest discussing designs before spending too much effort on them, since there might be problems that others here would bring up.
Also, it's worth considering a design that would also allow exposing a preference that addresses user fingerprinting through font detection.
(The fingerprinting issues are discussed in bug 732096.)
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #34) > (In reply to Rob Couto from comment #32) > The current pref works by converting all page-specified 'font-family' styles > to either 'monospace' or whichever of 'serif' or 'sans-serif' is the user's > default. This is done in nsRuleNode::ComputeFontData. > > Fixing the bug would require removing the entire current implementation of > the preference and reimplementing it in a different way. I'd suggest > discussing designs before spending too much effort on them, since there > might be problems that others here would bring up. Ahaha, I knew I was still just at the surface. Thanks for the tip :) (In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #35) > Also, it's worth considering a design that would also allow exposing a > preference that addresses user fingerprinting through font detection. And that's something I just recently found and started caring about, but I thought it was limited to Flash/Java because of the Panopticlick test results... so I apparently need to go learn all about the attacks. This explains how earlier today at Khan Academy, some symbols were missing for some seconds, and it eventually showed them and told me to enable downloading of fonts if I wanted it to work better. I'm not sure what they did-- render a picture of it? Was it client or serverside, was the delay due to their checking for fonts? Anyway, they were able to know... so yeah. Good call.
(In reply to mgambrell from comment #33) > I'm not sure how many sites would get saved by this. I just checked > mailinator which uses every format but SVG. github offers the blasphemous > octicon in all four formats, so it should be fixed by this. > > Disabling the EOT, WOFF, TTF, and SVG-font engines individually should be > pretty easy to implement as a user preference... TBH, I'd never heard of Mailinator, EOT, or WOFF before this, so you could say I'm the wrong person to be planning anything about it. Thanks also for the hints.
This is an increasingly difficult problem for me and I suspect others too. It has been going on for over a year. I'm new to bugzilla. I made an account just for this. What does it take to make this happen? I see this is marked as UNCONFIRMED. I suspect we could get this confirmed in a few minutes, right? Thanks!
Perhaps it should be implemented so if a downloadable page font exists and the preference is enabled, the downloadable font is used as a fallback if the glyph would otherwise be missing? Would also cover the scenario of a page specifying a downloadable font for text using an uncommon unicode block, and a non-preferred font should always be better than a "glyph not found" block. I haven't had a chance to look at the code that handles things like font substitution for missing glyphs, so I'm not sure how difficult this would be to implement, however.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It seems to me that the only way to satisfy everyone is to provide all of these: a way to write and/or pick rules, a good set of default rules, a domain whitelist and blacklist implemented in permissions.sqlite, a font-name whitelist and blacklist (somewhere?), and a regular movable icon out front which lets a person blacklist or whitelist a domain or a typeface in two clicks or less, a la NoScript. Yeah, I calmed down and remembered that I already "maintain" a whitelist constantly but I use a thing that makes it pretty easy and sadly I still don't expect the average person to get used to it as I have. So, the rules... I'm thinking that where the checkbox is now would be a drop-down selector instead, for which context we're considering and which ruleset is shown just below that. Sorry that I don't know a better word to use than context, since context means something already within FF source and I still don't know what exactly. When I say it here, I only mean "situation where particular font faces are desired". The three contexts I can think of so far are: * web pages in standard mode * web pages in private browsing mode * built-in PDF viewer For each context, you would have something like the boolean option but the name would be shortened to "Allow pages to choose their own fonts" and if it was unchecked, a list box would be un-greyed and the font finally being used would be chosen by the first matching rule from the list. Each context would have 2 buttons for moving the currently highlighted item up and down in the list. Each list item would have a checkbox for disabling the rule except "my selections above" which would always be the fallback. The rules I can think of so far are (not suggesting any default order): * My selections above * System fonts named in the page, if domain-whitelisted * System fonts named in the page, if NOT domain-blacklisted * System fonts named in the page, if fontname-whitelisted * System fonts named in the page, if NOT fontname-blacklisted * Downloaded fonts named in the page, if (DL enabled and) domain-whitelisted * Downloaded fonts named in the page, if (DL enabled and) NOT domain-blacklisted * Downloaded fonts named in the page, if (DL enabled and) fontname-whitelisted * Downloaded fonts named in the page, if (DL enabled and) NOT fontname-blacklisted * System fonts named in userContent.css The reason for so many system/downloaded options is so the user could decide what list takes precedence if something should ever match more than one. A perfectly flexible rule system's UI would have another pair of buttons to add and remove items, and each item would be a row of drop-down selectors to build a rule out of those possible combinations. That would be more corner-case-proof and future-proof but harder to configure (for most people). For the internal PDF viewer, downloaded fonts don't make sense (or do they? or just not yet?) but last time I checked, the document-fonts option breaks that too, so it still goes here. If someone *wants* the current binary behavior, all they would have to do is uncheck the "allow pages to choose" and move the "My selections above" rule to the top of the list, in all 3 contexts. That's about as complex as I can see it needing to get. What do you think? What else (contexts & rule bases & rule criteria) belong in there? I think it would also be good to add a per-host font-download item (not the aforementioned font-choosing item) to permissions.sqlite but that's sort of a tangent, not about rendering. And I sort of confused the ideas of blacklists and whitelists in that DB-- it would be impossible for a domain to wind up on both lists as you apparently can't choose both allow and deny for a function. If the managed font names were stored in the same way but in a different DB, then the extra rules or rule criteria to make one list take precedence would be totally unnecessary. If FF can easily get error codes from every system's font API about the existence of a requested glyph, you could add a boolean "Allow substitution when a page contains missing characters" but given the direction the web is headed, I can already see some clever people making up their own font in some "blank" area of the character table (ignoring PUA again) then rot13-ishly shifting the page text over to it to trigger that setting and get back control over the presentation of their page. They already sort of proved that they don't care about the people who use browsers that can't or won't download fonts. So instead you would add a boolean option to each context, such that rule matches would fall through if a character doesn't exist, something like "Obtain missing characters from additional fonts within these rules". Or, if you went all-out iptables-style rule-construction-kit constructing, rules would have another criteria that simply says "and the character exists". I also think that this could really hurt rendering performance.
(In reply to Rob Couto from comment #41) > If the managed font names were stored in the same way but in > a different DB, then the extra rules or rule criteria to make one list take > precedence would be totally unnecessary. Also, if there was another DB that organized permissions according to font names, it would be easy to add things like per-font minimum size, override bold/italic/etc, and so on... for even more corner cases. Then you'd just need a FontExceptions addon (to go with ExExceptions) to handle them easily because it is probably overkill in the main program.
About that last note-- I forgot about overriding things in userContent.css, again, though I don't think you can do in CSS what you can do in CPP. I also forgot about things like Greasemonkey and Stylish. Some weeks ago when I was first thinking about rules, I figured those developers would have to be advised to play along-- anyone dealing in CSS would need to create a font priority rule (preferably naming the addon) during installation and should ask the user whether they want it moved to the top of the list. So, the rule-construction-kit seems the only way to go, at least under the hood. Maybe a small handful of coarse default rules would be part of the main program UI and the fine-grained controls would be buried in a custom settings mode like the Privacy page, unless left out for addons to pick up and handle.
I gave up and checked "Allow..." and started building a substitution list like Osmo Salomaa. It seems to work neatly if not conveniently, but now userContent.css doesn't override downloaded fonts. That seems awfully counter-intuitive but of course it's a different bug already (#827422) which would also be solved by that stack of options I described, which took more time to type than I've spent on adding common faces to be substituted.
Now that Rob has given up, I will ask. Is this not getting attention because the proposed solution is too difficult or because it doesn't have enough votes? I assume the latter, right?
The proposed solution (comment 9 / comment 11 / comment 21 / comment 34) is a lot of work, and it would be for a feature used by a pretty small fraction of users; more votes aren't going to make a difference. I think the material in comment 41 is largely orthogonal -- it's about automatically toggling the setting in different contexts rather than how to implement the setting in the first place. It's also way too complex to be in Firefox, although I could imagine it making sense in an extension (somewhat like NoScript).
I'm sorry, I know I shouldn't intrude, but if there is no hope for the proposed solution, I wonder if we could revisit some easier ones. What about comment 2? If I understand it correctly, that is what I was hoping would be implemented. How difficult would it be to just allow any downloaded fonts? All these icon fonts are used that way, right? I will not be surprised if this doesn't work for some reason; I don't really understand how it works. But, the Web is very uncomfortable to read, now, regardless of which setting I choose.
That wasn't actually a proposed solution, it was an outline of what might be the smallest number of variables required to cover all the possible ways a user could want or need to filter what winds up on their screen, just for discussion's sake.
(In reply to Osmo Salomaa from comment #17) > For what it's worth, the current work-around I use is to allow pages to use > their own fonts, but override them in my userContent.css with a long bunch > of programmatically generated rules. Is it possible to share this list? Perhaps we can keep it publicly updated like some kind of AdBlock list.
(In reply to aerique from comment #49) > (In reply to Osmo Salomaa from comment #17) > > For what it's worth, the current work-around I use is to allow pages to use > > their own fonts, but override them in my userContent.css with a long bunch > > of programmatically generated rules. > > Is it possible to share this list? Perhaps we can keep it publicly updated > like some kind of AdBlock list. I could share it, yes, but you can't make a general list out of this. What looks good and what looks bad depends individually on your screen, OS, font rendering stack, language, script, taste etc. I just replace everything bad I have encountered with Open Sans and Inconsolata (or Calibri and Consolas on Windows) using the template I posted. For people on this bugtracker, it should be trivial to generate to generate their own rules from a list of fonts and a template, and rest of the people need a check box.
(In reply to Porcelain Mouse from comment #47) > I'm sorry, I know I shouldn't intrude Don't be, you're not intruding. (In reply to Osmo Salomaa from comment #50) > (In reply to aerique from comment #49) > I could share it, yes, but you can't make a general list out of this. What > looks good and what looks bad depends individually on your screen, OS, font > rendering stack, language, script, taste etc. I also thought about posting mine somewhere but I agree, being a substitution table has the same problem of someone else deciding the result, so maybe there would be multiple 'font themes' around, maybe there already are-- and maybe not one of them is acceptable to you. > For people on this bugtracker, it > should be trivial to generate to generate their own rules from a list of > fonts and a template, and rest of the people need a check box. FWIW, I gave up on userContent.css as well because even though I can stand to hit Shift+Ctrl+C and copy-paste font names here and there, it just isn't powerful enough. I'm guessing that the team considers it to be just another stylesheet, not a user configuration file, based on the fact that it can't substitute a downloaded font and they're either not able or not willing to give it more priority than downloaded CSS. That's no problem because I learned something (yeah, again! that's like, 3 things already this month) --there are font substitution user scripts for Greasemonkey which go underneath all this nonsense by modifying the page, such as https://userscripts.org/scripts/show/150418 and suddenly my suggestion to tell Greasemonkey people to create a reorderable entry in a fall-through list seems pretty silly-- the selectors that are there now are already *inputs* to that user script when it substitutes with sans-serif/serif/monospace. Greasemonkey allows user scripts to save to and load from their own .sqlite file, so now I'm trying to work out the best way to present a UI for knocking out fonts without having to bother about their names, whether it's an extension that has to be used in conjunction with the script, or if it can simply be placed in/over the web page by the script. Either way, it'll probably be a while, but then it will work basically everywhere Greasemonkey works, incl. old versions of Firefox that won't get a fix even if it's accepted here, which IMHO is a huge plus.
(In reply to Rob Couto from comment #51) > FWIW, I gave up on userContent.css [...] based on the fact that it can't > substitute a downloaded font and [...] I've noticed this as well, but usually it isn't much of an issue. The horrible likes of Arial and Courier New aren't used as downloadable fonts. But on a site or two I've had to resort to a site-specific rule. @-moz-document domain(foo.com) { * { font-family: sans-serif !important; } } > --there are font substitution user scripts for Greasemonkey which go > underneath all this nonsense by modifying the page I vaguely remember trying something like this long ago and there were two problems: (1) the page began to display before some gm hooks were run causing the site to first be shown in its own font, then flicker, reflow and be shown in the replacement font. And (2) a gm script iterating over all elements caused a noticeable delay on the page load time. Maybe the situation has improved since?
This is an important bug/problem. The option to set a custom font is priority for accessibility besides aesthetic preference. And the option is breaking with these increasingly common 'fontified' icons.
Forgive my naivete, but isn't *how* to solve this not such a major question here? It's obviously an issue that other browsers have dealt with and solved. Google Chrome, for example, doesn't experience this issue. Wouldn't a quick spin through the code at chromium.org demonstrate at least one plausible approach for solving this? At that point it just becomes a matter of someone doing the legwork to implement it.
I wasn't aware that chrome had a preference to override page-specified fonts, though I could certainly be missing it. (Remember, this bug only shows up in Firefox when using that preference.)
That said, there is already a clear proposed approach here (see pointers comment 46, well hidden by all the other comments), it's just a substantial amount of work to do.
I can confirm that chrome (33.0.1750.154) on windows seems to magically do the right thing when launched with --disable-remote-fonts. But this doesnt seem to me solved in a widespread way. In IE11, when toggling on "ignore font styles specified on webpages" in the accessibility options, it seems to behave roughly as firefox, blocking the special fonts entirely and failing to render icons. And as of opera 20 I was unable to find a way to disable downloadable fonts to check it.
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-7) from comment #56) > That said, there is already a clear proposed approach here (see pointers > comment 46, well hidden by all the other comments), it's just a substantial > amount of work to do. The approach referenced in comment 46 sounds hard to me; I'm not disputing that. And, I'm sure I'm wrong, but wouldn't just allowing all downloaded fonts solve the issue and be less work to implement than the aforementioned approach? That was what I was asking; I should have been more clear. Honestly, I don't like this idea, myself. Seems like these fonts were invented with the intention of making it impossible to select ones own fonts and a good solution will have to be very complicated (and equally overbearing in design).
Chrome falls back on webpage specified fonts where user defined font missed characters - ideal for accessibility needs with no complex user ruleset required or requested. I am doubtful that much discussion here has been any practical help to firefox fixing this issue. It looks like a technical matter to add missing character fallback to the font load and display codebase with minimum extra complexity and fuss, but worth whatever change it takes within reason.
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-7) from comment #34) > (In reply to Rob Couto from comment #32) > > Yes, I know... more of that "easy to talk about" from over here. I looked. > > dbaron was right, some things will need to get a bit more complex in order > > to handle this. Since this is unconfirmed, I suppose that means nobody is on > > it yet, so I'm going to dig around in nsPresContext.cpp for a while and see > > if I can see anything else like a way out. > > The current pref works by converting all page-specified 'font-family' styles > to either 'monospace' or whichever of 'serif' or 'sans-serif' is the user's > default. This is done in nsRuleNode::ComputeFontData. > > Fixing the bug would require removing the entire current implementation of > the preference and reimplementing it in a different way. I'd suggest > discussing designs before spending too much effort on them, since there > might be problems that others here would bring up. Here's a suggestion for a relatively minor change to ComputeFontData that I think would address most of the usability problems people are reporting: instead of *replacing* the page-specified font-family with the user's default of 'serif' or 'sans-serif', how about if we just *prefix* the user's default to the page-specified value? This would mean that the user's chosen default font will be used everywhere; but for characters that are not supported by that font (such as PUA icon codepoints), we'd have the original page-specified font-family list (including any downloadable icon fonts, etc).
Something like this seems to work OK in simple testing, at least. Pushed to tryserver to see how it fares (https://tbpl.mozilla.org/?tree=Try&rev=0c828cfa445d). This will alter the computed value we return for font-family when the use_document_fonts pref is disabled, so I wouldn't be surprised if we have some tests that break and will need updating if we decide to go this way. David, do you think this is a reasonable approach to try?
Attachment #8399997 - Flags: review?(dbaron)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
The UI text "Allow pages to choose their own fonts, instead of my selections above" should be changed (maybe in a followup bug). Web pages will always be allowed to choose fonts with this change. The option will just change the preference order.
(In reply to Masatoshi Kimura [:emk] from comment #62) > The UI text "Allow pages to choose their own fonts, instead of my selections > above" should be changed (maybe in a followup bug). Web pages will always be > allowed to choose fonts with this change. The option will just change the > preference order. Right; if we decide to adopt this change, I'd suggest modifying the UI option to something like "Prefer my selections above to fonts specified by web pages" (which would be off-by-default, reversing the sense of the checkbox). But let's see what :dbaron thinks of the idea.
(In reply to Jonathan Kew (:jfkthame) from comment #61) > Something like this seems to work OK in simple testing, at least. Pushed to > tryserver to see how it fares > (https://tbpl.mozilla.org/?tree=Try&rev=0c828cfa445d). This will alter the > computed value we return for font-family when the use_document_fonts pref is > disabled, so I wouldn't be surprised if we have some tests that break and > will need updating if we decide to go this way. David, do you think this is > a reasonable approach to try? Excuse my ignorance, but is it possible to download those builds for testing? I've gotten the impression that a lot of sites do not use PUA code points, but rather abuse some general region. Would be nice to have a test build and click around in various sites and see how it behaves.
(In reply to Pierre Ossman from comment #64) > Excuse my ignorance, but is it possible to download those builds for > testing? From the job summary at https://tbpl.mozilla.org/?tree=Try&rev=0c828cfa445d, you can click on the green "B" (build) for the platform of your choice (be sure to use an "Opt" build, as the "Debug" builds will be really slow), then click the "Go to build directory" link at the bottom left of the window to find the dir where the build (and associated logs, etc) is stored. Feedback on how well this does (or doesn't) work would be welcome, thanks! > I've gotten the impression that a lot of sites do not use PUA code > points, but rather abuse some general region. If so, such sites are simply broken (they'll fare poorly with accessibility software, for example), and I would encourage you to complain to their webmasters.
A quick test so far, and I'm afraid it doesn't look good. First off it feels too heavy handed to lock this into the "force my fonts" setting. I'd prefer it to force local fonts first. I.e. shuffle the web fonts to the back of the list. If nothing else this method forces all sites to either sans or serif (why are there three settings? it doesn't seem to have any connection to the font-family style on the page.). This is minor though compared to: a) The default Sans font on most Linux systems (DejaVu Sans) has glyphs for many of the PUA code points. I noticed this on github which uses this heavily all over the site. By pure dumb luck pvponline.com works because it happens to pick a dead region in DejaVu Sans. b) Many sites, as suspected, don't use the PUA code points. Examples are sourceforge.net and romanticallyapocalyptic.com, which both use latin characters. And I doubt getting sourceforge are even going to consider this a problem, given that they can't even be bothered keeping their core services running sanely.
(In reply to Pierre Ossman from comment #66) > A quick test so far, and I'm afraid it doesn't look good. > > First off it feels too heavy handed to lock this into the "force my fonts" > setting. I'd prefer it to force local fonts first. I.e. shuffle the web > fonts to the back of the list. I don't see how that addresses this bug as originally reported - people who *want* to use the "force my fonts" setting, but this leading to icon-font breakage. It might address a different use-case, but I'm not really sure; what actual behavior are you envisaging? How would "shuffling web fonts to the back of the list" help? > If nothing else this method forces all sites > to either sans or serif (why are there three settings? it doesn't seem to > have any connection to the font-family style on the page.). > > This is minor though compared to: > > a) The default Sans font on most Linux systems (DejaVu Sans) has glyphs for > many of the PUA code points. Huh, that's unfortunate. So it does. :( > I noticed this on github which uses this > heavily all over the site. By pure dumb luck pvponline.com works because it > happens to pick a dead region in DejaVu Sans. > > b) Many sites, as suspected, don't use the PUA code points. Examples are > sourceforge.net and romanticallyapocalyptic.com, which both use latin > characters. And I doubt getting sourceforge are even going to consider this > a problem, given that they can't even be bothered keeping their core > services running sanely. For sites that do that, I don't see how the browser can be expected to "solve" the issue people are complaining about here. Either you allow the site to specify the fonts to be used (leading to the complaints about sites that choose hard-to-read typefaces), or you don't (leading to "icons" that get displayed as random Latin characters). Anyhow, it sounds like this probably isn't a useful solution. Sigh.
Assignee: jfkthame → nobody
Comment on attachment 8399997 [details] [diff] [review] modify behavior of setting browser.display.use_document_fonts=0 to still allow fallback to document fonts Cancelling r?dbaron here, given that it apparently doesn't help as much as hoped.
Attachment #8399997 - Flags: review?(dbaron)
I have to correct a claim i repeated earlier that Chrome has a fix for this - but on checking, I find my chrome install does not even have such a 'force fonts' setting. I tried the test build there and Github is still broken. These web-font-icons just might be the death-knell for the days of use-my-own-font internet browsing. The option might be partially salvaged by combining an "accept web fonts" setting. Or possibly possible? - "accept web fonts that look like they are probably icons" ... Thanks to everyone having a go at this issue. Should the bugs Platform field be corrected? It is listed as Linux at the moment but im on Vista and believe its cross platform.
(In reply to Jonathan Kew (:jfkthame) from comment #67) > > It might address a different use-case, but I'm not really sure; what actual > behavior are you envisaging? How would "shuffling web fonts to the back of > the list" help? > Ok, there has been so much discussion on this bug that I have to admit that I haven't kept track of what different people want. For me the problem is fairly simple: Lots of sites have started having their own fonts with abysmal hinting. Prime example is google and their Roboto font. The blurry mess makes things very straining to read. The fonts on the system though are generally well hinted (or there is a decent bug report channel to have it sorted out). So except for this very annoying issue with fonts being used for symbols, the current gfx.downloadable_fonts.enabled is exactly what I want. > For sites that do that, I don't see how the browser can be expected to > "solve" the issue people are complaining about here. Either you allow the > site to specify the fonts to be used (leading to the complaints about sites > that choose hard-to-read typefaces), or you don't (leading to "icons" that > get displayed as random Latin characters). > > Anyhow, it sounds like this probably isn't a useful solution. Sigh. Yeah, I don't see how any general solution would work either. So some form of white list/black list system might be the only practical method. :/
(In reply to comethope from comment #69) > Or possibly possible? - "accept web fonts that look like they are probably > icons" ... Any creative ways we could tell? Check number of valid glyphs? Check the ranges perhaps?
Given, there may be a problem with generally very poor web fonts some would like to blacklist, but this bug is about the long legacy of forcing ones own fonts getting broken by font-icons. It is a long standing browsing option which is maybe dying out, but i personally have always liked it. If i could do my own hacking here, i would add an 'accept all web-fonts' clause and live with the unnecessarily altered typefaces for the sake of seeing font-icons, as an experiment id try 'accept web-fonts less than xKb size' if size is accessible, as I guess font-icon web-fonts might tend to be smaller sets of glyphs, compared to whole letter and symbol sets of full fonts. Certainly if it were possible to review the ranges of the characters before changing fonts in the documents then that should be most accurate, but I expect thats most awkward to implement.
"accept known icon-fonts" .. maintain a list, expose it in about:config. Have a Whitelist for icons and good fonts. Since we are at it, have a Blacklist for bad and disliked fonts. This might seem like a job for an addon, but that means accepting defeat here. The old force-font feature was a minority tool, never perfect in all respects, but worked well by my reckoning. It is effectly broken now and should probably be removed or at least a warning that some sights will have broken icons, if it cant be salvaged.
> Any creative ways we could tell? Check number of valid glyphs? Check the ranges perhaps? If a font is used for only one-letter words, it is probably being used for icons. I think this is a horrible idea. Maybe useful to an add-on that would manage a whitelist or blacklist though.
(In reply to Jonathan Kew (:jfkthame) from comment #67) > For sites that do that, I don't see how the browser can be expected to > "solve" the issue people are complaining about here. Either you allow the > site to specify the fonts to be used (leading to the complaints about sites > that choose hard-to-read typefaces), or you don't (leading to "icons" that > get displayed as random Latin characters). > > Anyhow, it sounds like this probably isn't a useful solution. Sigh. But in so far as this bug is solvable at all, it sounds like a pretty good approach, actually. (from the description; I didn't look at the patch)
This problem is definitely solvable. A whitelist would fix it, accepting all web-fonts would fix it (while degrading/altering the use-own-fonts option a bit), detecting icon-fonts would fix it... at least the first two are clearly doable. To be clear - prominent sites using icon fonts have broken firefoxs use~own~fonts ability. It used to work very nicely if you had need of it and now prominent sites such as github are unusable with it. If the new use of webfonts for font-icons (which have no equivalent in own-fonts) is not accomodated , the option begs to be disabled because of the confusion/frustration it will cause to leave it in.
The patch doesn't work so great for me since it depends on my disabling use_document_fonts which uglifies more websites than downloadable_fonts.enabled, because sites are sometimes going through effort to pick a good hierarchy of fonts to try in case I disable their blurtastic downloadable font. I studied the chromium sources a bit to try to understand why it seemed to magically work for me with --disable-remote-fonts. In FontFace.cpp is this line: bool allowDownloading = foundSVGFont || (settings && settings->downloadableBinaryFontsEnabled()); Where downloadableBinaryFontsEnabled() seems to correspond to --disable-remote-fonts and gives some indication of the reasoning behind this function, which is as a security feature for unsafe fonts, and not so much as gear to fight ugly fonts. I guess they consider SVG to be safer. Therefore, a set of options, as I described earlier, to individually control which font engines are enabled for remote fonts, would not only match what chrome does (by enabling only SVG for remote fonts), but exceed its flexibility and allow the old downloadable_fonts.enabled functionality to be represented (by disabling all font engines for remote fonts). It seems strange that allowing only SVG remote fonts would solve most of the font-icon problems, but in my testing, it does. I'm not sure how long we can count on that...
(In reply to mgambrell from comment #77) > The patch doesn't work so great for me since it depends on my disabling > use_document_fonts which uglifies more websites than > downloadable_fonts.enabled, If you weren't using the use_document_fonts pref already, then I think the problems you're having don't belong in this bug, since this bug is about problems with icon fonts when using that pref. > because sites are sometimes going through effort > to pick a good hierarchy of fonts to try in case I disable their blurtastic > downloadable font. It sounds like it would be useful if you filed a separate bug (if there isn't one already) about the blurriness of downloadable fonts. (In reply to comethope from comment #76) > This problem is definitely solvable. A whitelist would fix it, This is both difficult to maintain and a bad experience for people writing content for the Web platform, some of whom actually test with configurations like this pref. > accepting all > web-fonts would fix it (while degrading/altering the use-own-fonts option a > bit), more than a bit; it would make the preference no longer do what some users need it to do > the option begs to be disabled because of the > confusion/frustration it will cause to leave it in. I agree it's becoming less usable, but I strongly suspect some users have accessibility needs for this feature and still prefer having it over not having it.
Thanks David Baron, points taken. To accommodate these icon-fonts for the 'force-font facility' it seems sure that web-fonts have to be scrutinized before deciding whether to substitute them. If it were possible at the moment of scrutiny to determine if the character 'e' (commonest letter) is out of range in the web-font, then it could be supposed that it is probably an icon-font and should not be replaced. If 'e' is in range then it is likely to be an alpha-numeric font and so it should be replaceable. This would need the fonts to be downloaded before accepting or replacing them, which i expect doesn't happen already. The only other way i guess without maintaining whitelist or downloading fonts to check them is to try and generalise/ establish a naming convention/pattern for icon-fonts, eg. accept fonts named ".*icon.*"
Apologies if the idea about checking 'e' is too Western-centric. Im not familiar with encoding of other alphabets.
(In reply to comethope from comment #80) > Apologies if the idea about checking 'e' is too Western-centric. Im not > familiar with encoding of other alphabets. It is indeed too Western-centric. It would also fail in plenty of non-icon-font cases, such as a font that's intended for titles and includes only the UPPERCASE letters. And it will fail for sites (like sourceforge, for example) that use icon fonts where the icons are (incorrectly) encoded as Latin characters, so that 'e' is actually one of the icons critical to the site's navigation.
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-7) from comment #78) > I agree it's becoming less usable, but I strongly suspect some users have > accessibility needs for this feature and still prefer having it over not > having it. You strongly suspect correctly. :) It seems strange to me that the concept of "user-agent" has been diluted to the point where the ability to have text displayed in a way that's agreeable to you has been marginalized, but... rather than ranting about that, I've been pondering how this feature might best be compromised, if it indeed has to be compromised. Would there be any merit to having a conditional version, based on semantics? For instance, "Display everything in a <p> tag with my chosen font" or some smarter version of the same? If designers feel the need to control elements of the page that are essentially widgets vs. blocks of text, maybe giving them that would be enough, with the understanding that large text areas are subject to user control...
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-7) from comment #78) > If you weren't using the use_document_fonts pref already, then I think the > problems you're having don't belong in this bug, since this bug is about > problems with icon fonts when using that pref. The problems I'm having are the same: icons are broken due to font suppression. If you deal only with the use_document_fonts pref then I think youll discover shortly that it only solved the problem for half of the people, and this history will repeat itself, and the next solution will be less likely since it will seem redundantly weird after having solved it here. Let's rephrase my last suggestion to be more pertinent to this bug as you've defined it: add options "allow_page_to_choose_TTF" and "allow_page_to_choose_SVG". This would solve many of the same cases without even needing to make this thread about whether a font was downloaded. > It sounds like it would be useful if you filed a separate bug (if there > isn't one already) about the blurriness of downloadable fonts. This is never going to get solved. The fonts are ugly, it isn't firefox's fault. I just want to avoid these fonts.
Maybe we could add some kind of style or something that would mark text as containing icons. This would cause it to get treated differently according to "always_use_font_specified_by_page_for_icons", a new preference. If webmasters cared about accessibility (purely hypothetical) then they could make sure that's in all their styles; and if not, it could possibly be easier for a community or individual list to maintain as some user CSS patch-ups (I don't know the first thing about CSS, but I think this makes sense) which mark those styles appropriately. An add-on might find this convenient: imagine a context menu option "add mozilla-font-icon to style of selected text"
If any of the characters on the page are invalid in the user-defined font, then don't use the user font. If that is to complex to implement, the only other option i see is whitelist/blacklisting.
(In reply to comethope from comment #85) > If any of the characters on the page are invalid in the user-defined font, > then don't use the user font. When you say "the user font", you mean the default font chosen by the user in Preferences - not a font defined by the web page, right? (The term "user font" is often used for downloadable fonts linked via @font-face, which would be the opposite of what you're talking about, I think - hence wanting to confirm what you meant here.) "then don't use"... do you mean don't use it for the particular character(s) that aren't present in the user's chosen font, or don't use that font at all?
Sorry for the loose terminology, your guess which makes sense of my statement in this context was correct. I dont think it desireable to individuate invalid characters, i think 'dont replace that font at all' if it will result in any invalid characters. Foreach(webfont){ If ( any of the characters on the page in each webfont are invalid in the 'local-preference-set-font') then { do not replace the webfont with the 'local-preference-set-font' } else { it is safe to replace the webfont with the 'local-preference-set-font' } } To me this is a pretty core principle of deciding whether a webfont is replaceable without breaking characters, and would work quite optimally if it is possible to neatly implement it - thats a whole other matter though.
(In reply to comethope from comment #87) > deciding whether a webfont is replaceable without breaking characters This isn't a good approach, since we must assume within a year's time 100% of websites will use icon-fonts. Your logic will choose to use the webfont 100% of the time, resulting in the local preference being pointless. Webfonts must always be 'replaceable' even if characters are broken--the goal here is to find a way to fix the broken characters.
I think it would be inaccurate to assume that web-fonts will dominate in a year or twos time. But individuating characters to keep original font of only the ones which would be invalidated by replacement with the 'local-preference-set-font' is a possibility... However it is more complicating and less consistent than keeping the whole webfont, and i think most often icon-webfonts will be specialised and contain few if any other replaceable characters, and text-webfonts will most often not contain icons and so be fully replaceable with the 'local-preference-set-font'). The more complex the solutions we conceive here the less chance anyone who can code it will be able or inclined to do so. I am pretty sure my most previous suggestion would be a very tight and efficient and lasting solution to this issue if it were possible to neatly implement.
(In reply to comethope from comment #87) > Sorry for the loose terminology, your guess which makes sense of my > statement in this context was correct. > I dont think it desireable to individuate invalid characters, i think 'dont > replace that font at all' if it will result in any invalid characters. > > Foreach(webfont){ > If ( any of the characters on the page in each webfont are invalid in the > 'local-preference-set-font') Anything along these lines is pretty much doomed to failure. It would require analysis of the entire page - which could include a huge amount of text, and/or might still be progressively downloading from the network, and/or might be constantly changing - before we could decide which font to use for any given fragment of text.
Do people have any intermediate solutions that they're happy with? Have any of the aforementioned solutions evolved into something better or are there perhaps reason why one is not using them anymore. I'm currently using the Document Font Toggle add-on and I'm looking for something better. I find the switch when switching between tabs where the toggle is in different states to be very distracting.
Hi, I'm the author of the Document Font Toggle add-on. I know it's very crude, but it was only meant to serve as a band-aid until this bug got fixed. Doesn't sound like it will, right now. :(
Thanks for the add-on Alexander. It's the best solution I'm using currently. I was just hoping whether someone had a less distracting solution to this problem.
"Anything along these lines is pretty much doomed to failure. It would require analysis of the entire page - which could include a huge amount of text, and/or might still be progressively downloading" I am at odds with that assessment of the idea - sure it is not an 'easy' idea, however huge pages do require alot more processing than the proposed scan here for invalid characters, reflows etc occur very frequently, invalid character scan could also, or not (however a capable programmer sees fit). Yes pages can change dynamically but this can not be a block to dismiss the idea of assessing them. Choices can be made of when and how often to do such assessment (which would be required to intelligently detect the web-icon font problem here), those choices ultimately made and tested by a capable programmer - not argued out in or out of bounds a bugtracker thread.
The way this should be handled is with a font whitelist and appropriate UI to add individual fonts from a particular webpage to that whitelist. The setting should be "Do not allow websites to choose their own fonts, unless they are choosing one of these fonts: X, Y, Z. . ." Then provide a mechanism for users to see what fonts a site is *trying* to use, and to enable the ones they want. The trend towards websites using fonts for this inappropriate purpose is truly lamentable and cheeses me off on a daily basis. But the way to handle it isn't to try to guess what the font is being used *for*. Only the user can decide if they want to see a certain font or not, so the best way is to let the user enable individual fonts one by one. This way browsers users can enable just the fonts that they absolutely need for navigating the poorly-designed sites that require them, while retaining their own chosen fonts for everything else.
I use gfx.downloadable_fonts.enabled = false because the webfonts show uggly on my system with cleartype off. We need a pref for whitelisting fonts that use icons in websites. Now i use stylish or userstyle as workaround (gfx.downloadable_fonts.enabled = true) to block all webfonts and not icon webfonts, but the webfont list is long and the rule is never complete: @-moz-document url-prefix("http://"), url-prefix("https://") { @font-face {font-family: "Droid Sans"; src: local("Arial");} @font-face {font-family: "Droid Sans"; font-weight: bold; src: local("Arial Bold");} @font-face {font-family: "Droid Serif"; src: local("Arial");} @font-face {font-family: "Droid Serif"; font-weight: bold; src: local("Arial Bold");} @font-face {font-family: "Droid Serif"; font-style: italic; src: local("Arial Italic");} @font-face {font-family: "opensans"; src: local("Arial");} @font-face {font-family: "open_sans"; src: local("Arial");} @font-face {font-family: "open_sans"; font-weight: bold; src: local("Arial Bold");} @font-face {font-family: "open_sans"; font-weight: bold; font-style: italic; src: local("Arial Italic");} @font-face {font-family: "opensansbold"; src: local("Arial Bold");} @font-face {font-family: "Open Sans Light"; src: local("Arial");} @font-face {font-family: "Open Sans"; font-weight: bold; src: local("Arial Bold");} @font-face {font-family: "Open Sans"; src: local("Arial");} @font-face {font-family: "Open Sans"; font-weight: 300; src: local("Arial");} @font-face {font-family: "Open Sans"; font-weight: 400; font-style: italic; src: local("Arial Italic");} @font-face {font-family: "Open Sans"; font-weight: 400; src: local("Arial");} @font-face {font-family: "Open Sans"; font-weight: 600; src: local("Arial Bold");} @font-face {font-family: "Open Sans"; font-weight: 700; font-style: italic; src: local("Arial Bold Italic");} @font-face {font-family: "Open Sans"; font-weight: 700; src: local("Arial Bold");} @font-face {font-family: "Open Sans"; font-weight: 800; src: local("Arial Bold");} @font-face {font-family: "Cuprum"; src: local("Arial");} @font-face {font-family: "Fira Sans"; src: local("Arial");} @font-face {font-family: "Fira Sans"; font-weight: 600; src: local("Arial Bold");} @font-face {font-family: "Fira Sans"; font-weight: 700; src: local("Arial Bold");} @font-face {font-family: "Lato Black"; src: local("Arial");} @font-face {font-family: "Lato Bold"; src: local("Arial Bold");} @font-face {font-family: "Lato Regular"; src: local("Arial");} @font-face {font-family: "Montserrat-Regular"; src: local("Arial");} @font-face {font-family: "Lato"; font-weight: 700; src: local("Arial Bold");} @font-face {font-family: "Lato"; font-weight: 900; src: local("Arial");} @font-face {font-family: "Lato"; font-weight: 400; src: local("Arial");} @font-face {font-family: "Montserrat"; font-weight: 400; src: local("Arial");} @font-face {font-family: "Titillium"; src: local("Arial");} @font-face {font-family: "Titillium"; font-weight: 600; src: local("Arial");} @font-face {font-family: "Titillium"; font-weight: 400; src: local("Arial");} @font-face {font-family: "Istok Web"; src: local("Arial");} @font-face {font-family: "LatoRegular"; src: local("Arial");} @font-face {font-family: "PatuaOneRegular"; src: local("Arial");} @font-face {font-family: "proxima-nova"; src: local("Arial");} @font-face {font-family: "Roboto"; src: local("Arial");} @font-face {font-family: "Roboto"; font-style: italic; src: local("Arial Italic");} @font-face {font-family: "Roboto"; font-weight: 300; src: local("Arial");} @font-face {font-family: "Roboto"; font-weight: 400; src: local("Arial");} @font-face {font-family: "Roboto"; font-weight: 500; src: local("Arial");} @font-face {font-family: "Roboto"; font-weight: 100; font-weight: 700; src: local("Arial Bold");} @font-face {font-family: "Roboto"; font-weight: 300; font-weight: 700; src: local("Arial Bold");} @font-face {font-family: "m1m"; src: local("Arial");} @font-face {font-family: "m_1mmedium"; src: local("Arial Bold");} @font-face {font-family: "adobe-clean"; font-weight: 300; src: local("Arial");} @font-face {font-family: "adobe-clean"; font-weight: 400; src: local("Arial");} @font-face {font-family: "adobe-clean"; font-style: italic; font-weight: 400; src: local("Arial Italic");} @font-face {font-family: "adobe-clean"; font-weight: 700; src: local("Arial Bold");} @font-face {font-family: "Helvetica Neue"; font-weight: 300; src: local("Arial");} }
I am doing something similar inspired by both ToBo and https://support.mozilla.org/en-US/questions/988772 to try this out. I already like it better than using Document Font Toggle since I can still force my preferred font on offending websites and have them display their icons. I have also re-enabled "allow pages to use their own fonts" and am using the Stylish add-on for this. The main thing that needs to be done is adding a global style: @namespace url(http://www.w3.org/1999/xhtml); * { font-family: sans-serif !important; } After this some website using icons fonts already work alright, f.e. Twitter. Others like GitHub need additional tweaks. Here are a few examples (the main culprit for me was GitHub since I switch to that a couple of times a day and I would be presented with its own ugly font (and the distracting switch cause by Document Font Toggle)). GitHub: @namespace url(http://www.w3.org/1999/xhtml); @-moz-document domain("github.com") { * .octicon { font-family: octicons !important; } * .mega-octicon { font-family: octicons !important; } } Keybase: @namespace url(http://www.w3.org/1999/xhtml); @-moz-document domain("keybase.io") { * .fa { font-family: FontAwesome !important; } } Pushbullet: @namespace url(http://www.w3.org/1999/xhtml); /* See: http://www.w3.org/TR/selectors/#attribute-selectors */ @-moz-document domain("pushbullet.com") { * [class ^= "icon-"] { font-family: FontAwesome !important; } * [class ^= "push-"] { font-family: pushfont !important; } * .standard-push-icon { font-family: pushfont !important; } } (I have actually no idea whether the lines with @namespace are necessary.)
I deactivate my stylish workaround in comment 97 and use now the filtering in Adblock with this rules: *.ttf| *.woff| ||fonts.googleapis.com^ and this withlist rules: @@*PayPalIcons-Regular.ttf @@*PayPalIcons-Regular.woff @@*fontawesome-webfont.ttf @@*fontawesome-webfont.woff It works for 95% of the websites and the other sites get a site specific rule.
Add me to the list of people very annoyed with this bug. I am working around it using the addon from Alexander now. So, no solution for this? Too hard?
Yes! Alex's add-on is great. Thanks for the idea, Sunil. That's all I really needed. The behavior of the add-on is a bit odd, though. If you are on a white-listed web-page where server fonts choices are allowed, such as github, for example, and switch to a tab that with a page that is "use my own font choices", then the page renders first with the server fonts then immediately is rendered without. So, a better fix is needed that doesn't ensures unapproved fonts/pages are never rendered with unknown/undesirable/hazardous fonts.
Users who set firefox to show their own fonts is not the only cause of this "icon breakage." If NoScript blocks @font-face then icons break. Many users apply NoScript settings to whitelisted sites as a way to improve security as @font-face can be a vector of attack. Not sure if this adds any import to the discussion, but I thought I'd mention it in case it affects any solutions. Personally, one of my favorite things about Firefox is being able to select my own fonts to display. So it would be nice to have this fixed.
Anybody know an ETA on this fix? I'm surprised this bug is not being given higher priority. It breaks web pages bad.
I've been trying a half dozen or more basic approaches... really spending a lot of time on this. Actually roaming the web to search for icons to whitelist. Based on my recent experimentation with adblock+, 90% of icon fonts have 'icon' in the name. Therefore an approach like this is working well: 1. block .ttf and .woff and data:application/x-font-ttf and friends 2. whitelist @@icon*.ttf^ and similar (still experimenting with this exact filter) 3. whitelist individual offenders, who are in the minority, such as + fontawesome and font-awesome + pictos + a very small number (surprisingly) of data:application + icomoon 4. detailed inspection of confusing rare special cases (etsy) This has led me to the realization that we are on the brink of a very soft and easy standardization method which we could promulgate to help solve this problem: simply put "icon" in the name of the font if its intended use is icons. Actually this could be improved.. suppose the guidance is to end in -icon.ttf or -icon.woff etc. to make filters faster. But at least by requiring *icon* somewhere in the filename we'd automatically have the support of 90% of websites. I'm writing before I'm done with my experimentation because I'm excited that something as simple as this could fix the problem and wonder what others think. This approach is vulnerable to people combining font icons with blingy typefaces. However the typical website is sending down 5-12 icons. I don't think they'll be trying very hard to combine them, especially when they must be sourced from different vendors. So it should be safe.
Workarounds are good, but they're not the same thing as solutions. We can't rely on website or font designers to follow sane practices in order to make our lives easier. If we could, we'd never have found ourselves in this mess in the first place. We need an in-browser solution that allows the *user* to determine which fonts are allowed to be used for display. It would be cool if it had some heuristics along the lines you're describing, though (e.g., autosuggesting fonts with 'icon') in the name).
Most of the reasoning I come across behind not allowing fonts to download is for security reasons. For example, enabling NoScript's "Forbid @font-face" embedding breaks Firefox fonts. @mgambrell regarding comment 77: If Chrome is set to --disable-remote-fonts, do I understand correctly that Chrome is still downloading some fonts? If so, this would defeat the setting's purpose if it was set for security reasons. Is this why Chrome does not break fonts even when a user sets his/her own font to be used (i.e., enabling the override of page-specified fonts)?
Here's my 2 cents. It's not a 100% solution to the icon fonts problem but it works for me. Set Firefox to "allow pages to use their own fonts". Install the Stylish addon I recommend to install Stylish ver. 1.4.3 https://addons.mozilla.org/en-US/firefox/addon/stylish/versions/1.4.3 (optional) Install "stylish-custom" ver. 1.5.1a by the developer Sonny srazzano This addon adds some useful features to the Stylish addon. https://dl.dropboxusercontent.com/u/77691265/sc151a.xpi Install my Global userstyle https://userstyles.org/styles/92341/global-large-font-except-major-sites It changes the font of the "main" text of the page to Trebuchet MS (you can change it to font you like) and the text size to LARGE without changing the headers and the glyphs (icon fonts). I created today another userstyle. It's a copy pf the previous userstyle but without changing the text size. https://userstyles.org/styles/111927/global-change-font-family-excluding-some-sites If you stumble to a site that you don't want it to be affected by my userstyle then add the site name to the regexp line at the top of the userstyle - it's a list of sites to be excluded (like gmail,facebook,youtube,...)
> @mgambrell regarding comment 77: > If Chrome is set to --disable-remote-fonts, do I understand correctly that > Chrome is still downloading some fonts? If so, this would defeat the > setting's purpose if it was set for security reasons. Is this why Chrome > does not break fonts even when a user sets his/her own font to be used > (i.e., enabling the override of page-specified fonts)? I'm having difficulty confirming it today... it seems sites are switching over to forced https rapidly and I don't know a handy way to monitor the URLS that are retrieved through https. But chrome will definitely stop rendering ugly typefaces while simultaneously showing icons on github. Github's css tries eot,ttf,woff,svg in that order. Based on the code I found, I assume the SVG is being requested by chrome despite --disable-remote-fonts. In firefox, the icons won't show if I block eot, ttf, woff because firefox isn't even requesting the SVG. Therefore, after studying it again, I still believe you are understanding it correctly--chrome is still downloading some (svg) fonts. I should mention that during today's study I noticed many broken font icons in chrome. Maybe I'm more sensitive to it now or maybe use of SVG fonts is dropping off. I don't feel like their solution will be workable in the long run. You can find lots of people online talking about how their icons render in different browsers when done as TTF vs SVG, etc. So these decisions will get made on aesthetic concerns. To refine my comment 84 and my continued efforts to find some kind of best-practices partial solution to this problem, I might see the following CSS: @font-face{ font-family:'octicons'; src:url(/assets/octicons.ttf) format("truetype"),url(/assets/octicons.svg) format("svg"); } I would like to see additions to W3C or whatever standards (I dont know how this works) which would look like this: font-semantic:icon /* defaults to 'typeface' */ This is like the least intrusive addition to CSS specs I can even imagine for any purpose whatsoever. Maybe everyone won't set that. But everyone who does will have webpages that now magically work for more people, so... This would not peacefully coexist with the black/whitelisting approach I've been working on lately, however, because the lists dont have access to that information. But.. we may as well create the infrastructure to solve this even if it doesnt completely solve it yet, right?
Screenshot of how bad Firefox breaks things (even an Addon's buttons) when setting preferences FONTS & COLORS "Allow pages to choose their own fonts, instead of my selections above" is disabled. http://a.pomf.se/kfquks.png
+ 1 for a solution This has really become an issue the last couple of years. Many major sites are now unusable with forced fonts. And it's far more an issue than it ever was with sites now using fancy, badly proportioned, hint-less fonts. There's a real benefit in blocking them. In the good old days a page could only load a font already on the user's system. Banishing Comic Sans from the OS would make a page default to something better. I don't understand the technical limitations, but with 'allow page to choose their own font' is disabled, could there be a character whitelist of: - all standard English, French, German, etc chars - common chars: !"ÂŁ$%^&*()_+-=[]{};'#:@~,./<>? et al that get rendered in the user's choice of fonts (exactly as it is now) but every other character would be rendered in the custom font(s) specified in the page?
Here's a possible patch that I think we could consider. The idea here is the same as described in comments 60-61 (though the implementation looks simpler with the new FontFamilyList class): give priority to the user's preferred fonts when the use_document_fonts option is off, but for characters not supported in the user's choice of font, use the page's specified fonts (whether local or downloaded or both) as usual, rather than going directly to system fallback fonts. This allows things like Github icons to continue working, as the PUA codepoints used should not be found in the user's pref fonts (normally), and so they'll fall back to the appropriate icon font from the page.
Your proposal is definitely an improvement over status quo, although incomplete. The problem is that many sites put icons in codepoints that actually are present in ordinary fonts. For such sites, I think we're gonna be stuck with the Stylish based solution described in comment #99.
(In reply to Dmitry Borodaenko from comment #116) > Your proposal is definitely an improvement over status quo, although > incomplete. The problem is that many sites put icons in codepoints that > actually are present in ordinary fonts. Yes, I know such sites and fonts exist. They are misusing character codes as defined by Unicode, and the result is a lack of interoperability/compatibility. I don't see how the browser can "fix" this, except via some kind of explicit whitelist (or blacklist) of fonts/sites/etc, which would be a never-ending maintenance nightmare. The appropriate response is to complain to the author/webmaster/font designer, asking them to update their pages/sites/fonts to be Unicode-compatible.
Attachment #8399997 - Attachment is obsolete: true
Updated patch for my proposed approach here, revising the behavior of the use_document_fonts=0 setting. The idea is to prefer a CSS generic that the user can set via preferences (either from the font-family list, or the browser default) but still keep the rest of the page-specified fonts in the list for fallback purposes. That way, icon fonts that use PUA characters, etc., still have a chance to render; but for all characters that are supported by the generic fonts configured in prefs, those will be used. This deliberately changes existing behavior in one respect (besides fixing some of the icon font problems people are having): it means that even with use_document_fonts disabled, the serif and sans-serif generics will still take effect, instead of always falling back to a single 'default variable-width font'. On balance, I think that's an improvement: there's no real need for this option to kill off the serif/sans distinction altogether, and if users really want to use the same font for *everything*, they can configure it as both their 'serif' and 'sans-serif' choices.
Attachment #8621501 - Flags: review?(dbaron)
Attachment #8616646 - Attachment is obsolete: true
Assignee: nobody → jfkthame
And just to make it clear: there will still be cases that fail. E.g. if the user's pref fonts include lots of PUA characters, overlapping with the codes used by an icon font, they'll take precedence over the icons. (So don't use default fonts that cover PUA characters, as they're non-interoperable by definition.) And icon fonts that replace standard ASCII letters with icons will not be accessible with use-document-fonts disabled. (Complain to the people abusing Unicode characters in that way.)
This looks really great and elegant !
How about font enumeration (bug 732096) again? Will a site be able to work [ ] use-document-fonts around by taking fonts' character set differences into account?
This is also a problem that I have had lately. I consider font-based icons to be a bad design practice in my opinion, but various sites use this. Even my school website uses font-based icons. I like to force my own fonts to my selection for consistency as well as to avoid problem with lousy fonts chosen by the web developer. That way I can choose what is used for serif, sans-serif, and mono-space fonts. I like the idea of being able to always use the user-selected font unless the glyph is missing, then falling back to the font specified by the web page. But as some have already mentioned, there are times when installed fonts I choose may already have glyphs for the PUA range. Would it be possible to simply add another option: Allow to use the page-specified font for PUA characters? This would then become two options in the Fonts dialog Allow pages to choose their own fonts, instead of my selections above [ ] for non-PUA characters [x] for PUA characters
Or the options could be configured as this, allowing always/never/only if missing for two separate radio groups: Allow pages to choose their own fonts for symbol characters (PUA), instead of my selections above (x) Always ( ) Only when missing from my selected fonts ( ) Never Allow pages to choose their own fonts for non-symbol characters (PUA), instead of my selections above ( ) Always (x) Only when missing from my selected fonts ( ) Never Based on the example selection above, symbol characters that properly fall within the PUA range would always use the page font, even if the selected front has the glyph for those characters. Other characters would only use the page font if the selected front doesn't have the glyph for those characters.
(In reply to Jonathan Kew (:jfkthame) from comment #118) > it means that even with > use_document_fonts disabled, the serif and sans-serif generics will still > take effect, instead of always falling back to a single 'default > variable-width font'. On balance, I think that's an improvement: there's no > real need for this option to kill off the serif/sans distinction altogether, > and if users really want to use the same font for *everything*, they can > configure it as both their 'serif' and 'sans-serif' choices. This sounds great. I wouldn't want to force a single font for all content (which some of the workarounds further up seem to do). Still having text render in one of the user specified; serif, sans-serif, monospace fonts would be best IMO.
(In reply to Jonathan Kew (:jfkthame) from comment #118) > Created attachment 8621501 [details] [diff] [review] > Revise the don't-use-document-fonts option so that it will prefer generics > (as configured in prefs), but may still use page-specified fonts if > necessary for fallback (e.g. icon fonts) > > Updated patch for my proposed approach here, revising the behavior of the > use_document_fonts=0 setting. The idea is to prefer a CSS generic that the > user can set via preferences (either from the font-family list, or the > browser default) but still keep the rest of the page-specified fonts in the > list for fallback purposes. That way, icon fonts that use PUA characters, > etc., still have a chance to render; but for all characters that are > supported by the generic fonts configured in prefs, those will be used. This > deliberately changes existing behavior in one respect (besides fixing some > of the icon font problems people are having): it means that even with > use_document_fonts disabled, the serif and sans-serif generics will still > take effect, instead of always falling back to a single 'default > variable-width font'. On balance, I think that's an improvement: there's no > real need for this option to kill off the serif/sans distinction altogether, > and if users really want to use the same font for *everything*, they can > configure it as both their 'serif' and 'sans-serif' choices. This works for me. For example, sparkfun.com renders correctly and github is fixed with the exception of the repo icon because it uses 0xF000 or 0xF001 (0xF000-3 are 2-digit 7-segment numerical displays updated just-in-time by the hinting bytecode, IIUC). I tried deleting the entire PUA from DejaVu Sans in FontForge and fontconfig found a way to show something there anyway (something that wasn't an octicon) so that will just require a sharper knife over here, or perhaps a bigger hammer. I had too much trouble with scripts and styles and I figured out that I don't want to be an extension maintainer and (surprise) I actually don't want to spend the rest of time complaining to someone new for abusing a spec. But icon fonts are legit: Unicode defines entire sets of icon-ish glyphs like dominoes and playing card symbols, so within the PUA it is arguably Just Fine(TM). Page loading seems a bit faster now since that userscript is disabled, and it wasn't correct to begin with. I had to resort to using a modified Stylish rule alongside it to successfully knock out helvetica and then at least one site specified a combination of size and weight that makes my chosen font at my chosen screen DPI look like garbage anyway, so face substitution isn't always enough. But so far, this works. Thanks for the patch.
Comment on attachment 8621501 [details] [diff] [review] Revise the don't-use-document-fonts option so that it will prefer generics (as configured in prefs), but may still use page-specified fonts if necessary for fallback (e.g. icon fonts) Review of attachment 8621501 [details] [diff] [review]: ----------------------------------------------------------------- The patch looks clean and efficient. It transfers the action of the options setting "(do not) Allow pages to choose their own fonts ..." to be integrated into gfx rendering's mFontlist by reordering the option-set fonts in the list. It corrects a deficiency of "(do not) Allow pages to choose their own fonts ..." which did overwrite mFontlist with a single preferred user font -thus it ignored sans and serif provisioning, and that also worked very poorly as increasingly popular webfonts are required for special ranges and icons. The previous behaviour left no fallback fonts in renderers fontlist for out of range characters. The patch ends such deficiencies by configuring the "(do not) Allow pages..." setting and associated fixed/sans/serif fonts, into the renderers existing font fallback list.
I hope this patch can be accepted as soon as possible - i haven't built and tested it myself due to local os and driver issues, but the patch is small and concise enough to have confidence in. I do not think it can affect the font fingerprinting concern considered by [:Aleksej], if anything this browser font option is more obscured from servers when combined with font fallback mechanism. The patch just delivers a long sought after refinement to the dont-use-document-fonts option : it restores sans and serif observance, and utilises existing font fallback to help with increasingly common Icon and Webfont complications. It is great, lets' get it accepted - Thankyou Jonathan Kew!
I'm glad this bug is getting attention and positive momentum and that people are happy with the direction. The approach of the proposed patch seems sensible to me, also. However, I urge you to consult security experts before adopting this fix. My interest in this bug is 50% aesthetic and 50% security. The current situation allows the user to sacrifice icon fonts--which is poor practice, anyway--for the security of known fonts. If I understand correctly, the proposed patch "falls back" to unknown/remote fonts. This is clearly unsafe behavior, generally speaking. I'm annoyed that pages with icon-fonts look bad, but I'd rather have that than remote fonts because I don't trust them; at least, I don't trust most of them. At the very least, I propose leaving in the option to enable strict, user-chosen font override of all page fonts, which is the current behavior. I don't see a good reason to eliminate this behavior, permanently, and I don't think anyone as suggested that, explicitly, either. I see the proposed behavior as a good default behavior *option,* but not a replacement for the current behavior. Even if you trust remote fonts, preserving the current behavior as an option is a good idea because it can be used as mitigation tool should a vulnerability in the font code be discovered in the future.
Presumably gfx.downloadable_fonts.enabled can still control whether fonts get downloaded. Besides that, "Allow pages to choose their own fonts, instead of my selections above" does not sound like it guarantees anything about downloading. It sounds purely cosmetic: in place of proportional, serif, sans-serif, or monospace fonts listed above, the page can choose their own font. Says nothing about icons. I don't think the proposed change to the behaviour of this option defeats any expectations anyone should have had (regardless of whether they did) Perhaps gfx.downloadable_fonts.enabled should be added to the GUI in the same place.
I think Porcelain Mouse's suggestion is a reasonable one, regardless of what expectations anyone may have had based on the wording of the option. Is there any reason NOT to have three options? Option 1: Let pages specify their own fonts Option 2: Use my fonts if glyphs are available, otherwise page fonts Option 3: Use my fonts always no matter what I don't see any downside to allowing all three options.
Brendan this patch enables your option two, it is dont-use-document-fonts with gfx.downloadable_fonts.enabled true. Option 1 and 3 are already available, option 3 is dont-use-doc-fonts with gfx.downloadable.. disabled. The patch enhances option 3 by preserving sans,serif,and fixedwidth styles to user font. Porcelain mouse about security, with gfx.downloadable_fonts.enabled set to disbaled, there is no security advantage from also setting dont-use-document-fonts. You can allow webpages choose different fonts that might or might not be _already_installed_ on your system without affecting any security possibilities (as far as can be predicted). The dont-use-document-fonts option has never intended to affect security, and if it was to by accident then that would be a different issue and bug report. This bug report was to correct or improve the performance of the 'dont-use-document-fonts' option when used with pages which _require_ some downloaded fonts/fonticons etc. to be usable. Crucially there is no practical way to make webpages which require downloadable fonts to be usable -Be Usable without allowing the necessary downloadable fonts through. Changes to option dialogues are another issue as well which would require untimely UX deliberations. A great thing about Jonathans improvement is it does not complicate security effects and it does not in itself beg interface changes. Its all good to go for this bug report.
Apologies, I see dont-use-document-fonts has over-ridden gfx.downloadable_fonts.enabled=true which is confusing. But the dont-usexxx setting has been around for longer than downloadable fonts, and is what needs fixed - actually because of downloadable fonts. The option to just not download any fonts exists regardless of doc-fonts option, as the config option gfx.downloadable_fonts.enabled=false. The "Allow pages to use.." option/facility here might better be called "Prefer my own font choices" The security relevant setting doesnt need a UI form, because it is a specialist security requirement needing combined with disabled images and other filetypes and heavy javascript limitation, and other configurations to have any practical value. General users are not going to improve security with an easy option to disable font downloading, they are just going to make some sites look bad on firefox.
Comment on attachment 8621501 [details] [diff] [review] Revise the don't-use-document-fonts option so that it will prefer generics (as configured in prefs), but may still use page-specified fonts if necessary for fallback (e.g. icon fonts) Clever! >+ mFontlist.RemoveElementAt(i); >+ mFontlist.InsertElementAt(0, name); I guess nsTArray doesn't have a more efficient way to do this (i.e., that avoids repeatedly shifting the elements after i). Oh well. Was it intentional that you're now honoring system fonts as well? You didn't mention that in comment 118. If you didn't want to, you'd also need code in the following else of the highest-level if-else chain in your nsRuleNode::SetFont change. (I think I'd be slightly against honoring them, but I'm ok if you think honoring them is better.) Also, do you want to call SetDefaultFontType() if the use document fonts pref is false? Or is the intent that you never modify it from the default in that case? But my biggest concern is that the whole thing is conditional on: if (aGenericFontID == kGenericFont_NONE) { nsRuleNode::ComputeFontData looks at fontFamilyValue, sets it in the style data, and, if it has a generic, calls nsRuleNode::SetGenericFont, otherwise calls nsRuleNode::SetFont directly, either way passing the generic. nsRuleNode::SetGenericFont in turn calls nsRuleNode::SetFont, maybe more than once, passing the generic through. So in SetFont, aGenericFontID is only kGenericFont_NONE if there only wasn't a generic in the family list. This makes me think that this patch will allow document fonts through as long as they specify a generic. Is this somehow not the case? Also, please remove the fl local variable in nsRuleNode::ComputeFontData. review- because of the "But my biggest concern" paragraph. (But maybe I'm missing something there?)
Attachment #8621501 - Flags: review?(dbaron) → review-
(In reply to David Baron [:dbaron] ⏰UTC-7 (mostly busy, back June 29) from comment #133) > Was it intentional that you're now honoring system fonts as well? > You didn't mention that in comment 118. If you didn't want to, > you'd also need code in the following else of the highest-level > if-else chain in your nsRuleNode::SetFont change. (I think I'd be > slightly against honoring them, but I'm ok if you think honoring > them is better.) Sorry, I forgot to mention that although I was aware of the behavior. I think it makes sense to allow system fonts; after all, that's the mechanism for a site to present UI elements that fit in with the user's system environment/theme. The main complaint against use-document-fonts is that people dislike the fonts web designers are specifying, and find them ugly and/or hard to read. If that complaint applies to the user's system fonts, they have a much bigger problem! > Also, do you want to call SetDefaultFontType() if the use document > fonts pref is false? Or is the intent that you never modify it > from the default in that case? Yes, I think that should be OK. > But my biggest concern is that the whole thing is conditional on: > if (aGenericFontID == kGenericFont_NONE) { > nsRuleNode::ComputeFontData looks at fontFamilyValue, sets it in the style > data, and, if it has a > generic, calls nsRuleNode::SetGenericFont, otherwise calls > nsRuleNode::SetFont directly, either way passing the generic. > nsRuleNode::SetGenericFont in turn calls nsRuleNode::SetFont, maybe more > than once, passing the generic through. So in SetFont, aGenericFontID > is only kGenericFont_NONE if there only wasn't a generic in the family > list. This makes me think that this patch will allow document fonts > through as long as they specify a generic. Is this somehow not the > case? I see what you mean from reading the code. But testing shows that in fact the patch does work as intended even when the author has included a generic: data:text/html,<div style="font-family: zapfino, apple chancery, serif;">foo bar does NOT use the zapfino or chancery fonts, and inspecting the computed style shows that serif has been promoted to the front of the list. I'll try to figure out why this actually works, and provide an explanation. :)
OK, in the case where the font-family list names several families, potentially including a generic, we do NOT pass the generic from nsRuleNode::ComputeFontData in to nsRuleNode::SetFont; the code there for setting a generic and calling nsRuleNode::SetGenericFont applies only if fontlist->Length() == 1. So that's why specifying a generic in addition to some explicit family names does not cause a problem. And if the generic is specified alone, then the patch is intended to use it. However, I think it would actually be better for us to ignore the 'cursive' and 'fantasy' generics when use-document-fonts is disabled, and only respect the serif/sans-serif/monospace ones. This makes sense because only these "common" generics can be configured via the Firefox UI; and because the usual reason for wanting to turn off document fonts is for better readability, which 'cursive' and 'fantasy' are unlikely to offer.
Updated so that disabling use_document_fonts will also cause the cursive and fantasy families to be ignored when choosing a generic to use instead.
Attachment #8626939 - Flags: review?(dbaron)
Attachment #8621501 - Attachment is obsolete: true
Comment on attachment 8626939 [details] [diff] [review] Revise the don't-use-document-fonts option so that it will prefer generics (as configured in prefs), but ignoring the 'cursive' and 'fantasy' values, but may still use page-specified fonts if necessary for fallback (e.g. icon fonts) Ah, I guess my understanding of when we used SetGenericFont was based on the XXXldb comment that was removed in https://hg.mozilla.org/mozilla-central/rev/014f475ca0ec . Anyway, r=dbaron
Attachment #8626939 - Flags: review?(dbaron) → review+
dont-use-document fonts upgraded for the 21st century! Epic WIN for Jonathan Kew!
https://hg.mozilla.org/mozilla-central/rev/e0aba384235c
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox41: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Would someone be so kind as to affirm/deny whether I understand the end result of this fix? Is this an accurate understanding (in layperson terms) of the behavior that will result: 1) browser.display.use_document_fonts=1 #Website chooses fonts gfx.downloadable_fonts.enabled=true #Website chooses icons 2) browser.display.use_document_fonts=0 #Local-system chooses fonts gfx.downloadable_fonts.enabled=true #Website chooses icons 3) browser.display.use_document_fonts=0 #Local-system chooses fonts gfx.downloadable_fonts.enabled=false #Local-system chooses icons
Yes Greg, its as close to that as possible. 1) Website chooses fonts and uses any webfonts: browser.display.use_document_fonts = 1 gfx.downloadable_fonts.enabled = true 2) Firefox default fonts are used but webfonts are allowed when they contain characters not covered by the users default fonts (like icons): browser.display.use_document_fonts = 0 gfx.downloadable_fonts.enabled = true 3) Only Firefox default fonts are used. No fonts are ever downloaded. browser.display.use_document_fonts = 0 gfx.downloadable_fonts.enabled = false
I just want to say thanks to the people involved in writing/approving this patch! I've been testing with 41.0 and the new font controls work well. The only site I've noticed breaking so far is imgur.
(In reply to intracube from comment #144) > The only > site I've noticed breaking so far is imgur. I looked at imgur, and it's using a webfont where standard ASCII letters (A, B, C, etc) are displayed as icons. Not really anything we can do about that; you might consider complaining to the site's webmaster.
(In reply to Jonathan Kew (:jfkthame) from comment #145) > (In reply to intracube from comment #144) > > The only > > site I've noticed breaking so far is imgur. > > I looked at imgur, and it's using a webfont where standard ASCII letters (A, > B, C, etc) are displayed as icons. Not really anything we can do about that; > you might consider complaining to the site's webmaster. There is something that can be done about it, which is what I suggested in an earlier comment on this bug: change the font-allowing interface so that it is a whitelist of individual fonts rather than a binary choice of "let pages use their own fonts, or don't". Then you could whitelist the offending font on imgur and it would work. I agree that using this sort of font is poor web design, but having such a coarse font preference is also not great browser design. The user should be able to specify exactly what fonts he or she is willing to see.
(In reply to Jonathan Kew (:jfkthame) from comment #145) > I looked at imgur, and it's using a webfont where standard ASCII letters (A, > B, C, etc) are displayed as icons. Not really anything we can do about that; > you might consider complaining to the site's webmaster. What should I be asking imgur customer support? That the page font icons should be moved into Unicode PUA character code ranges? (In reply to Brendan from comment #146) > Then you could whitelist the offending font on imgur and it would work. But that would mean manual intervention from the user to fix broken site layouts. I grudgingly do this with NoScript because of the benefits it gives, but wouldn't want to expand on that tbh. As there are only a few (major) sites that don't work with the current patch, IMO it'd be better to lean on the site designers to fix things.
I used fontawesome on my site http://www.wide.co.il and Got the same problem with ff.
SOLVED ON WIN7 BUT NOT WIN10 This has not been fully fixed and needs to be reopened. As I just did several tests, everything works fine with Firefox stable 43 on my desktop PC with Win7 US-en 32bit and nVidia driver 309.08 32bit. BUT On my laptop with fresh install of Win10 1511 US-en 64bit (absolutely no further cumulative updates, nVidia driver 9.18.13.4192 from 13.10.2015, graphic card 310M), Firefox (version 34.0.5 and up until todays Nightly 47.0a1 20160207) is not displaying some icons correctly, and it displays a rectangle instead. Ive done all the tests with absolutely fresh profiles/portable installations with no addons. Version 33.0 and lower works well. Issues are not only on some pages, (eg www.kosicednes.sk )but also in an addon uBlock Origin v1.6.0rc1 (any version). Here is a screenshot how it looks like: http://oi57.tinypic.com/2i7rt3.jpg Note that the same addon, in the same version of Firefox on Win7 works OK, I cant really explain it. I found out it has nothing to do whether its 64 or 32 bit version of Firefox, whether multiprocess is enabled or not, also language of Firefox interface doesnt matter. There must have been a change between v33 and v34.0.5 that broke some things on Win10 while Win7 got unaffected or improved, im not sure. I tried to check gfx.downloadable_fonts.enabled TRUE but it was already true. Again, I tested with just installed portable versions so all the values are default. Please someone take a look at this, I can test the newest Nightly or a custom build to confirm if fixed.
(In reply to a8092719 from comment #149) > SOLVED ON WIN7 BUT NOT WIN10 > > This has not been fully fixed and needs to be reopened. No, what you're describing is unlikely to be the *same* issue as this bug addressed. Please file a separate bug report with details of your problem. (Actually, I suspect your issue might be related to the Win10 firewall, based on some other reports I've seen. You could try disabling/re-enabling the firewall and see if that makes any difference.)
Alright thank you, I created Bug 1249173 (Missing icons, rectangles on web pages, Windows 10, Fx 34b1 up to 47nightly)
(In reply to craigwut from comment #16) I used fontawesome on my site http://www.noemiwedding.com/ and Got the same problem with ff. It would require analysis of the entire page before we could decide which font to use for any given fragment of text.
Not the end. This flag breaks Material Icons, because they use ligatures https://material.io/icons https://google.github.io/material-design-icons/#icon-font-for-the-web --- What the great **** !!!!!!! The web is full of **** hack :( Any good idea?
Flags: needinfo?(jfkthame)
> Any good idea? For authors, or for readers? Page authors could use the PUA codepoints for the icons instead, which will probably continue to work even with Use Document Fonts disabled. I don't think there's much a reader can do, if the author is using the ligature approach: to see the expected icons in that case, you have to allow the page to specify the right font, otherwise it's just not going to work.
Flags: needinfo?(jfkthame)
Mentioned in bug 1363454
I think this fix has caused another great issue. At least bisection reduced the range to eaf4f9b45117 (last good) and c26dbd63604d (first bad). And this bug seems to be the most relevant When I try to override GUI fonts with this CSS in userchrome.css: @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); * { font-family:"Comic Sans MS" !important; } And don't allow pages to use their own fonts, the GUI font will be the one set in FF options for WEB PAGES and not the one specified in CSS. It seems like website settings are applied to chrome... So this means I can only have the UI font the same as the forced website font, when I force font settings on websites.
Flags: needinfo?(jfkthame)
Please file a new bug report, rather than raising a new problem in an already-lengthy bug that has been resolved long ago. You can include a reference back to this one if you suspect it's connected, but any further changes that may be wanted should be discussed and tracked in their own separate bug. We won't be adding new patches in _this_ bug, that makes issue tracking a nightmare.
Flags: needinfo?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #163) > Please file a new bug report, rather than raising a new problem in an > already-lengthy bug that has been resolved long ago. > > You can include a reference back to this one if you suspect it's connected, > but any further changes that may be wanted should be discussed and tracked > in their own separate bug. I had the empty hope that some mozilla people would care enough to file and fix bugs that were noticed. It made sense to mention here, where it most likely arose. Plus I'm tired of filing bugs just so they can be ignored. > We won't be adding new patches in _this_ bug, > that makes issue tracking a nightmare. Never implied that I expected
Depends on: 1430798

This has been closed for a long time, but was there a regression? Ever since I've started using the minimum font size settings, which requires unchecking the box for not allowing sites to choose their own fonts, icon fonts have been broken. The errors are most notable on Google sites but occur in various places across the web.

To reproduce the error:

  • open firefox preferences
  • ensure you're looking at "Fonts for: Latin"
  • uncheck 'allow pages to choose their own fonts, instead of your selections above'.
  • go to https://web.dev/measure/ and enter any url to analyze.
  • scroll down to the benchmark measures; you'll see serif text with words like 'bookmark', 'check_circle', and 'arrow_drop_down' cluttering up the UI.

This ties into a wider issue, that I can't find a bug about: why does my minimum font size preference need to change the font in use at all? As a person with lower-than-average vision who relies on that setting, I'd rather see the same fonts as everyone else, just big enough for me to see them. Text only zoom doesn't really solve my use case; the text that's already very large doesn't need to be even large, but text that's small does need bumped up to my minimum size.

This isn't a regression; the page you're looking at uses a font where the icons are not encoded as unique Private Use Area codepoints (in which case we'd expect the page's icon font to be used, rather than the browser's default Latin font), but rather they're represented as simple strings of English text, and the expectation is that the font will form whole-word ligatures such as a "bookmark" glyph from the characters 'b', 'o', 'o', 'k', 'm', 'a', 'r', 'k.

But as the content here is simple English text, there's no way for the browser to know that the page intended this particular word to be treated specially by the font. When you tell Firefox to prefer the fonts specified in Preferences, rather than the fonts from the web page, it looks at the word "bookmark" and sees that this works fine with the default Preferences font, so it doesn't have any reason to resort to the icon font from the page (as it would if the icon were encoded using a Private Use codepoint).

Having said that .... as far as I know, you should be able to set a Minimum Font Size in the Firefox Preferences, while still leaving the "Allow pages to choose their own fonts" option enabled. This seems to work for me: if I set a large Minimum, then (even though I'm still allowing pages to choose their own fonts) I see larger font sizes being used.

Thanks Johnathan, that makes sense.

When I tested in the past, it seemed like fonts wouldn't increase in size if I changed the minimum with 'Allow pages to choose their own fonts' enabled. Very probably I got confused in my testing, because I'm seeing a similar behavior to you now. Yay! This will make my web life easier. Thanks for your help, and sorry for the misdirection in my first comment.

(In reply to Cassey Lottman from comment #167)

When I tested in the past, it seemed like fonts wouldn't increase in size if I changed the minimum with 'Allow pages to choose their own fonts' enabled. Very probably I got confused in my testing, because I'm seeing a similar behavior to you now. Yay! This will make my web life easier. Thanks for your help, and sorry for the misdirection in my first comment.

Note that some websites (e.g. Google, if this is still the case) use a font that is smaller than the real size. I doubt that Firefox can detect that. (And increasing the Minimum Font Size is not a solution as this would make fonts too large on other web pages.) So the option to disable "allow pages to use their own fonts" is useful for real text.

(In reply to Jonathan Kew (:jfkthame) from comment #166)

This isn't a regression; the page you're looking at uses a font where the icons are not encoded as unique Private Use Area codepoints (in which case we'd expect the page's icon font to be used, rather than the browser's default Latin font), but rather they're represented as simple strings of English text, and the expectation is that the font will form whole-word ligatures such as a "bookmark" glyph from the characters 'b', 'o', 'o', 'k', 'm', 'a', 'r', 'k.

Concerning this issue, there is now bug 1638585.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: