25810 - <font size> was only ignored in Nav4 in section with *explicit* font-size {compat} {ll}

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[jonathan.brickman]

It's visible immediately upon entry to this URL.  On every other browser I have
seen, whether or not the browser even touches CSS, "AVSC's Start Spot" is rather
large, and "Suggestions?       Add you to the emailing list?" is much smaller.
Under M13, "Suggestions?       Add you to the emailing list?" is the same size
as "AVSC's Start Spot".  This web site's code is made almost entirely by a very
well-behaved and quite common WYSIWYG editor, MicroVision (www.mvd.com) WebExpress.

Comment 1

[rickg]

Mark -- please take a look.

Comment 2

[Marc Attinasi]

Attachment: Simplified test case: <FONT> tag in a <H1> is enough

Comment 3

[Marc Attinasi]

Attachment: More obvious test case; first one was too simple.

Comment 4

[Marc Attinasi]

The FONT element is inheriting the font-size from the H1 element, and the H1 
element has a font-size defined in the html.css file as a specific value (as do 
H2, H3, H5, H6). Since the FONT element is inheriting the font-size of its 
parent the text within the FONT is inheriting it as well (from the FONT 
element). There appears to be a bug in either html.css (if specific font-size 
values are suppossed to be inherited absolutely) or elsewhere if the FONT 
element is suppossed to be modifying the inherited font-size value. Awaiting 
advice and information for more knowledgable sources.

NOTE: H4 has no font-size value in html.css so it does not cause the bug.

Comment 5

[Pierre Saslawsky]

H4 should have a "font-size: 1.0em;" style rule and behave like the other 
headers.

This bug is probably be a dup of bug 23461. I'm going to reassign the latter to 
you. See my comments dated from 2000-01-13 01:13 in bug 23461 for the 
explanation.

I did not figure out why we have the quirk in nsHTMLFontElement.cpp line 268. You 
may want to try different testcase in Nav4 where the FONT has no effect if a font 
size is already explicitely set. If you don't find any, I'd suggest to get Rick's 
approval and remove the quirk.

Comment 6

[Marc Attinasi]

The problem is related to the quirk-code that Pierre identified in 
nsHTMLFontElement.cpp: if a font-size is already explicitly set then the size in 
the FONT tag is ignored. The problem is that the style system is explicitly 
setting the font size because the H1-H6 rules have and explicit font size 
(except H4 which is another bug yet to be written-up). So, the code thinks there 
is already an explicit font size set and ignores the size=n attribute on the 
FONT tag. I suggest removing this quirk, otherwise we have to find a way to 
either avoid setting the explicit-size flag on the font when the style is 
resolved for the parent H1 tag. Anyway, as the related bug 23461 indicates, the 
quirk is not really being fully emulated anyway. I'll venture off to gather 
consensus...

Comment 7

[Marc Attinasi]

It looks very much like the quirk needs to stay. The test case for bug 23461 
shows how Nav4 ignores a FONT tag's size when enclosed in a styled block with 
font-size: specified. hen I remove the qurik that test case fails. I cannot 
judge which is more important... I'll look at how to keep the heading tags from 
setting the size-explicit and see what that breaks, er, fixes.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Allowing the size specified in a font element to be ignored because of a font
size specified on the parent is incorrect according to CSS1.  That's what this
bug seems to be about, if I'm reading it correctly.

Comment 9

[Marc Attinasi]

From looking at a recent change by karnaze (nsHTMLStyleSheet.cpp) it looks like 
we can easily implement a custom style rule and override the default inheritance 
NavQuirk for Headings. I'll get on that once Beta bugs are done.

Comment 10

[Hixie (not reading bugmail)]

Nav4 and IE5 disagree. I'll attach another test case which shows the quirky 
behaviour of Nav4 for FONT in blocks with font-size compared to FONT in H1s.
Compare it in both IE and Nav to see the difference.

[lowering from "critical" severity -- this is not a crasher.]

Comment 11

[Hixie (not reading bugmail)]

Attachment: test case showing <font size> in <h1> and <font size> in <p style="font-size:20px">

Comment 12

[Hixie (not reading bugmail)]

Updating summary. (affects font size 1-7)

Comment 13

[Marc Attinasi]

This Nav Quirk is lame... IE honors the FONT tag after an explicit font size has 
been set on the parent block. I have approval from Rick G. to remove this quirk: 
it is lame and IE acts correctly. Also, since bug 23461 has been fixed, this 
change does not break that bug's testcase.

I have a simple fix (remove check for explicit font size in 
hsHTMLFontElement.cpp near line 273); is there any objection to removing this 
quirk-emulation and honoring font sizes in a FONT tag when a size is already 
explicitly set?

Comment 14

[Marc Attinasi]

Another note: with this quirk removed we honor the font size from the FONT tag, 
however IE and NAV use the line-height of the containing block whereas Mozilla 
gives each line the line-height corresponding to the size of the font applied to 
that line. This looks like another compatibility bug.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

IE5 and NN4 seem to use the line-height of the containing block only on certain
elements.  I guess I need to revisit bug 26998 on that issue as well, and
actually test every single element...

Comment 16

[Hixie (not reading bugmail)]

attinasi: I say pull the plug on the quirk!

Comment 17

[Marc Attinasi]

Removed the Quirk.

Comment 18

[Chris Petersen]

Fixed in the May 22 build.

Comment 19

[BMO Automation]

Attachment: [mozilla-mobile/firefox-android] For #25810 - Unified search 'search popup menu' should give hint to the user that there are more menu items available by scrolling (#181)

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d28d9dc9a98b
For #25810 - Unified search 'search popup menu' should give hint to user that there are more menu items available by scrolling
https://hg.mozilla.org/integration/autoland/rev/453b921854bc
[fenix] For https://github.com/mozilla-mobile/fenix/issues/25810 - Unified search should give hint to user that there are more menu items available by scrolling (https://github.com/mozilla-mobile/fenix/pull/27895)