Closed Bug 222503 Opened 22 years ago Closed 22 years ago

overlong <pre style="overflow:auto"> hangs Mozilla

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: vbraun, Unassigned)

References

(
URL
)

Details

(Keywords: hang, testcase)

Attachments

(3 files)

Testcase (saving URL for posterity)
124 bytes, text/html
Details
Call stack
4.31 KB, text/plain
Details
trace output
1.65 KB, text/plain
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/0 Galeon/1.3.7 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 If the text within a <pre style="overflow:auto"></pre> does not fit into the browser window then Mozilla will hang. The same thing happens if the overflow:auto style is selected via a separate stylesheet. Hang here means that there will be no redraws in any Mozilla window opened. The only recourse is to close the Mozilla window with the overlong line - if there are other windows then they redraw correctly afterwards. Minimal example document exhibiting the issue: <html> <head></head> <body> <pre style="overflow:auto">The quick brown fox jumps over the lazy dog.</pre> </body> </html> Reproducible: Always Steps to Reproduce: 1. Load a webpage with above tag 2. Make Mozilla window thinner until the text does not fit into one line Actual Results: Mozilla hangs
Works for me 20031012 PC/WinXP
Confirming bug, 2003-10-16-05 trunk Linux. 100% CPU hang. Bug also occurs in Mozilla 1.5
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: hang, testcase
This worksforme in a 2003-10-15-22 nightly and my cvs builds... what's the catch?
Still 100% reproducible in 2003-10-29-05 on Linux. I stuck a printf in nsBlockFrame::Reflow and watched it fill my console for several minutes before I killed it. Since we don't blow the stack and crash, I guess the reflow somehow causes a reason for a new reflow, ad infinitum. Let me know if you have any tips on debugging this further.
Assignee: dbaron → other
Component: Style System (CSS) → Layout
wfm Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031028
Maybe break in nsXULElement::SetAttribute and see whether it's being called over and over again on <scrollbar> nodes?
I did put a printf in nsXULElement::SetAttribute() - it is NOT called over and over again. The infinite loop involves reflowing all (3) block frames: nsBlockFrame::Reflow: Area(html)(-1)@0x826852c nsBlockFrame::Reflow: Block(body)(2)@0x8268730 nsBlockFrame::Reflow: Area(pre)(1)@0x8268afc nsBlockFrame::Reflow: Area(html)(-1)@0x826852c nsBlockFrame::Reflow: Block(body)(2)@0x8268730 nsBlockFrame::Reflow: Area(pre)(1)@0x8268afc ... etc ...
Blocks: 225326
Worksforme as well. What's the outermost loop that's looping?
The problem seems to be that reflowing PRE adds a new incremental reflow command targeted at BODY which leads to a reflow of the whole ViewportFrame... Stack and trace printfs follows.
Attached file Call stack —
Attached file trace output —
Works with Mozilla 1.6, changing to FIXED.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
without knowing what fixed it, it should be worksforme
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: