Closed Bug 23461 Opened 25 years ago Closed 25 years ago

font size with no units is misintepreted in QuirkMode

Categories

(Core :: CSS Parsing and Computation, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: michael.j.lowe, Assigned: attinasi)

References

()

Details

(Keywords: testcase, verifyme)

Attachments

(1 file)

On this page after the stylesheet loads, a large part of the text becomes much
smaller than intended.   I think the page may be using some invalid css, but in
Mozilla quirks mode, it should be rendered as Navigator 4.x does it.
Attached file Testcase
Whiteboard: [TESTCASE]
This is the testcase markup:

<P style="font-size: 2">
  <font size="3">
    Computer Engineering
  </font>
</P>
I see this also on Win98 with build 2000011210.
The testcase can be reduced even more to

  <font size="3">
    Computer Engineering
  </font>

It's just a matter of interpreting correctly FONT SIZE="number" with a number
between 1 and 7.
Status: NEW → ASSIGNED
My mistake: the testcase does require the code as written by Mats:
<P style="font-size: 2">
  <font size="3">
    Computer Engineering
  </font>
</P>

For some reason, it was decided (in nsHTMLFontElement.cpp line 268) to ignore the
<font size> tag in NavQuirks mode if the font size was already explicitely set.
In the testcase above, the <p> tag sets the font size to 2px and <font size> tag
is ignored.

I don't know why we have that quirk. It's been around since the origin of that
file. I'm going to ask whether it can be removed.
Here is a better test case which demonstrates what needs to be emulated by
Mozilla in NavQuirks mode:

<html>
<P style="font-size: 5">
   <font size="3">
     Will use size from font tag (3)
   </font>
</P>
<P style="font-size: 5px">
   <font size="3">
     Will use size from P tag (5px)
   </font>
</P>
</html>

In the first paragraph, the paragraph style font size is deemed to be invalid I
guess because it lacks units, and so the size from font tag is used.

In the second paragraph, the paragraph style font size has px units and so is
used instead of size from font tag.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp
This bug is related to - and maybe a duplicate of - bug 25810.
Reassigned to attinasi.
Assignee: pierre → attinasi
Status: ASSIGNED → NEW
Summary: [4.xP] font size misintepreted → font size misintepreted
Whiteboard: [TESTCASE]
Status: NEW → ASSIGNED
There are two bugs here: 
1) Where a font-size is specified without units it is getting a default unit of 
px, whereas Nav4.x ignored it altogether.
2) When a font size is set in a containing block's style-rule, the size in the 
FONT tag is ignored, whereas Nav4.x honored it.

The second is a dup of bug 25810, but the first is a valid quirk-mode bug. 
Changing the description to reflect the first part of the bug.

New Bug Summary: Specifying a font-size style rule with no units on the 
font-size value should cause the rule to be ignored in quirk-mode.
Summary: font size misintepreted → font size with no units is misintepreted in QuirkMode
Code in nsCSSParser.cpp line 2298 explicitly gives unitless values a unit of px 
in NavQuirks mode. The comment says that is what Nav does. Presumably, other 
attribute values are assumed to be px when unitless, and the routine at the 
specified line (ParseVariant) is used for all kinds of attributes. So, we cannot 
just remove or change the quirk-code, since it is probably necessary for other 
attributes, but we must enforce the font-size quirk where no unit means ignore 
it. The ParseVariant routine could pass out information to the caller (via a 
member or out-param?) to indicate that the unit was absent, and the caller can 
then enforce the attribute-specific quirk-logic... The other solution is just to 
live with this quirk-incompatibility and resolve this bug as  WONTFIX. (How many 
documents are there with font-size specified with no units where we WANT to 
ignore the font size?)
CSSParserImpl::ParseSingleValueProperty when propID is eCSSProperty_font_size 
can trap the return, look at the token-type and determine if the unit was 
missing. If so, it can return false and the style is ignored. I have tested 
this and it works. Fix checkin is pending review. NOTE: this fixes only the 
quirk-mode problem where we were accepting font-size values with no units. With 
this fix font-size values with no units will be ignored, as Nav4 ignores them.
Fixed. r=pierre
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Keywords: verifyme
Verified fixed in mozilla bits from 071108 on NT4.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: