234913 - select all on XML pretty-printed page hangs browser

Status: RESOLVED WORKSFORME

(Core :: XBL, defect)

Description

[Mike Connor [:mconnor]]

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

[Boris Zbarsky [:bzbarsky]]

Where does it hang?

Comment 2

[Ben Fowler]

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

[Chris Moore]

(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

[Chris Moore]

Attachment: output of gdb's "where" command during the hang

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

[Chris Moore]

Attachment: output of gdb's "where" command during the hang

I continued, waited for a while, hit control C and ran 'where' again.  The
stack is different.

Comment 6

[Chris Moore]

Attachment: output of gdb's "where" command during the hang

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

[Chris Moore]

(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

[Boris Zbarsky [:bzbarsky]]

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

[Chris Moore]

(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

[Stefan Borggraefe]

*** Bug 235121 has been marked as a duplicate of this bug. ***

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

[José Jeria]

*** Bug 238838 has been marked as a duplicate of this bug. ***

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Is this still an issue on trunk since we've simplified the prettyprint DOM?

Comment 14

[Wayne Mery (:wsmwk)]

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.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Probably fixed by not having FindFrameWithContent anymore and just storing the frame in the nsIContent.