Closed Bug 72360 Opened 24 years ago Closed 18 years ago

incorrect layout with anonymous table frames

Categories

(Core :: Layout: Tables, defect)

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

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ian, Unassigned)

References

(
URL
)

Details

(Keywords: css2, testcase, Whiteboard: [Hixie-P1])

See http://www.damowmow.com/mozilla/crash/10.html In a debug build you will get this asserion: ASSERTION: attempt to create circular frame list: 'aNextSibling != this', file ...\mozilla\layout\html\base\src\nsFrame.cpp, line 2200 If you step past the assertion, or when using an opt build, you will then see memory usage sky-rocket, followed by an unseemly crash as the system starves us of resources. The markup is making <body> into a table, then nesting a table inside it.
Note: The fact that <body> is being turned into a table is apparently important. It doesn't happen in XML or if you use a <div> instead of <body>. Unfortunately, making <body> into a table with CSS is likely to become very common once CSS becomes usable for doing layout.
Keywords: crash, css2, mozilla1.0, testcase
Moving to m1.0
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
QA contact update
QA Contact: chrisd → amar
*** Bug 84813 has been marked as a duplicate of this bug. ***
changing OS to all based on the OS declaration (Linux) in duplicate bug 84813 Jake
OS: Windows 2000 → All
So far there have been three manifestations of this bug: http://www.damowmow.com/mozilla/crash/10.html http://bugzilla.mozilla.org/showattachment.cgi?attach_id=36317 (bug 83042) http://www.hixie.ch/tests/adhoc/css/box/table/002.html
Assignee: karnaze → waterson
URL: http://www.damowmow.com/mozilla/crash... → http://www.hixie.ch/tests/adhoc/css/b...
Status: ASSIGNED → NEW
Priority: -- → P1
Summary: Crash caused by attempting to create a circular frame list in tables → Crash caused by attempting to create a circular frame list in tables (Simple nested table causes runaway memory allocation, crash) (Infinite loop, runs out of memory and crashes)
Whiteboard: [Hixie-P1]
*** Bug 83042 has been marked as a duplicate of this bug. ***
Accepting on waterson's behalf since he accepted duplicate bug 83042.
Status: NEW → ASSIGNED
Well, if I'd _known_ this was [Hixie-P1]! ;-)
Target Milestone: mozilla1.0 → mozilla0.9.3
Well, this is certainly interesting. If I had to guess, I'd say that the logic that was added in r1.530 and later modified in r1.579 is suspect. Specifically, it seems wrong to me that the table is returning frames that it has newly appended to a pseudo-cell child back out to the topmost level. attinasi, you sr='d these changes, do you understand the table frame construction logic?
heh - I sr'd karnaze's later change (nsCSSFrameConstructor.cpp r1.579) but not the earlier one, that was buster. Anyway, I do not really understand table frame construction very well, but that change looks reasonable (and karnaze's walkthrough seemed rational too). I'll try backing out the change made for 1.579 and see if it fixes the testcases.
backing out 1.579 doesn't fix this. It might be that the more critical stuff was in the earlier patch. Anyway, there is an interesting bug that buster opened about this kind of problem, seems related to the earlier checkin: see bug 57010
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Blocks: 103709
Target Milestone: mozilla0.9.6 → mozilla0.9.7
I'm not going to get to this before mozilla-1.0. Oh okay, who am I kidding? I'm not going to get to this. karnaze, backatcha.
Assignee: waterson → karnaze
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.7 → ---
This is really nasty bug but since the new VM in the Linux 2.4.14 and newer kernels it's not crashing the whole machine. But anyway please please someone try to fix it before 1.0
Setting milestone to Moz1.1
Target Milestone: --- → mozilla1.1
Ak, I was just thinking about this bug this morning. This bug is very serious. Just think if Microsoft got a hold of this info and put the css on on their sites that would trigger this crash! Of course it wouldn't affect IE because it would ignore that css. This is just asking to be used to sabotage Mozilla users especially since it is so easy to trigger and can take down the whole machine (at least in Windows). That could me some major data loss. Heck, this could be sent by email and users of Mozilla mail would all have their machines crash. Can we get some priority on this for 1.0? Releasing 1.0 with a bug this easily exploitable will really look bad for Mozilla (and Netscape6, by proxy). Jake
Yes, Yes, Yes I second that. Nominating nsbeta1.
Keywords: nsbeta1
-->m1.0
Status: NEW → ASSIGNED
Target Milestone: mozilla1.1 → mozilla1.0
Marking nsbeta1+
Keywords: nsbeta1 → nsbeta1+
This is no longer crashing (probably fixed by bug 118465). The layout is not quite right, however. ->future,P4
Severity: critical → normal
Keywords: crash, mozilla1.0, nsbeta1+
Priority: P1 → P4
Target Milestone: mozilla1.0 → Future
Changing the summary.
Summary: Crash caused by attempting to create a circular frame list in tables (Simple nested table causes runaway memory allocation, crash) (Infinite loop, runs out of memory and crashes) → incorrect layout with anonymous table frames
Keywords: mozilla1.0+
Keywords: mozilla1.0+ → mozilla1.0-
mass reassign to default owner
Assignee: karnaze → table
Status: ASSIGNED → NEW
QA Contact: amar → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
We really should fix this. Someone basically needs to go through the anonymous table generation code and make it Work...
Priority: P4 → --
Target Milestone: Future → ---
Keywords: mozilla1.0-
QA Contact: madhur → nobody
Hardware: PC → All
I do not see the assert, the layout is correct IMHO. ==> WFM
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.