Closed
Bug 222503
Opened 21 years ago
Closed 21 years ago
overlong <pre style="overflow:auto"> hangs Mozilla
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: vbraun, Unassigned)
References
()
Details
(Keywords: hang, testcase)
Attachments
(3 files)
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
Comment 1•21 years ago
|
||
Works for me 20031012 PC/WinXP
Comment 2•21 years ago
|
||
Confirming bug, 2003-10-16-05 trunk Linux. 100% CPU hang. Bug also occurs in Mozilla 1.5
Comment 3•21 years ago
|
||
Comment 4•21 years ago
|
||
This worksforme in a 2003-10-15-22 nightly and my cvs builds... what's the catch?
Comment 5•21 years ago
|
||
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
Comment 6•21 years ago
|
||
wfm Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031028
Comment 7•21 years ago
|
||
Maybe break in nsXULElement::SetAttribute and see whether it's being called over and over again on <scrollbar> nodes?
Comment 8•21 years ago
|
||
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 ...
Worksforme as well. What's the outermost loop that's looping?
Comment 10•21 years ago
|
||
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.
Comment 11•21 years ago
|
||
Comment 12•21 years ago
|
||
Reporter | ||
Comment 13•21 years ago
|
||
Works with Mozilla 1.6, changing to FIXED.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
without knowing what fixed it, it should be worksforme
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WORKSFORME
Updated•20 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•