Closed
Bug 42773
Opened 25 years ago
Closed 25 years ago
Loading some javascript: URLs causes freeze
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
People
(Reporter: security-bugs, Assigned: jst)
References
()
Details
(Keywords: crash)
Attachments
(1 file)
|
110 bytes,
text/html
|
Details |
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).
|
Assignee | |
Comment 2•25 years ago
|
||
|
|
Assignee | |
Comment 3•25 years ago
|
||
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?
|
|
Assignee | |
Updated•25 years ago
|
|
||
Comment 4•25 years ago
|
||
Maybe you can give up the monitor around the nsIStreamIO calls (like Open), and
then check the status again after re-entering.
|
||
Comment 5•25 years ago
|
||
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.
|
|
||
Comment 6•25 years ago
|
||
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.
|
||
Comment 7•25 years ago
|
||
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...
|
|
||
Comment 8•25 years ago
|
||
The crash on http://www.tek-tips.com is a dup of bug 42439.
|
|
Assignee | |
Comment 9•25 years ago
|
||
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: 25 years ago
Resolution: --- → DUPLICATE
|
|
||
Comment 10•25 years ago
|
||
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).
You need to log in
before you can comment on or make changes to this bug.
Description
•