Closed
Bug 234913
Opened 20 years ago
Closed 13 years ago
select all on XML pretty-printed page hangs browser
Categories
(Core :: XBL, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mconnor, Unassigned)
References
(Depends on 1 open bug, )
Details
Attachments
(3 files)
sicking told me to file this here :) on current trunk win32 builds (tested seamonkey and Firefox nightlies) hitting Ctrl-A to select all on a pretty-printed XML page, see the URL.
Comment 1•20 years ago
|
||
Where does it hang?
Comment 2•20 years ago
|
||
WFM, Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040219 Firefox/0.8.0+
Comment 3•20 years ago
|
||
(In reply to comment #0) > on current trunk win32 builds (tested seamonkey and Firefox nightlies) It also hangs on also on firefox 0.8 and mozilla 1.4 under Mandrake Linux.
Comment 4•20 years ago
|
||
I just pulled mozilla from CVS, built it on a box running Mandrake Linux (2.4.22-26mdk), reproduced the hang, attached to it with gdb and typed 'where' to get this output
Comment 5•20 years ago
|
||
I continued, waited for a while, hit control C and ran 'where' again. The stack is different.
Comment 6•20 years ago
|
||
And a third time. I waited 5 or 10 minutes before interrupting it this time. Note the bottom of the stack is different here. Standard output had said: "WARNING: Dropping timer event because thread is dead, file nsTimerImpl.cpp, line 498"
Comment 7•20 years ago
|
||
(In reply to comment #1) > Where does it hang? See the 3 attachments. They are from gdb's "where" command. All 3 are from the same 'hang'.
Comment 8•20 years ago
|
||
Interesting... Could someone create a minimal-ish file that shows this problem? It looks like the frame tree is screwed up and FindFrameWithContent loops....
Comment 9•20 years ago
|
||
(In reply to comment #8) > Interesting... Could someone create a minimal-ish file that shows this problem? > It looks like the frame tree is screwed up and FindFrameWithContent loops.... I just tried to create a minimal file that shows the problem, but I can't, because the problem doesn't exist... I started with the original file and started removing chunks. Eventually, what happened was that control-a started working, albeit very slowly. It turns out that this *isn't* hanging the browser, it's just making it very very slow. Anyway, here's a smaller version of the file: http://s89213869.onlinehome.us/xml.cgi (it's a small CGI script that prints a "Content-Type: xml\n\n" header and then cats a .xml file; I'm not apache expert and this was the easiest way for me to generate the correct header. The bug doesn't show itself without the header). It exhibits the problem to a lesser extent - control A is slow, but doesn't hang the browser. Try the following steps: 1) visit http://s89213869.onlinehome.us/xml.cgi 2) select a small piece of text with the mouse; it will be highlighted 3) press control-A; after about a second (on a 2.2GHz P4) the highlighting disappears. 4) try resizing the window; the refresh takes a long time, longer than the 'control a' in the previous step took 5) switch tabs, or cover the browser window and uncover it again, or do pretty much anything, and it's slow. 6) select a small piece of text again and everything's back to normal speed. I hope this helps!
Comment 10•20 years ago
|
||
*** Bug 235121 has been marked as a duplicate of this bug. ***
Comment 11•20 years ago
|
||
Probably has to do more with the fact that table cells/rows/whatever don't get stored in the primary frame map (and that as a result GetPrimaryFrameFor() is O(N) in number of previous siblings for them) than with XBL.... Could someone try building the DOM that prettyprinting builds without the binding and all that rigmarole and seeing whether that has the same problems?
Comment 12•19 years ago
|
||
*** Bug 238838 has been marked as a duplicate of this bug. ***
Is this still an issue on trunk since we've simplified the prettyprint DOM?
Updated•15 years ago
|
QA Contact: ian → xbl
Updated•15 years ago
|
Assignee: hyatt → nobody
Comment 14•13 years ago
|
||
WFM Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110110 Firefox/4.0b9pre using testcase from bug 292631 https://bug292248.bugzilla.mozilla.org/attachment.cgi?id=182378 this bug's test url and http://s89213869.onlinehome.us/xml.cgi no longer exist.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Comment 15•13 years ago
|
||
Probably fixed by not having FindFrameWithContent anymore and just storing the frame in the nsIContent.
You need to log in
before you can comment on or make changes to this bug.
Description
•