Open
Bug 79074
Opened 23 years ago
Updated 2 years ago
[Pref Stylesheet]Generic font family settings ignored when `Allow documents to use other fonts' is off
Categories
(Core :: CSS Parsing and Computation, enhancement, P4)
Core
CSS Parsing and Computation
Tracking
()
NEW
Future
People
(Reporter: mpt, Unassigned)
References
Details
Attachments
(3 files)
930 bytes,
text/html
|
Details | |
1.08 KB,
patch
|
Details | Diff | Splinter Review | |
32.19 KB,
application/octet-stream
|
Details |
Build: 2001050314, Mac OS 9.1 To reproduce: * In your font prefs, turn on `Always use my font settings'. (Or, if bug 28899 has been fixed, turn off `Allow documents to use other colors'.) * Go to <http://www.uwm.edu/~wildbery/css/generic.html>. What you should see: * Your choices for the CSS generic fonts used for the text in the page. (Serif, sans-serif, and monospace at least, and the other families once bug 28899 is fixed). What you actually see: * Either serif or sans-serif used for everything. This bug is similar to bug 58048, but not directly equivalent. Bug 58048 asks for the system UI colors to be retained when `Always use my colors' is on. The system UI fonts *are* (correctly) retained when `Always use my font settings' is on (which is why this is a different bug); but the user's generic font choices are not retained, which is wrong.
Reporter | ||
Comment 1•23 years ago
|
||
Er, `Allow documents to use other colors' should be `Allow documents to use other fonts'. Sorry for the confusion.
Comment 3•23 years ago
|
||
The setting should be renamed as "Allow documents to specify fonts". See bug 105297 for more info. This bug could even be closed as dup.
Assignee: pierre → dbaron
Depends on: 105297
Reporter | ||
Comment 4•22 years ago
|
||
No, it's not a dup. Bug 105297 appears to have been backing out an earlier attempt to fix this bug, for the sake of a rare case where an author incorrectly specifies more than one generic, which seems like an odd decision. Predictably, I don't think much of the idea of renaming the pref to describe the bug.
Summary: `Always use my font settings' ignores my generic family font settings → Generic font family settings ignored when `Allow documents to use other fonts' is off
The bug in bug 105297 was deeper than that one case.
Severity: normal → enhancement
Status: NEW → ASSIGNED
OS: Mac System 9.x → All
Priority: -- → P3
Hardware: Macintosh → All
Target Milestone: --- → Future
Comment 6•22 years ago
|
||
I would increase severity to normal because it breaks <PRE> rendering if monotype font is set in its style definition and "Allow documents to use other fonts" is not set. I will attach a testcase shortly. Best wishes Tometzky -- ...although Eating Honey was a very good thing to do, there was a moment just before you began to eat it which was better than when you were... [Winnie the Pooh]
Comment 7•22 years ago
|
||
Comment 8•22 years ago
|
||
I have written a patch for this bug. It's very simple and ugly but it should work. It ignores useDocumentFonts (forces TRUE) if current font is one of generic fonts ("serif", "sans-serif", "monotype" etc.). But I can not test it properly. My computer is a little too slow for compiling Mozilla - I don't have enough patience, sorry. Could you check it, please? One more thing: it disables patch for bug 105297, so if it's accepted that bug has to be reviewed too. Best wishes Tometzky -- ...although Eating Honey was a very good thing to do, there was a moment just before you began to eat it which was better than when you were... Winnie the Pooh
*** Bug 155026 has been marked as a duplicate of this bug. ***
Summary: Generic font family settings ignored when `Allow documents to use other fonts' is off → [STYLEPREF]Generic font family settings ignored when `Allow documents to use other fonts' is off
Summary: [STYLEPREF]Generic font family settings ignored when `Allow documents to use other fonts' is off → [Pref Stylesheet]Generic font family settings ignored when `Allow documents to use other fonts' is off
*** Bug 158401 has been marked as a duplicate of this bug. ***
Comment 11•22 years ago
|
||
Comment on attachment 84929 [details] [diff] [review] Proposed patch for 1.0rc3. Not tested, sorry. I can confirm that this patch fixes the testcase.
*** Bug 179436 has been marked as a duplicate of this bug. ***
Priority: P3 → P1
Comment 13•22 years ago
|
||
dbaron: Assuming the patch is not the right way to fix this, could you mark it obsolete? (It's not long.)
Comment 14•22 years ago
|
||
Just tested - Bug is still present on my machine, in Mozilla 1.2.1 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130)
Comment 15•22 years ago
|
||
Adding vote, and removing (broken) URL. It's nice to have actually found a bug before I filed a dup for once.
Comment on attachment 84929 [details] [diff] [review] Proposed patch for 1.0rc3. Not tested, sorry. This may be wrong because we also need to use a generic, if present, at the end of a font-family list. Also, once this bug is fixed, we should be able to remove '-moz-fixed'.
Blocks: 159440
Comment 17•21 years ago
|
||
*** Bug 205537 has been marked as a duplicate of this bug. ***
Comment 18•21 years ago
|
||
This bug is still present in 1.4rc3 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624) on Windows 2000.
Comment 19•21 years ago
|
||
*** Bug 225047 has been marked as a duplicate of this bug. ***
Comment 20•21 years ago
|
||
This bug is still present in 1.6 (Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113) I noticed it when I turned of the "...use other fonts" option and saw pages switch from sans-serif to serif. Example: http://www.intellicast.com/Local/USLocalStd.asp?loc=kezf&seg=LocalWeather&prodgrp=Forecasts&product=Forecast&prodnav=none&pid=none The daily forecast text is coded with <font face="Verdana, Arial, Helvetica, sans-serif">. With the abovementioned option disabbled, one would expect Moz to reject the first three fonts listed and accept sans-serif. Instead it uses the serif font. I hope a fix for this will be found. Restricting pages to the standard fonts would help legibility in many cases and even save a little memory.
Reporter | ||
Comment 21•21 years ago
|
||
(For bonus points, a fix for this bug could allow embeddors to specify *which* families are respected when other fonts are prohibited, so it can reflect the simplicity or complexity of the embeddor's font prefs interface. For example, a simpler browser might allow only Serif, Sans-Serif, and Monospace to be configured, so its equivalent pref should result in only those three families being used. And in MSIE/Windows' font prefs, only Proportional and Monospace can be configured, so "Ignore font styles specified on Web pages" results in only two families being used.)
Comment 22•20 years ago
|
||
Here's a complete example to easily demonstrate this bug. <html> <head> <style type="text/css"> <!-- input { font-family: monospace; } --> </style> </head> <body> <input type="text" value="This should be monospace." size=25> <p>The input text should be monospace, regardless of the "allow documents to use other fonts" setting.</p> </body> </html>
Comment 23•20 years ago
|
||
Is this bug really an enhancement??? I don't think so. Mozilla is clearly broken if it's not using the monospace font specified by the user for <pre>-tagged text! Most annoying, especially since there's a working patch here that hasn't been landed for nearly two years. Basically my choice currently is either to submit myself to the font whims of dubious web designers or have all <pre>-tagged text displayed using the serif/sans-serif proportional font of my choice. Wonderful. Anyway, this "enhancement" is getting my vote.
Comment 24•20 years ago
|
||
I've just tried applying the patch manually, and it doesn't fix all the problems. If you say <pre style="font-family: monospace;"> ... </pre> it's now correctly styled. But if it says <pre style="font-family: lucidatypewriter, monospace;"> ... </pre> it still gets rendered in the wrong (proportional) font. However, with the patch applied, you can work around the bug by putting pre { font-family: monospace ! important; } in userContent.css, so it is an improvement....
Comment 25•20 years ago
|
||
Indeed, I just noticed this bug. I personally believe it's pretty clear that this is not an enhancement but a bona-fide bug. Consider: Many websites use "font-family: Verdana, Arial, sans-serif" in their stylesheet. Of course, in most cases, simply using sans-serif would be sufficient (since I believe MSIE defaults to Verdana for sans-serif anyway), and would allow the user to easily pick an alternate sans-serif font. I personally don't like Verdana's handling of the "cl" character pair, so I want to use Bitstream Vera Sans. However, turning off the "Allow documents to use other fonts" option results in things which are clearly styled with a font-family of "sans-serif" (when there are preceeding definite typefaces) being rendered using my serif font. Maybe we should have multiple overrides: Use my typefaces, use only one font family (and my typeface), allow document to specify everything, etc. Just a thought, but I think this is pretty clearly a bug.
Comment 26•20 years ago
|
||
*** Bug 262975 has been marked as a duplicate of this bug. ***
Comment 27•20 years ago
|
||
This bug is still present in Firefox 1.0. Regarding the "Severity: enhancement": When a style-sheet specifies pre { font-family: monospace; } and the browser renders it with a proportional font I would call this a major bug!
Comment 28•20 years ago
|
||
BTW, what rendering would you guys expect if it was instead: pre { font-family: courier new; } /* note the lack of a generic type */ [then generalize the solution that you come up with to all elements, not just pre]
Comment 29•20 years ago
|
||
Well, IMHO simply ignoring all font-family attributes would be better then the current behaviour. But best would be to honour the generic fonts and ignoring all specific one. Typical example where this would be preferable over ingoring the attribute completely is: textarea { font-family: Helvetica,sans-serif; } versus textarea { font-family: Courier,monospace; } I'm no css-wizard and there may be problems I don't see but is this unreasonable? PS: Of course, all this only when the preference "Always use my fonts" is set.
Comment 30•20 years ago
|
||
*** Bug 274241 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Flags: blocking-aviary1.0.7?
Please don't nominate bugs like this for security releases.
Flags: blocking-aviary1.0.8? → blocking-aviary1.0.8-
Comment 32•19 years ago
|
||
*** Bug 315360 has been marked as a duplicate of this bug. ***
Comment 33•19 years ago
|
||
This is definitely *not* an enhancement, but a major bug. Please update the Severity, it should block any further Firefox versions, especially 1.5.
Comment 34•19 years ago
|
||
*** Bug 321550 has been marked as a duplicate of this bug. ***
Comment 35•19 years ago
|
||
The attached zip file shows a tigris subversion repository webpage, both with and without monospaced inside of a region of text formatted with <PRE>. PRE uses fixed width fonts if no "font-style: monospace;"; PRE doesn't use fixed width fonts if there is "font-style: monospace;"; The bug seems to be the same (serious) bug that was demonstrated 3.5 years ago, in this attached test document: https://bugzilla.mozilla.org/attachment.cgi?id=84918&action=view
Comment 36•19 years ago
|
||
*** Bug 325168 has been marked as a duplicate of this bug. ***
*** Bug 294448 has been marked as a duplicate of this bug. ***
The patch I just attached to bug 159440 mostly fixes this bug, except it doesn't allow pages to choose between all the generics, only between monospace / non-monospace. I think that's actually all I want to fix (i.e., I want to mark this bug half-FIXED (or duplicate of bug 159440) and half-INVALID), but I'm not sure about that yet.
Comment 39•18 years ago
|
||
This bug is still present in Firefox 2.0... Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Firefox 2.0 is based on a Gecko that branched on August 12, 2005, well before bug 159440 was fixed.
QA Contact: ian → style-system
Priority: P1 → P4
Assignee: dbaron → nobody
Comment 44•6 years ago
|
||
No assignee, updating the status.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•