Closed Bug 42773 Opened 24 years ago Closed 24 years ago

Loading some javascript: URLs causes freeze

Categories

(Core :: DOM: Core & HTML, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 37463

People

(Reporter: security-bugs, Assigned: jst)

References

()

Details

(Keywords: crash)

Attachments

(1 file)

To Reproduce:
Go to above URL, click "Client Services Login".
Result:
Mozilla freezes and must be interrupted.

Another Testcase:
Go to www.bmwusa.com, click on the link in the lower left, then click on one of
the model numbers right in the center of the page. Same result. 

There were security bugs relating to JS URLs, these have been fixed. THe
security code is working correctly. In both these cases, I traced execution as
far as nsJSProtocolHandler::EvaluateString, where the script actually gets
evaluated, and all is fine. The freeze happens somewhere in JS execution. I
could not reproduce this problem in a simplified test of js URLs (see
http://warp/u/mstoltz/bugs/jsurl.html, this works fine).
Blocks: 34810
*** Bug 42811 has been marked as a duplicate of this bug. ***
Attached file Simplified testcase
The simplified testcase I just attached contains this:

<html>
<body>
<a href="javascript:window.location='http://www.mozilla.org';">
Click on me</a>
</body>
</html>

and that's enough to lock up mozilla if the link is clicked.

Here's what happens...

The link is clicked and we eventually end up in the docshell loading
the uri that the link points to, javascript:win... in this case. The
docshell tells necko to load the uri, necko creates a file transport
for the loading of the uri and necko goes off to some other thread to
process this request. On this other thread the file transport is
opened and necko calls AsyncRead on the transport, AsyncRead
dispatches requests and what not, and we end up on yet one more thread
(I think) in nsFileTransport::Process(), first time we get there we
end up calling Open on mStreamIO (which is the nsJSThunk that deals
with executing the script in the uri). Now, nsFileTransport::Process()
is protected by a monitor so when we end up in nsJSThunk::Open() the
file transport is locked. In nsJSThunk::Open() we execute the
javascript through a proxy that makes the script execution happen
syncronously on the main thread (i.e. the necko thread waits for the
execution to finish). So on the main thread we execute the script
"window.location='http://www.mozilla.org';", this takes us into the
docshell again to load www.mozilla.org and *this* is the problem. When
we start loading a new uri we first cancel ongoing loads, and since
we're currently loading the script url, we cancel that, this calls
nsFileTransport::Cancel() on tha main thread (ie different thread than
nsFileTransport::Process() was called on) and since
nsFileTransport::Cancel() is also protected by the same monitor we
dead lock!

This is bad, anyone got any ideas on where and how to solve this?
Keywords: crash, nsbeta2
Maybe you can give up the monitor around the nsIStreamIO calls (like Open), and 
then check the status again after re-entering.
When using builds later than 2000060908, attempt to load http://www.tek-tips.com
causes the Mozilla processes to die (SuSE Linux 6.2 with 2.2.16 kernel, X
Windows version 3.3.4).  There is a javascript section near the beginning of the
page.  This page loads normally with build 2000060908 and earlier.
This bug is resolved (with respect to build 2000061611) as far as the Tek-Tips
page is concerned.  The 2000061520 build trashed both Netscape 4.7 and Mozilla
on my box, but recovery was relatively easy once I figured it out.
This is a dup of mostfreq bug 37463. Ok, maybe the crash was missing there.
Warren, Johnny, do we really need a second bug for this problem? 
Well, if it helps in getting this fixed...
The crash on http://www.tek-tips.com is a dup of bug 42439.
Yes, Andreas, this is a dup of bug 37463, exactly the same problem as far as I
can tell, Thanks!

Duping...

*** This bug has been marked as a duplicate of 37463 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Bug 37463 is fixed. Clicking "Client Services Login" on
http://www.equitable.co.uk doesn't freeze any more.
The www.bmwusa.com testcase works for me, too.
(PC/Linux, build 2000063020).
Verified Duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.