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)

enhancement

Tracking

()

Future

People

(Reporter: mpt, Unassigned)

References

Details

Attachments

(3 files)

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.
Er, `Allow documents to use other colors' should be `Allow documents to use 
other fonts'. Sorry for the confusion.
Style system issue: Reassigning to Pierre
Assignee: attinasi → pierre
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
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
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]
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 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. ***
dbaron: Assuming the patch is not the right way to fix this, could you mark it
obsolete? (It's not long.)
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)
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'.
*** Bug 205537 has been marked as a duplicate of this bug. ***
Blocks: 205537
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.
*** Bug 225047 has been marked as a duplicate of this bug. ***
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.
(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.)
Here's a complete example to easily demonstrate this bug.
  &lt;html>
    &lt;head>
      &lt;style type="text/css">
        &lt;!--
          input { font-family: monospace; }
          -->
      &lt;/style>
    &lt;/head>
    &lt;body>
      &lt;input type="text" value="This should be monospace." size=25>
      &lt;p>The input text should be monospace, regardless of the
      "allow documents to use other fonts" setting.&lt;/p>
    &lt;/body>
  &lt;/html>

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.
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....
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.
*** Bug 262975 has been marked as a duplicate of this bug. ***
Blocks: 269818
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!
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]
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.
*** Bug 274241 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0.7?
Please don't nominate bugs like this for security releases.
Flags: blocking-aviary1.0.8? → blocking-aviary1.0.8-
*** Bug 315360 has been marked as a duplicate of this bug. ***
This is definitely *not* an enhancement, but a major bug. Please update the Severity, it should block any further Firefox versions, especially 1.5.
*** Bug 321550 has been marked as a duplicate of this bug. ***
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
*** 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.
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
No assignee, updating the status.
Status: ASSIGNED → NEW
No assignee, updating the status.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: