49927 - Loading web page halts M17

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Neil Fraser]

Open M17, go to http://www.emericaskate.com/
Browser can be seen drawing the black frames, then becomes permanently
unresponsive.

No excuses about the quality of the offending site, it was afterall featured on
websitesthatsuck.com, but that still doesn't excuse a hanging browser.

Comment 1

[Gilles Durys]

Works fine for me on M17 build 2000080712 and on build M18 build 2000082208 on 
NT4 SP6a

Comment 2

[R.K.Aa.]

does not work fine on linux 2000082221 - confirming bug.

A "continue" in gdb after breaks, hinted about this candidate struggling with a
loop:

0x4011695f in js_GC () from /tmp/package/./libmozjs.so
and
0x40115d31 in js_AllocGCThing () from /tmp/package/./libmozjs.so

The loop is extremely CPU intensive (as usual), 99.7 % used.
Not sure about component.

Comment 3

[Neil Fraser]

I have created a demonstration page for this bug and reduced as much of the
peripheral garbage as possible:
  http://mozilla.digitalroutes.co.uk/

* frame.html is the page that demos the bug.
* left.html is a frame with Javascript that attempts to redirect to one of
several (non-existant) pages.
* right.html is a minimal html document.
No other files are required.  Linux's M17 still freezes just as it does for the
emericaskate site.  Hope this helps!

Comment 4

[Asa Dotzler [:asa]]

reassign.

Comment 5

[Phil Schwartau]

Using Mozilla tip builds 2000-08-23 on WinNT, 2000-08-24 on Linux.
Confirming bug. I notice that while Mozilla seems to be hanging, there 
are actually hundreds of these messages being sent to the debug console:

         .
         .
Enabling Quirk StyleSheet
Enabling Quirk StyleSheet
Enabling Quirk StyleSheet
Enabling Quirk StyleSheet
         .
         .

I interrupted this on Linux to get a stack trace; will attach below.
Changing OS to "All".

Comment 6

[Phil Schwartau]

Attachment: Linux stack trace -

Comment 7

[Phil Schwartau]

No JS Engine issues apparent in stack trace. 
Reassigning to Layout component -

Comment 8

[Phil Schwartau]

Reassigning to evaughan, because of all the "nsBoxFrames" in the trace -
Note: this bug and bug 50129 may be related - same symptoms...

Comment 9

[Eric Vaughan]

Any UI stack trace will have many many boxes in it because mozilla's UI is built 
almost entirely out of them. But this stack trace is croking somewhere in the 
file transport code while loading the background image. We should try this in 
viewer. That would tell us if it had anything to do with XUL or not.

Comment 10

[Eric Vaughan]

Just tried this in the current build. It no longer crashed and seems to work 
quite well.

Comment 11

[Phil Schwartau]

Using: Mozilla binary and commercial builds 2000090110 on WinNT 
       Mozilla binary and commercial builds 2000090111 on Linux

Mozilla no longer hangs, but does not render the page completely.
At the given URL, http://www.emericaskate.com/, there are many small images
to the right which load fine. However, there is also supposed to be a large
image in the center of the page. You can see this if you load the page in 
NN4.x or in IE4.x. None of the four Mozilla builds above load this image
when you first log on to the site.

In addition, Neil Fraser's test case (see 2000-08-23 08:20 above) loads 
incompletely: http://mozilla.digitalroutes.co.uk/frame.html 

If you load this in NN4.x or IE4.x, you see text to the left of the divider.
(a 404 message). In Mozilla, everything to the left of the divider is blank.

Reopening and changing summary -

Comment 12

[Peter Trudelle]

Sounds like this is morphing into some other bug.  Shouldn't the incomplete load
be filed separately?  

Comment 13

[Phil Schwartau]

Opened bug 51127 to reflect the new problem - 

Changing summary on this bug back to what it was, and also its status 
(Resolved WorksForMe)