Closed Bug 452038 Opened 16 years ago Closed 5 years ago

Increase TAGLVL (only 33 nested tables isn't enough)

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: martin.loetzsch, Assigned: hsivonen)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: testcase, Whiteboard: [fixed by bug 256180])

Attachments

(1 file)

testcase #1
5.72 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

As I understand from (much) earlier related bug reports, there was a crash problem that has been fixed by limiting the maximum number of nested elements. As a result, Firefox can only display 33 nested tables as demonstrated in 

http://martin-loetzsch.de/firefox-rendering-issue/example-1.html

I would be very happy if that limit could be increased by at least factor 10. 

I guess most of you will find more than 33 nested tables a bit excessive, but with your great rendering engine it is now possible to do amazing things such as recursively drawing search trees: 

http://martin-loetzsch.de/firefox-rendering-issue/example-2.html

In this example the structures at the bottom right of the page are not displayed completely and it would be nice if they would.

Many thanks for all your work,

Martin

Reproducible: Always

Steps to Reproduce:
Go to http://martin-loetzsch.de/firefox-rendering-issue/example-1.html
Actual Results:  
This page contains 50 nested tables, of which only 33 are displayed.

Expected Results:  
All 50 nested tables should be rendered.
opera 9.6 & WebKit-SVN-r35806 show the desired 50 tables.
Fx2/3 fail.
Status: UNCONFIRMED → NEW
Component: General → Layout: Tables
Ever confirmed: true
Keywords: testcase
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → layout.tables
Hardware: Macintosh → All
Version: unspecified → Trunk
Martin, do you have the bug number for the older bug report you mentioned in comment 0?
(In reply to comment #3)
> Martin, do you have the bug number for the older bug report you mentioned in
> comment 0?
> 

In 2002 the engine could render only 12 nested tables (Bug #160555) and apparently 12 tables are ok now. One commenter wrote about a "frame level" limit of 75.

And it also similar to Bug #256180, but I actually don't care what happens with elements beyond the "TAGLVL" limit, I just want that limit to be much higher.

Martin
Summary: Only 33 nested tables isn't enough → Increase TAGLVL (only 33 nested tables isn't enough)
> I would be very happy if that limit could be increased by at least factor 10. 

Can you guarantee that that doesn't blow out the C stack on any devices that matter (including ARM mobile devices)?
(In reply to comment #5)
> > I would be very happy if that limit could be increased by at least factor 10. 
> 
> Can you guarantee that that doesn't blow out the C stack on any devices that
> matter (including ARM mobile devices)?
> 

I'm afraid I know nothing about the implementation details (I did not even know that it depends on the C stack size).

But maybe that could depend then on the operating system, i.e. that at least on Macosx and Winxp the "TAGLVL" limit is much higher. Or there could be a test for available stack size.
Well, the whole point of TAGLVL is to avoid blowing out the stack and crashing.  So it certainly depends on the stack size!  I was pretty sure the earlier bugs discussed this...

> But maybe that could depend then on the operating system

We'd really like to not have our web page rendering change radically from OS to OS.  That whole cross-platform thing and all.

Note that historically it's been Windows and Mac that have been the limiting factors in terms of stack size.  The Unix-based OSes haven't been the problem.
> Well, the whole point of TAGLVL is to avoid blowing out the stack and crashing.
>  So it certainly depends on the stack size!  I was pretty sure the earlier bugs
> discussed this...

I read all this and I understand that it is not easy.

> We'd really like to not have our web page rendering change radically from OS to
> OS.  That whole cross-platform thing and all.

This is a very valid goal as well.

---

But something needs to be done (I don't know what). You risk here to be the only web browser that can not do more than 33 nested tables. 

Although I really like using Firefox, I'm forced to use Safari now for pages such as in my second example (http://martin-loetzsch.de/firefox-rendering-issue/example-2.html).

And with increasingly faster computers (mine is four years old) it is very likely that people (including) me will want to render even much larger (more nested) pages.


Reading the replies to similar bugs, I had the feeling that the problem is seen as too difficult and thus can't be dealt with. This may very well be. But I'd really like to convince you that it's very important to find a solution (and have no clue at all).

Thanks, Martin
Mac has space for thousands of native stack frames nowadays.  How about Windows?

I don't think it's fair to limit tag nesting on desktop OSes due to a limitation specific to our code and specific to mobile devices.
there's also windows mobile and symbian.

can you provide a real use case to justify this? what's wrong w/ css?

from a qa perspective, it's really great for me to be able to tell my mobile testers to just test firefox on their desktop.

and it's bad for app devs to write something and be surprised when it doesn't work somewhere.
Target Milestone: --- → M8
Target Milestone: M8 → ---
Use Case:
The product I work on is an AJAX web application with a dynamic window-based UI. We have an automated container layout scheme. Each container/widget is wrapped in a table. This is enables accurate measurement of the effects of padding, borders and margins over all browsers & rendering modes (e.g. quirks, standards). We cannot create the complex layouts that some of our customers want because Firefox will not render the deepest children. 

About a 50% increase in DOM depth would cover us for the near future, though doubling or tripling would make me more comfortable in the long term. 

Anyone know if stack-based iteration or tail recursion has been investigated for the stack overflow issue?
http://en.wikipedia.org/wiki/Recursion_(computer_science)#Recursion_versus_iteration
> Anyone know if stack-based iteration or tail recursion has been investigated
> for the stack overflow issue?

Answered my own question: see Bug 56182 and comments in Bug 256180
(In reply to comment #10)

> can you provide a real use case to justify this? what's wrong w/ css?

We use the web browser as a GUI for visualizing internal states and processes of our agent simulation framework for artificial language evolution. This framework is written in Lisp and it communicates with the browser using ajax.

Part of this system is an implementation of a construction grammar formalism (see http://emergent-languages.org/fcg/). Processing linguistic knowledge in this formalism involves search. And because this can be very complicated, we implemented visualizations for these search trees, as for example in http://martin-loetzsch.de/firefox-rendering-issue/example-3.html. Each node in the tree can be clicked on and reveals more information about what happened (it's actually much more that we display in these nodes, including other search trees, but I did not include that to keep the file size of the examples small).

And I don't know how to do this kind of stuff without nested tables, especially when nodes can be dynamically expanded.

Of course the example in http://martin-loetzsch.de/firefox-rendering-issue/example-3.html is very simple, and we normally deal with much bigger search trees, as for example in http://martin-loetzsch.de/firefox-rendering-issue/example-4.html . But the latter is not displayed correctly in Firefox because the number of nested tables is too high (but it works in Safari).

A few years ago I could not have imagined that there would be a browser that can render megabytes of divs and tables, but now that this is possible, we also want to use it. And especially for visualizations of hierarchical structures, using the web browser is the first choice, because difficult layout decisions can be left to the (great!) rendering engine of Firefox.

Right now the Mac users in our team are forced to use Safari, the Windows users can use Chrome, but the Linux users are doomed. And all of us can't print these structures, because only Firefox creates nice pdfs from dom trees that were incrementally built by ajax calls.

So I would say it's not justified to take away the possibilities of this fantastic rendering engine from people who use Desktop OSes just because some mobile devices have smaller stack sizes.

We would be covered by a 1000% increase of the limit in the near future, and removing it in the long term would be good.

Thank you for your attention and your great work,


Martin
When using the same limit on all operating systems is really an issue, we would be also fine when this limit is something that can be set in the preferences of Firefox.

Is that limit something compiled into the code with a 
#define TAGVL 200 

or could that be changed programmatically?

Thanks, Martin
We don't seem to have TAGLVL anymore.  We do still have MAX_REFLOW_DEPTH (which as it happens is different on Mac Classic and WINCE from everything else).
Looking at the original testcase (https://bug452038.bugzilla.mozilla.org/attachment.cgi?id=335332), Firefox can do at least 50 nested tables now.

So I think this bug can be closed.
How odd. Still only 33 tables in FF 14 Mac.
(In reply to Martin Loetzsch from comment #16)
> Looking at the original testcase
> (https://bug452038.bugzilla.mozilla.org/attachment.cgi?id=335332), Firefox
> can do at least 50 nested tables now.
> 
> So I think this bug can be closed.

Ah sorry, it doesn't work. I accidentally used another browser :)

It's pretty shocking that it took four years to start tackling it.

https://bug452038.bugzilla.mozilla.org/attachment.cgi?id=335332
https://bug256180.bugzilla.mozilla.org/attachment.cgi?id=156529
Assignee: nobody → hsivonen
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 256180]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: