92425 - JS onload changing location to do nothing causes infinite loop

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect)

Description

[Markus Hübner]

Just go to
http://www.wohnen-in-tirol.com
and see mozilla die.
Altough I am using a talkback version its completely killed and no talkback 
report is being created.

The site uses the .NET technology (.aspx pages)

Using build 2001072503

Comment 1

[Markus Hübner]

don't know exactly but I think this worked in previous builds (regression?)

Comment 2

[Francisco León]

WFM linux 7/21
The page never finished downloading ("transferring data from ...")

Comment 3

[Matthias Versen [:Matti]]

confirming with win2k build 20010725.. (trunk)
I will seacrh the correct component later. (lxr.mozilla.org and irc.mozilla.org 
is down at the moment)

removing bad keywords !

A part of the Stack trace (VC6++ reports: Stack overflow):
NTDLL! 778cc4fb()
_heap_alloc_base(unsigned int 80) line 200
_heap_alloc_dbg(unsigned int 32, int 1, const char * 0x00000000, int 0) line 378 
+ 9 bytes
_nh_malloc_dbg(unsigned int 32, int 1, int 1, const char * 0x00000000, int 0) 
line 248 + 21 bytes
_nh_malloc(unsigned int 32, int 1) line 197 + 19 bytes
operator new(unsigned int 32) line 24 + 11 bytes
XPCJSStackFrame::CreateStack(JSContext * 0x04c5cc28, JSStackFrame * 0x04d84428, 
XPCJSStackFrame * * 0x04e2fa2c) line 131 + 7 bytes
XPCJSStackFrame::CreateStack(JSContext * 0x04c5cc28, JSStackFrame * 0x04d844e0, 
XPCJSStackFrame * * 0x04e2f9d4) line 140 + 23 bytes
XPCJSStackFrame::CreateStack(JSContext * 0x04c5cc28, JSStackFrame * 0x000f77c0, 
XPCJSStackFrame * * 0x04e2f97c) line 140 + 23 bytes

Comment 4

[Matthias Versen [:Matti]]

Attachment: really long stack trace (135k)

Comment 5

[Matthias Versen [:Matti]]

CC: [e-mail]
Phil can you help me ?
Do you know where this should go ?
(XPCJSStackFrame is inside the JS directory.Should this go to XPconnect ?)
LXR seems to be down for me....

Comment 6

[Phil Schwartau]

This is one I've never seen before. Stack overflow - 
Bottom half of stack is all DocShell functionality. Then we hit:

ThrowBadResult(unsigned int 2147500037, XPCCallContext & {...}) 
                                                      
and end up with massive numbers of 

XPCJSStackFrame::CreateStack(JSContext * 0x036bf500, JSStackFrame * 0x0003a24c,                                                                                                                                                  
                             XPCJSStackFrame * * 0x05ca691c) 


Discussed this with jband. Looks like this may be due to nesting 
in the DocShell functions in the lower part of the stack trace. 
If we look closely at this part of the trace, we can see a periodic 
pattern. If this nesting is deep enough, then XPConnect (the upper half 
of the stack trace) will be forced to create a large stack of its own ....


Reassigning this one to Embedding:Docshell for further analysis - 

cc'ing jband  - 

Comment 7

[Olivier Cahagne]

Using Mozilla 2001072618 on Win2k crashes with Talkback ID: TB33397685E

Comment 8

[basic]

Attachment: really really simplified testcase

Comment 9

[basic]

Attachment: another testcase to show what is going on

Comment 10

[basic]

err don't use attachment 43778 [details] unless you want to kill your browser manually

Comment 11

[Matthias Versen [:Matti]]

attachment 43777 [details] works and I get the same stack trace.
43778 doesn't work.....

Comment 12

[Matthias Versen [:Matti]]

-> reassigning to component owner

Comment 13

[Markus Hübner]

Adding keyword "regression" since this worked fine in mozilla 0.9.1
(using build 2001060703)

Comment 14

[Adam Lock]

This looks like it may be a strange onload/js interaction problem which is
triggering an infinite loop. The JS code is a bit tricky but I will explain what
is happening.

The page's BODY tag has an onload handler that calls MM_executeFlashDispatcher
in http://www.wohnen-in-tirol.com/Dispatcher.js to sniff out what Macromedia
Shockwave plugin (if any is installed) and set the document location
accordingly. In the case of this crash, the Shockwave 5.0 plugin is detected so
the code sets the location to the first arg passed into MM_executeFlashDispatcher.

This happens to be "javascript:void(null);". This does nothing at all except
drive docshell through an entire LoadURI/EndPageLoad cycle which finally
generates another onload event. Since the document hasn't changed, the onload
goes back to the BODY handler, causing the whole cycle to repeat infinitely,
eventually causing the stack overflow and crash.

I don't know the best course of action but imagine that not firing another
onload event when the page hasn't changed would be a good place to start.

I'll see if I can come up with a clean test case.

CC'ing Rick.

Comment 15

[Adam Lock]

I'm going blind - the previous test case demonstrates the problem, no need for a
new one.

The problem in simple terms - Any onload handler that changes the location to
some JS that does nothing (i.e. javascript:void(null);) will cause an infinite loop.

Comment 16

[Markus Hübner]

updating summary description.

Comment 17

[rpotts (gone)]

It looks like this regression is due to my changes to nsJSProtocolHandler.cpp
for bug #65777 (trunk only).

The problem is that if no content is created as part of the javascript URL, the
failure state is not propagated down to the underlying channel.  This means that
the docshell will fire an OnLoad event because the channel has a NS_OK status...

I'm attaching a patch that fixes this problem...

-- rick

Comment 18

[rpotts (gone)]

Attachment: patch to propagate failure code to underlying channel...

Comment 19

[rpotts (gone)]

hey vidur and jst,

can I get an r/sr on the patch to nsJSProtocolHandler.cpp?

It is important that the underlying channel is notified of the open failure
because when nsIChannel::GetStatus(...) is called (later) it just delegates down
to the underlying channel :-)  So, without the patch, GetStatus(...) will return
NS_OK even if the AsyncOpen() failed (due to no content being generated by the
script)

thanks,
-- rick

Comment 20

[Adam Lock]

r=adamlock

Comment 21

[Johnny Stenback (:jst)]

sr=jst

Comment 22

[rpotts (gone)]

patch checked in.

Comment 23

[Waheed Islam]

regression.

this bug is visible again using yesterdays build, 20030213-08.

going to the following site and trying to get the plugin cases the browser to
crash without talkback appearing.

http://www.mitsubishi-telecom.com/products_detail.asp?id=58999

... click on 3d demo, then on the white space (under phone image) to get plugin.

Comment 24

[Markus Hübner]

Using trunk build 2003020308 on winxp pro sp1 I also do crash as described in
comment #23

Comment 25

[Holger Lehmann]

You can reproduce this bug very well when doing this:
<html>
<head><title></title>

<script language="javascript">
  function goToAnchor(){
    anchor = "#anch_27";
    document.location.href=anchor;
  }
</script>
</head>
<body onLoad="goToAnchor()">

...
    <a name="anch_27">Here</a>
</body>
</html>

The use case is that the number, here 27, is generated by jsp,asp,pl,php or
whatever server side script you tend to use. This way some kind of navigation
can be done in a long page by simple giving the page a parameter or equivalent.

BTW: The Mozilla Release 1.2.1 seems not to be affected by this bug.

Comment 26

[Adam Lock]

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

Comment 27

[Adam Lock]

Attachment: Simple test case

A test case along the lines suggested by the last comment. This works for me,
so I don't know if this particular problem is fixed, but certainly other issues
remain.

Comment 28

[Adam Lock]

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

Comment 29

[Kevin Berkheiser]

Don't get the crash from comment 23 and don't crash from the simple testcase.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316

Comment 30

[Anders Pedersen]

(In reply to comment #0)
> Just go to
> http://www.wohnen-in-tirol.com
> and see mozilla die.
> Altough I am using a talkback version its completely killed and no talkback 
> report is being created.
> 
> The site uses the .NET technology (.aspx pages)
> 
> Using build 2001072503

Cannot reproduce, site fails to load.

Alert window:

The operation timed out when attempting to contact www.wohnen-in-tirol.com.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040330
Microsoft Windows 2000 Pro 5.00.2195 SP4

Comment 31

[Anders Pedersen]

(In reply to comment #23)
> regression.
> 
> this bug is visible again using yesterdays build, 20030213-08.
> 
> going to the following site and trying to get the plugin cases the browser to
> crash without talkback appearing.
> 
> http://www.mitsubishi-telecom.com/products_detail.asp?id=58999
> 
> ... click on 3d demo, then on the white space (under phone image) to get plugin.

Getting the plugin without problems here. Goes to the homepage of the plugin
producer and a window with progress bar appears and the plugin gets installed.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040330
Microsoft Windows 2000 Pro 5.00.2195 SP4

Comment 32

[Asa Dotzler [:asa]]

Unable to reproduce with Mozilla 1.7 beta on windows XP