limit allowed number of nested <big>s




16 years ago
11 years ago


(Reporter: xyerp, Unassigned)




Firefox Tracking Flags

(Not tracked)




(2 attachments)



16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

The page is so badly deformed that nothing can be seen other than a huge black
square in the middle of an ever more huge white square. The page is correctly
displayed is all other browsers, including the Linux version of Mozilla. This is
not the only site I have seen this happen on. Unfortunately I cannot remember
the other URL, but I believe it was another IBM page...

Reproducible: Always

Steps to Reproduce:
1. Go to the URL
2. Look at the page
3. Cry

Actual Results:  
I used Microsoft Internet Explorer to view the page

Expected Results:  
Displayed the page so it could be read by a human

Comment 1

16 years ago
Problem on this page are all these <big> tags in the beginning:
<div align="Center"><big></big>
src="sblimlogo-35x143.jpg" border="0">
</big></big></big><big><big><big>  Project</big></big></big></h1>
<big> </big></div>

(Though the pages renders fine in IE and  Opera 7.11)

Comment 2

16 years ago
DOM inspector shows a computed style for the text ("The") between all those
<big>s is 2767px. scrolling around, you can see the text is actually being drawn
correctly at that size! (and the rest of the content is way below, of course).
So it is actually well-formed, if rather large.

The HTML standards don't specify about what should happen, however, IE and Opera
seem to ignore further nested <big>s after the 4th level. Evidently we just
carry on getting bigger and bigger... It's certainly crappy coding on the page,
but maybe it would be sensible to have a limit like those other browsers (e.g.
use big > big > big > big > big {font-size: inherit} )

confirming as an enhancement request.
Assignee: general → font
Severity: normal → enhancement
Component: Browser-General → Layout: Fonts and Text
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: general → ian
Hardware: PC → All


16 years ago
Summary: Web page TOTALLY malformed. → set size limit for computed font size.
It amusingly also overflows the text zoom code quite dramatically, although
that's another bug altogether.

I think the summary is wrong, the better solution is to just limit it to <big>.
It may also make sense to make it a quirk.
Component: Layout: Fonts and Text → Style System
Keywords: compat
Summary: set size limit for computed font size. → limit allowed number of nested <big>s

Comment 4

16 years ago
Looks to me like Opera & IE must be copying Netscape 3 (2?, 1?), which
apparently caps nested <big>'s at <font size=7>, as does Netscape 4.

<small> does the same thing. In Moz, it keeps getting smaller. In Netscape 3,
nested <small>'s stop at <font size=1>.

We could do either the same, or limit to css xx-large/xx-small. Page designers
who need text bigger or smaller than that can do it with css.

Comment 5

16 years ago
Created attachment 123719 [details]
HTML Testcase

Comment 6

16 years ago
*** Bug 210306 has been marked as a duplicate of this bug. ***
So we're just suggesting adding:

big > big > big > big > big { font-size: inherit }

to quirk.css?  Would that be sufficient for what we want?

Or would we want something more like:

big big big big big { font-size: inherit }

(much slower, unfortunately).

Comment 8

16 years ago
well the big > big > big ... was what I'd thought of, and it would handle the
page this was reported on.

but now you come to mention it, big big big ... would actually be better, and we
would then behave the same as IE (and Opera, and I guess NS4) in other cases too.

In what cases would the slower version cause a performance hit? only pages with
nested bigs, or all pages with a big tag, or all quirks pages?

If it's all quirks pages, I guess probably best to go with the faster solution.
 If it's only silly pages with nested bigs, then probably better for them to be
slower but more likely to be readable.
The slower version would be a perf hit on all quirks pages with a <big> tag. 
Which may in fact be not that many pages...

Comment 10

16 years ago
Created attachment 126712 [details]
testcase using first child rule (quirks doctype)

The first child rule isn't going to be enough. IE6 won't permit <big>'s to go
past <font size=7>, but Mozilla is not so constrained.
Does this really affect enough pages for us to care?

Comment 12

16 years ago
If anyone has a page entitled "how to make Mozilla look incompetent", this
should be near the top of the list. If authors need text bigger than size=7 they
should use CSS.
Um... how does this make Mozilla look incompetent?  It makes IE look incompetent
for sure (I ask it to make text "big" and it does not).

Comment 14

16 years ago
besides which (and someone will correct me if I'm wrong), there's no easy way of
saying "if the current computed font size is smaller than X, then make this
bigger, otherwise keep it the same".  A simple fix now is better than aiming for
a complex fix that will never happen...

I note that the page which was the subject of the report has since been fixed...

Comment 15

16 years ago
Unless we are expecting people to be using Mozilla at 10,000px wide resolution
in the foreseeable future, there is simply no good reason for HTML markup to
result in 1,000px+ character sizes. Netscape 3 & 4 didn't do it. IE doesn't do
it. Mozilla shouldn't do it either. It makes Mozilla look incompetent (comment
2) to display a 2767px character in a viewport at most maybe 1600px wide. No
useful message can be conveyed that way.

If limiting HTML to a maximum of size=7 like IE & the old browsers do is missing
from the HTML standard, that's a fault of the standard. If page designers really
want 1,000px text characters, make them use CSS.

Comment 16

16 years ago
I vote we put BZ's first child rule in as a stopgap. It simply is not a fix for
this behavior, which could be fixed, since that's the way everyone else behaves.

Comment 18

16 years ago
At 1024x768 using Modern fullscreen with text-only buttons, no personal toolbar,
and no tabs, the 11th big makes "1" the height of the 635px tall viewport.
NAICT, this means it takes roughly 12 bigs to achieve 1000px in height, which is
only 8 more than size=7.

By my count, there are 17 continguous bigs in comment 2, the source from the
original URL, a live web page. Not counting the opening H1, it only takes 4 of
them to reach size=7. When I bump resolution back to 640x480, leaving default at
16px, only the 6th excess big is sufficient to make the text taller than the
viewport, and thus incapable of conveying a useful message. I don't believe I
was exaggerating at all in comment 15.
One, two, or three bigs larger than <font size="7"> is perfectly legitimate, though.

Comment 20

16 years ago
The question is "why not".  There is nothing in the HTML spec prohibiting it,
and I fail to see why the following markup:

<font size="7">Text <big>bigger</big> text</font>

Should only produce text of one size.  I _told_ the friggin' browser to make
"bigger" big, so it should do as I told it.

Comment 22

16 years ago
That it isn't in the HTML spec is an HTML spec flaw, probably just minor issue
oversight during formulation, not a justification for extending the power of
HTML as a presentation where others unanimously haven't, don't and most likely
won't; and there exists a better way in CSS.

The original URL looked broken to any reasonable Mozilla user, which is the
bigger real problem.

If you really want it that big, you have CSS, you have zoom, and you can
increase your default size.

Should <small> <small> <small> <small> <small> <small> <small> also be OK? It's
just as useless as 17 bigs, or 12, or maybe even 10.

Where should a line be drawn? Or, should there be no line at all? I'm not
normally one to favor constraint, but here is an exception.
> That it isn't in the HTML spec is an HTML spec flaw

The fact that you think so does not make it so....

The question becomes whether we should be imposing random inconsistent behavior
on authors.  Right now, our behavior is consistent -- <big> makes text bigger,
interacting well with things like CSS styling, text zoom, etc.  With your
proposal, that will no longer be the case.  That's a rather big loss, for
minimal gain (none that I can see, really).  It's always possible to create HTML
markup that looks moronic; we can't stop people from shooting themselves in the

Comment 24

16 years ago
OK. Pretend the spec isn't flawed. Make the authors happy. Help them to be as
stupid as possible.  Prolong the "it works fine in [name any non-Gecko browser]"
mantra that makes the non-techie real human users see only that Gecko fails on
yet another page.

I thought we wanted designers to abandon HTML presentation and use CSS
exclusively.  Here's a way to nudge that forward, albeit a teensy one.

Mozilla is a user agent, not a designer agent. Users need a little help now and
then, and protection from excessive designer stupidity is a plus here.
I don't see how it is a help, actually. It just hides their mistake from them.

In any case, the URI given in the original bug report works, now, so if we
wanted to add this as a quirk, we'd have to find another page that it affected.

-> WONTFIX. The two most active Layout hackers, and the Layout QA guy, seem to
agree that there isn't much need to do this.
Last Resolved: 16 years ago
Resolution: --- → WONTFIX

Comment 26

16 years ago
I doubt the page "designers" employing a gazillion bigs and omitting CSS,
doctypes, and charsets are using Mozilla to do their dirty work.

This bug is a non-issue. Wontfixing this simply means performance and technical
standards compliance again beat out looking good to people who don't understand
where ultimate responsibility for an encountered problem lies.

A high level issue has arisen here. Sometimes it is insufficient to be
altruistic, to be moral in fact, to do what is in fact best for the greater
good. Hixie's track record is a worthy one. Nevertheless, recusal from certain
decision making may be appropriate to consider.
> This bug is a non-issue.

Wontfixing it is ok then, I assume.

> Wontfixing this simply means performance and technical standards compliance 
> again beat out looking good to people who don't understand where ultimate 
> responsibility for an encountered problem lies.

"Looking good to authors who blame browsers for their mistakes" does not appear 
to be one of the stated goals for Mozilla, so the fact that performance and 
standards compliance has beaten it would seem to be in line with expectations.

> A high level issue has arisen here. [snip rhetoric] Nevertheless, recusal from 
> certain decision making may be appropriate to consider.

I assume you mean "please re-open this bug". If this bug is indeed a "high level 
issue", please show us sites affected by this bug. There is absolutely no point 
us reducing performance on all pages that use <big> just to handle an edge case 
with very few real life occurances.

Comment 28

16 years ago
Wontfixing is not OK with me, but the minescule impact of this behavior doesn't
merit further quibbling.

Here I'm not at all interested in how we look to authors, only how we look to
users. To the user, Mozilla looks broken (incompetent).

I meant my last comment 26 paragraph to be taken literally. It was not about
this bug, except for its inclusion in a particular universe.

Comment 29

16 years ago
You've agreed that this bug is a minuscule issue, and I don't think anyone has
disagreed, so I don't see any problem with a WONTFIX.

Unless there are other examples of the same thing in existance, users won't even
see this happening, so the wider issue is irrelevant to this bug.  Bugzilla is
not the place to discuss wider issues...

Comment 30

16 years ago
having said that...

bug 210991 is another example of the same thing, and it causes a crash.

Comment 32

15 years ago
Bug 224181 many <big> cause Browser crash : "Bad length"
could also fit in here, as the fontsize has been caused by many nested <big>
tags, but has been duped to the bug showing the same message: 
Bug 192397 Font sizes over 300pt crash mozilla built with xft and gtk2

Comment 34

15 years ago
*** Bug 241024 has been marked as a duplicate of this bug. ***
Duplicate of this bug: 423262

Comment 37

11 years ago
It is incomprehensible to me that this situation has been evident for nearly five years without some solution arising. The fact that some site developers only check their results only with IE (or less likely Opera) can result in the problem. Isn't it possible for FireFox to display something like a warning when it runs into a non-standard which is known to deliver very incompatible results (as compared to IE)? Something like "Inappropriate use of <big> detected, contact page developer."

My involvement here is that I told the developer's customer that the page  was very faulty (along some others), not knowing who the developer was, and was told, essentially, that it works OK in IE so it must be FireFox's fault. And the customer was my local small-town police department!


Comment 38

11 years ago
Workaround for users needing to access pages this affects: add the following to userContent.css in your profile's chrome directory:

	big {font-size: large !important;}

That will effectively disregard normal font size inheritance, instead creating a nesting level limit of 1, basing upon the browser's default size setting.

Comment 39

11 years ago
Am I way off base? Isn't the best work-around to use IE or Opera to view these pages?  I still think a visible FireFox alert to the viewer that the fault on the page lies with the developer not with FF is a reasonable solution.
You need to log in before you can comment on or make changes to this bug.