Closed Bug 37463 Opened 24 years ago Closed 24 years ago

Javascript: URLs freeze app

Categories

(Core :: DOM: Navigation, defect, P1)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: timeless, Assigned: warrensomebody)

References

(
URL
)

Details

(Keywords: crash, embed, Whiteboard: [nsbeta2+])

Attachments

(4 files)

The relevant snipet from bugzilla, click the hypertext [requires mozilla]
1008 bytes, text/html
Details
stack trace of thread 2, PC/Linux, build 2000042809
3.07 KB, text/plain
Details
Hack that solves the deadlock
2.51 KB, patch
Details | Diff | Splinter Review
my fix -- also eliminates file transport lock (for performance)
26.86 KB, patch
Details | Diff | Splinter Review 
Clicking on a Javascript link brings up a dialog; entering a number and then 
pressing ok hangs mozilla
Not sure I understand the problem so it's hard to reproduce.
A little more information would be most helpful:

-Which build ID are you testing? (See lower right corner of Moz)
-Is the URL above the full URL to the page where the error happens?
-Can you give an example of what the text reads on one of the links that trigger
this?

Click the link (Mozilla bug); enter a number; click ok.
Mozilla is now hung.
Sorry, i'm just learning to [hate] and use bugzilla, it was build 2000042708.
Reporter: A workaround is using the visible form on that page to fill bug# in,
then click "show" button.

The link clicked is in 4th line at http://bigzilla.mozilla.org
Line reads "Show Mozilla bug no." (Hypertext "Mozilla bug")
This can be reproduced on linux 2000-042709 as well. The popup and Moz freezes
after OK is clicked.

Adding freeze to subject. Javascript Engine component?

(gdb) where
#0  0x4031cdeb in __sigsuspend (set=0xbf1ff94c) at
../sysdeps/unix/sysv/linux/sigsuspend.c:48
#1  0x4018bc22 in __pthread_wait_for_restart_signal (self=0xbf1ffe40) at
pthread.c:785
#2  0x40188960 in pthread_cond_wait (cond=0x862dd5c, mutex=0x862dd74) at
restart.h:26
#3  0x4016e4ae in PR_WaitCondVar ()
#4  0x4016e78f in PR_Wait ()
#5  0x4010ab89 in PL_WaitForEvent ()
#6  0x4010b87e in nsEventQueueImpl::WaitForEvent ()
#7  0x4010e266 in nsProxyObject::PostAndWait ()
#8  0x4010e576 in nsProxyObject::Post ()
#9  0x4010fac0 in nsProxyEventObject::CallMethod ()
#10 0x4011b2da in XPTC_InvokeByIndex ()
#11 0x4011b36e in nsXPTCStubBase::Stub4 ()
#12 0x40fd86a3 in NSGetModule ()
#13 0x40869492 in NSGetModule ()
#14 0x408693b6 in NSGetModule ()
#15 0x4010da32 in nsThreadPoolRunnable::Run ()
#16 0x4010caa0 in nsThread::Main ()
#17 0x4017279e in PR_Select ()
#18 0x40189b25 in pthread_start_thread (arg=0xbf1ffe40) at manager.c:241
(gdb)
Status: UNCONFIRMED → NEW
Component: Browser-General → Javascript Engine
Ever confirmed: true
Summary: Fancy javascript on bugzilla query form messes up. → Fancy javascript on bugzilla query form messes up. [freeze]
Probably complately unrelated but bug 36818 on BEOS is marked fixed on
2000-04-26 and was about PR_WaitCondVar

Checkins regarding 36818 are unreleated. 2000-042416 M16 freezes as well, but
different backtrace:
#0  0x40310deb in __sigsuspend (set=0xbf3ffc10) at
../sysdeps/unix/sysv/linux/sigsuspend.c:48
#1  0x4018bc22 in __pthread_wait_for_restart_signal (self=0xbf3ffe40) at
pthread.c:785
#2  0x40188960 in pthread_cond_wait (cond=0x80cc21c, mutex=0x80e92b4) at
restart.h:26
#3  0x4016e4ae in PR_WaitCondVar ()
#4  0x4016e78f in PR_Wait ()
#5  0x4010cfe0 in nsThreadPool::GetRequest ()
#6  0x4010d601 in nsThreadPoolRunnable::Run ()
#7  0x4010c680 in nsThread::Main ()
#8  0x4017279e in PR_Select ()
#9  0x40189b25 in pthread_start_thread (arg=0xbf3ffe40) at manager.c:241
--
(Tested an old build from 2000-0327 also: it didn't have this bug)
reassign
Assignee: asadotzler → rogerl
QA Contact: jelwell → pschwartau
assert failing in nsWebShell::onEndDocumentLoad, line 1206. The call to 
aURL->GetHost(...)
Assignee: rogerl → travis
Component: Javascript Engine → Embedding: Docshell
QA Contact: pschwartau → travis
I think this freeze can be characterized by the above stack trace of thread 2:
#0  __sigsuspend
#1  __pthread_lock
#2  __pthread_mutex_lock
#3  PR_Lock ()                      from libnspr4.so
#4  PR_EnterMonitor ()              from libnspr4.so
#5  nsFileTransport::Cancel ()      from components/libnecko.so
#6  nsStreamIOChannel::Cancel ()    from components/libnecko.so
#7  nsLoadGroup::Cancel ()          from components/libnecko.so
#8  nsDocLoaderImpl::Stop ()        from components/liburiloader.so
#9  nsURILoader::Stop ()            from components/liburiloader.so
#10 nsDocShell::StopLoad ()         from libdocshell.so
#11 nsDocShell::StopCurrentLoads () from libdocshell.so

Bug 38537 has an alternative way to reproduce this - 
just enter the following URL into the location field:
	javascript:window.location="http://www.mozilla.org";
*** Bug 38533 has been marked as a duplicate of this bug. ***
*** Bug 38742 has been marked as a duplicate of this bug. ***
Changing summary to make this bug easier to find. Adding nsbeta2 keyword 
(see summary of bug 38742, submitted by scalkins@netscape.com).
Keywords: nsbeta2
Summary: Fancy javascript on bugzilla query form messes up. [freeze] → lockup/freeze upon javascript:window.location="http://www.mozilla.org";
*** Bug 39176 has been marked as a duplicate of this bug. ***
Changing Platform/OS to All (original report is Win2000, I'm on linux, and 
bug 38537 was reported on Mac).

Adding some people to the CC list: reporters of bug 38742, bug 38533, bug 38537,
bug 39176, jst@netscape.com (DOM Level 0) as the current owner of bug 38537,
rogerl@netscape.com (Javascript Engine) because he added a possibly important
comment, and myself.

Note that this is a highly visible crash.
OS: Windows 2000 → All
Hardware: PC → All
Another test case to look at:



http://dansteinman.com/dynduo/en/checkbox.html



Scroll down to the bottom of the page and you will see a line that reads:



"Example: checkbox1.html [source] - for a checkbox example."



"checkbox1.html" and "[source]" are both hyperlinked.  Float the mouse over the

top of "checkbox1.html" and the status bar shows that this links to:



javascript:viewExample('checkbox1.html',1)



(FYI: The 'viewExample' function is not implemented on this page. If you view

the source to this page, at the top the guy imports about 4 other .js files. One

of those probably contains the implementation. I did not try to track down the

exact file.)



Click on the "checkbox1.html" link. Mozilla locks up hard. Doesn't repaint,

doesn't respond to mouse/kbd events, etc. The last thing Moz does before it dies

is print a line in the shell window that reads:



Error loading URL http://dansteinman.com/dynduo/en/checkbox.html



I am using a nightly build: 2000051508, PC, Linux.



I tried doing this in Netscape 4.72 and it works correctly; executes the

JavaScript and loads the page in the same browser window. This page also

displays correctly under M15, so this is a regression bug. :-(


CC warren (see below).

I have tried entering javascript:window.location="http://www.mozilla.org/";
into the location field (urlbar) with several older PC/Linux builds. Results:
M14 works fine.
2000032909 (which is the fist nightly after M14 that I tried): 
  lockup/freeze. Relevant stack traces seem to be in thread 2 and thread 4.
2000041008 same lockup/freeze, same stack traces. The only difference is in
  thread 2: #13 changed from nsWebShell::LoadURL to nsWebShell::InternalLoad
2000041412-M15: same lockup/freeze, same stack traces as 041008.
2000041505-M15: works fine :)
2000041811-M15: works fine :) (this is the final milestone) 

A bonsai query leads to warrens fix of bug 34217 that has been checked into 
the SeaMonkey_M15_BRANCH on 04/15 01:28, which as a side-effect seems to have
fixed the problems mentioned in this bug (or at least some of them) in M15:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=SeaMonkey_M15_BRANCH&branchtype=match&dir=&file=&filetype=match&who=warren%25netscape.com&whotype=match&sortby=Date&hours=2&date=explicit&mindate=04%2F14%2F2000+11%3A00%3A00&maxdate=04%2F15%2F2000+06%3A00%3A00&cvsroot=%2Fcvsroot

Unfortunately, the same patch could not be applied to the trunk.
A different fix to bug 34217 has been checked into the trunk by warren
on 4/20:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=warren%25netscape.com&whotype=match&sortby=Date&hours=2&date=explicit&mindate=04%2F20%2F2000+22%3A16%3A00&maxdate=04%2F20%2F2000+22%3A19%3A00&cvsroot=%2Fcvsroot

but that did not have the same nice side-effect:

2000041816 shows basically the same lockup/freeze and the same stack traces 
  as 2000041008 (modulo some nsWebShell --> nsDocShell changes), and
2000042113 still has the same problem. Now there are 5 threads instead of four,
  but the stack trace of thread 2 has not changed.

I haven't tried this with later builds yet, but I think it would be interesting
to understand why the first fix solved this problem for M15.
Putting on [nsbeta2-] radar. Not critical to beta2.

warren, assigning to you per PDT mtg.  Can you work on this?  right person?
Assignee: travis → warren
QA Contact: travis → warren
Whiteboard: [nsbeta2-]
This bug affects quite a few JavaScript based systems. 
Not critical? IMHO Mozilla needs to perform on these systems asap because only 
more complex and dynamic sites will expose those bugs that we aren't aware of 
yet.
Is 37702 related?

Removing [nsbeta2-] for re-eval to pr2 blocker per bht comments.

warren, do you have an words of wisdom here :-)
Whiteboard: [nsbeta2-]
The file transport is sitting blocked, trying to evaluate the script and waiting 
for the result. 

(I don't know if this part is relevant or not but...) The mozilla thread hits an 
assertion in the doc loader because the js url doesn't have a host field:

###!!! Break: at file d:\seamonkey-tip\mozilla\webshell\src\nsWebShell.cpp, line
 1194

The mozilla thread then tries to cancel the file transport and deadlocks:

NTDLL! 77f6829b()
NTDLL! 77f67546()
PR_EnterMonitor(PRMonitor * 0x03563060) line 79 + 14 bytes
nsAutoMonitor::nsAutoMonitor(PRMonitor * 0x03563060) line 184 + 13 bytes
nsFileTransport::Cancel(nsFileTransport * const 0x03564170, unsigned int 
0x804b0002) line 191
nsStreamIOChannel::Cancel(nsStreamIOChannel * const 0x036c35b0, unsigned int 
0x804b0002) line 206 + 30 bytes
nsLoadGroup::Cancel(nsLoadGroup * const 0x02da8120, unsigned int 0x804b0002) 
line 225 + 16 bytes
nsDocLoaderImpl::Stop(nsDocLoaderImpl * const 0x02da8180) line 246 + 31 bytes
nsURILoader::Stop(nsURILoader * const 0x00d46240, nsISupports * 0x02da8198) line 
560 + 23 bytes
nsDocShell::StopLoad(nsDocShell * const 0x02da8b70) line 236
nsDocShell::StopCurrentLoads(nsDocShell * const 0x02da8b70) line 2611
nsDocShell::InternalLoad(nsDocShell * const 0x02da8b70, nsIURI * 0x036cab30, 
nsIURI * 0x036c3630, const char * 0x00000000, nsIInputStream * 0x00000000, 
nsDocShell::loadType loadNormalReplace) line 2283 + 15 bytes
nsDocShell::LoadURI(nsDocShell * const 0x02da8b70, nsIURI * 0x036cab30, 
nsIDocShellLoadInfo * 0x036caaf0) line 213 + 42 bytes
LocationImpl::SetHrefWithBase(const nsString & {"http://www.mozilla.org"}, 
nsIURI * 0x02e7c970, int 0x00000001) line 384 + 36 bytes
LocationImpl::SetProperty(JSContext * 0x02d97da0, JSObject * 0x024805d0, long 
0x0257140c, long * 0x0012f808) line 803 + 30 bytes
GlobalWindowImpl::SetProperty(JSContext * 0x02d97da0, JSObject * 0x024805d0, 
long 0x00eb6a24, long * 0x0012f808) line 2025 + 55 bytes
nsJSUtils::nsCallJSScriptObjectSetProperty(nsISupports * 0x02d972f4, JSContext * 
0x02d97da0, JSObject * 0x024805d0, long 0x00eb6a24, long * 0x0012f808) line 242 
+ 27 bytes
SetWindowProperty(JSContext * 0x02d97da0, JSObject * 0x024805d0, long 
0x00eb6a24, long * 0x0012f808) line 815 + 25 bytes
js_SetProperty(JSContext * 0x02d97da0, JSObject * 0x024805d0, long 0x02669d90, 
long * 0x0012f808) line 2165 + 195 bytes
js_Interpret(JSContext * 0x02d97da0, long * 0x0012fa0c) line 2354 + 1424 bytes
js_Execute(JSContext * 0x02d97da0, JSObject * 0x024805d0, JSScript * 0x036cadd0, 
JSFunction * 0x00000000, JSStackFrame * 0x00000000, unsigned int 0x00000000, 
long * 0x0012fa0c) line 857 + 13 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x02d97da0, JSObject * 0x024805d0, 
JSPrincipals * 0x036cb1e0, const unsigned short * 0x0012faf4, unsigned int 
0x00000029, const char * 0x00000000, unsigned int 0x00000000, long * 0x0012fa0c) 
line 2736 + 27 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x02d97290, const nsString & 
{"window.location="http://www.mozilla.org";"}, void * 0x024805d0, nsIPrincipal * 
0x036cb1dc, const char * 0x00000000, unsigned int 0x00000000, const char * 
0x00000000, nsString & {""}, int * 0x0230fcd0) line 464 + 55 bytes
nsEvaluateStringProxy::EvaluateString(nsEvaluateStringProxy * const 0x03565c40, 
char * * 0x0230fccc, int * 0x0230fcd0) line 167 + 64 bytes
XPTC_InvokeByIndex(nsISupports * 0x03565c40, unsigned int 0x00000004, unsigned 
int 0x00000002, nsXPTCVariant * 0x035c6740) line 139
EventHandler(PLEvent * 0x035c6bd0) line 489 + 41 bytes
PL_HandleEvent(PLEvent * 0x035c6bd0) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01079850) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00b90898, unsigned int 0x0000c0fb, unsigned int 
0x00000000, long 0x01079850) line 1030 + 9 bytes
USER32! 77e71820()
010

Sending this to mscott to see about fixing the assertion first. Maybe that will 
avoid the cancel request, and avoid the deadlock.
Assignee: warren → mscott
Warren, I fixed the assertion in webshell and made sure we returned NS_OK if we
don't have a host name in the url. Unfortunately the dead lock still exists with
the file transport waiting for the script to run and the UI thread canceling the
file transport in response to the JS being executed.

Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
*** Bug 39832 has been marked as a duplicate of this bug. ***
*** Bug 39879 has been marked as a duplicate of this bug. ***
*** Bug 39437 has been marked as a duplicate of this bug. ***
*** Bug 40172 has been marked as a duplicate of this bug. ***
*** Bug 40236 has been marked as a duplicate of this bug. ***
Hmmm, Warren, I'm wondering if your changes for when JS urls get executed
exposed this problem because we didn't have it in PR1.  I can't think of what to
do here. The file transport is blocked waiting for a OnDataAvailable (or on
start?) event it posted on the UI thread to return. However, when the script is
executed on the UI thread, it tries to cancel the file transport because it's
going to load a new document into the docshell. The cancel call attempts to get
a monitor from the file transport and deadlocks.
Status: NEW → ASSIGNED
Blocks: 20283
Target Milestone: --- → M16
Priority: P3 → P1
*** Bug 40684 has been marked as a duplicate of this bug. ***
*** Bug 40719 has been marked as a duplicate of this bug. ***
bug 40607 hangs on javascript:location.href="/"
A dup of this?

*** Bug 40607 has been marked as a duplicate of this bug. ***
*** Bug 40969 has been marked as a duplicate of this bug. ***
*** Bug 40969 has been marked as a duplicate of this bug. ***
*SPAM* - adding mostfreq keyword to bugs with loads of DUPEs. Please aid this 
effort by adding this keyword to any bugs with more than 15 DUPEs.

Gerv
Keywords: mostfreq
*** Bug 38350 has been marked as a duplicate of this bug. ***
*** Bug 39558 has been marked as a duplicate of this bug. ***
*** Bug 40830 has been marked as a duplicate of this bug. ***
*** Bug 38752 has been marked as a duplicate of this bug. ***
*** Bug 42461 has been marked as a duplicate of this bug. ***
*** Bug 22393 has been marked as a duplicate of this bug. ***
*** Bug 42672 has been marked as a duplicate of this bug. ***
Another JS URL http://www.berlikomm.net/ (I'm not 100% sure whether this is
exactly the same, since it uses `parent.frames[i].location.href=URL', but the
result is the same -- freeze.)
I think you should change M16 to M17
Adding crash kw.
Keywords: crash
*** Bug 42773 has been marked as a duplicate of this bug. ***
I played around a bit with warrens suggestion in bug 42773 (a dup of this) and
that does solve the deadlock, but I have no idea on how it would impact on the
threadsafety of the necko code...
Submit the diffs.
The hack I just submitted removes the lock that scopes all the code in
nsFileTransport::Process() and adds locks around just about all the code in that
method except the call to Open() on mStreamIO. This solves the deadlock.
I'm using M16 (Build ID: 2000061311) on Linux (RedHat 6.2 and Debian 2.2).
Mozilla hangs if I:
1) go to "http://www.hp.com/cposupport/cspt/lj2100_spt/experts/"
2) click on the "Accept" button

I can confirm that with hack by Johnny applied the hanging is fixed. The few
javascript driven sites are much more useful with this applied. There is some
collisions going on in the various threads but I don't see how that can be
avoided.
*** Bug 42967 has been marked as a duplicate of this bug. ***
Does this fix bug 37702 as well?

I have a site that makes extreme use of JavaScript for setting frame
URLs, but it will not work with bug 37702.
This site uses frame history implemented in JavaScript because
of cross-browser problems.
If there are any threading problems left, then I would probably
spot them because locations are sometimes set by multiple events
per frameset.
Please notify me if the patch is implemented in a nightly build
and wheter 37702 is fixed.
I will test it asap and post my results here.
Yes in the build I have (2000061812 + this patch) it also 'fixes' 37702 . IE. No
deadlock on loading the testcase attached to that bug.

*** Bug 42965 has been marked as a duplicate of this bug. ***
*** Bug 43044 has been marked as a duplicate of this bug. ***
That last diff looks ok, although longer term, I'd like to find a way to 
eliminate most of those locks altogether. I say check it in.
The changes look good to me too and they do fix the problem. I can take care of
checking in this patch....many thanks for the patch jst!
Has the patch been checked in yet?
no not yet...i'll mark it fixed when i do.....
*** Bug 43243 has been marked as a duplicate of this bug. ***
*** Bug 43245 has been marked as a duplicate of this bug. ***
*** Bug 43295 has been marked as a duplicate of this bug. ***
M16 has been out for a while now, these bugs target milestones need to be 
updated.
mscott is http://bugzilla.mozilla.org/show_bug.cgi?id=43338
a dup of this?
*** Bug 43338 has been marked as a duplicate of this bug. ***
*** Bug 42720 has been marked as a duplicate of this bug. ***
Blocks: 35244
*** Bug 43650 has been marked as a duplicate of this bug. ***
*** Bug 43606 has been marked as a duplicate of this bug. ***
I don't know if its relevant but some javascript commands don't work,
for example a Previous Page link.

You can test this from my website:
http://www.modenos.com/index2.html

(click on any link, and click on Previous Page when the new page comes up)

That should hang the browser.
Blocks: 43317
sehh: yes, this is the same problem. See also bug 21373 which is specifically
about javascript:history.back() not working.
This diff isn't good because it doesn't check mStatus after entering the monitor 
-- the whole reason for the monitor.

I think a more minimal diff would be better: doing a mon.Exit() and mon.Enter() 
around Open, and checking mStatus after mon.Enter().
*** Bug 43907 has been marked as a duplicate of this bug. ***
Keywords: embed
*** Bug 36745 has been marked as a duplicate of this bug. ***
This applies to all Javascript: urls, right?  Updating summary to help possibly 
catch more dupes...please revert back to the old one if I'm wrong and this only 
applies to certain JS functions.
Summary: lockup/freeze upon javascript:window.location="http://www.mozilla.org"; → Javascript: URLs freeze app
I'll take this.
Assignee: mscott → warren
Status: ASSIGNED → NEW
QA Contact: warren
Thanks for the load balance help warren.

Blake to answer your question. JS URLS should work. It's only urls that involve
changing the content location (which involves tearing down the current content)
that should cause this hang. 
we still need QA for this. taking over unless someone else wants it.
QA Contact: BlakeR1234
*** Bug 44204 has been marked as a duplicate of this bug. ***
Warren, I tested your patch and it does solve the problem. Could we get that
checked in? I'd love to review but I don't know the code well enough so someone
else with more knowledge about that code should probably review.
Blocks: 43606
It's got a bug I'm still looking at.
*** Bug 43598 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Fix checked in. 

However, the location bar seems completely screwed up w.r.t. typing in 
something like: javascript:alert("hi"); It does autocompletion against 
previous javascript: urls. It wipes out one js url and replaces it with another 
after hitting return. The dialog only comes up sometimes, on and on... 
The checkin seems to have increased leaks too. They went from 1 to 6 KB on 
Tinderbox.

Is the patch in the nightlies? Cuz my bug (40172) is still present in
2000062920/Linux
Blake, if you really want to be QA for this, fine. :)
On PC/Linux, build 2000063020, I have tested everything from this bug's creation 
up to 2000-06-20 15:43, both things mentioned in this bug and the duplicate
tree. Looks good so far. Bug 37702 seems to be something different, but things
belonging to this bug are really fine.

*** Bug 43317 has been marked as a duplicate of this bug. ***
No longer blocks: 43317
Adding verifyme keyword.
Keywords: verifyme
Just verified with the www.ea.com test case on the dup.  Works fine with Win32 
2000-07-18-11 build.  Marking Verified.
Status: RESOLVED → VERIFIED
*** Bug 47671 has been marked as a duplicate of this bug. ***
Reopen per 47671. Jan, please verify all of the test cases, I'm guessing you 
didn't verify 2000-06-17 00:32 or maybe it regressed.

This is still nsbeta2+ and should be verified or fixed asap.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Sorry, but I must disagree. This bug is not a duplicate of bug 47671.  
This bug is about "javascript:someFunction('arg');" not working (in fact
hanging). Those work with both PR2 bits on win95/mac/linux, and with 08/04
trunk builds on win95.

Bug 47671 is about the JS 'window.location.href="someURL"' statement not
working.  That is a different issue (although they are both serious bugs).
[By the way, ekrock notes on bug 47671: "It's unfortunately too late to stop
nsbeta2 for something like this ... This is a *definite* nsbeta3 stopper."]

I'm re-resolving this bug as FIXED, and reopening bug 47671.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
verified fixed win32/linux/mac 20000816nn -- using a variety of javascript:
urls, in both a web page, and typing into urlbar ... no hangs, js code is
executed correctly.
Status: RESOLVED → VERIFIED
it's back - see bug 57585 reported with 2000102108 Windows.
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: