37463 - Javascript: URLs freeze app

Status: VERIFIED FIXED

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

Description

[timeless]

Clicking on a Javascript link brings up a dialog; entering a number and then 
pressing ok hangs mozilla

Comment 1

[R.K.Aa.]

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?

Comment 2

[timeless]

Attachment: The relevant snipet from bugzilla, click the hypertext [requires mozilla]

Comment 3

[timeless]

Click the link (Mozilla bug); enter a number; click ok.
Mozilla is now hung.

Comment 4

[timeless]

Sorry, i'm just learning to [hate] and use bugzilla, it was build 2000042708.

Comment 5

[R.K.Aa.]

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)

Comment 6

[R.K.Aa.]

Probably complately unrelated but bug 36818 on BEOS is marked fixed on
2000-04-26 and was about PR_WaitCondVar

Comment 7

[R.K.Aa.]

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)

Comment 8

[Asa Dotzler [:asa]]

reassign

Comment 9

[rogerl (gone)]

assert failing in nsWebShell::onEndDocumentLoad, line 1206. The call to 
aURL->GetHost(...)

Comment 10

[Andreas Franke (gone)]

Attachment: stack trace of thread 2, PC/Linux, build 2000042809

Comment 11

[Andreas Franke (gone)]

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";

Comment 12

[Andreas Franke (gone)]

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

Comment 13

[Andreas Franke (gone)]

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

Comment 14

[Andreas Franke (gone)]

Changing summary to make this bug easier to find. Adding nsbeta2 keyword 
(see summary of bug 38742, submitted by [e-mail]).

Comment 15

[Andreas Franke (gone)]

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

Comment 16

[Andreas Franke (gone)]

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, [e-mail] (DOM Level 0) as the current owner of bug 38537,
[e-mail] (Javascript Engine) because he added a possibly important
comment, and myself.

Note that this is a highly visible crash.

Comment 17

[Mark Whitley]

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. :-(

Comment 18

[Andreas Franke (gone)]

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.

Comment 19

[leger]

Putting on [nsbeta2-] radar. Not critical to beta2.

warren, assigning to you per PDT mtg.  Can you work on this?  right person?

Comment 20

[bht237]

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?

Comment 21

[leger]

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

warren, do you have an words of wisdom here :-)

Comment 22

[Warren Harris]

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.

Comment 23

[Scott MacGregor]

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.

Comment 24

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 25

[Andreas Franke (gone)]

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

Comment 26

[Andreas Franke (gone)]

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

Comment 27

[Andreas Franke (gone)]

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

Comment 28

[Andreas Franke (gone)]

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

Comment 29

[Scott MacGregor]

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

Comment 30

[Scott MacGregor]

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.

Comment 31

[R.K.Aa.]

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

Comment 32

[Andreas Franke (gone)]

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

Comment 33

[R.K.Aa.]

bug 40607 hangs on javascript:location.href="/"
A dup of this?

Comment 34

[Andreas Franke (gone)]

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

Comment 35

[Andreas Franke (gone)]

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

Comment 36

[Andreas Franke (gone)]

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

Comment 37

[Gervase Markham [:gerv]]

*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

Comment 38

[sean echevarria]

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

Comment 39

[Scott MacGregor]

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

Comment 40

[Andreas Franke (gone)]

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

Comment 41

[Doron Rosenberg (IBM)]

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

Comment 42

[Andreas Franke (gone)]

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

Comment 43

[vidur (gone)]

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

Comment 44

[Andreas Franke (gone)]

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

Comment 45

[Tobias Burnus]

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

Comment 46

[Andreas Franke (gone)]

Adding crash kw.

Comment 47

[Johnny Stenback (:jst)]

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

Comment 48

[Johnny Stenback (:jst)]

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...

Comment 49

[Warren Harris]

Submit the diffs.

Comment 50

[Johnny Stenback (:jst)]

Attachment: Hack that solves the deadlock

Comment 51

[Johnny Stenback (:jst)]

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.

Comment 52

[Marcello Nuccio]

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

Comment 53

[Gregory McLean]

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.

Comment 54

[Andreas Franke (gone)]

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

Comment 55

[bht237]

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.

Comment 56

[Gregory McLean]

Yes in the build I have (2000061812 + this patch) it also 'fixes' 37702 . IE. No
deadlock on loading the testcase attached to that bug.

Comment 57

[Andreas Franke (gone)]

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

Comment 58

[Andreas Franke (gone)]

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

Comment 59

[Warren Harris]

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.

Comment 60

[Scott MacGregor]

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!

Comment 61

[Mitchell Stoltz (not reading bugmail)]

Has the patch been checked in yet?

Comment 62

[Scott MacGregor]

no not yet...i'll mark it fixed when i do.....

Comment 63

[Martin Horwath]

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

Comment 64

[Andreas Franke (gone)]

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

Comment 65

[Stephen Walker]

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

Comment 66

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 67

[leger]

mscott is http://bugzilla.mozilla.org/show_bug.cgi?id=43338
a dup of this?

Comment 68

[Scott MacGregor]

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

Comment 69

[Andreas Franke (gone)]

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

Comment 70

[Blake Ross]

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

Comment 71

[Johnny Stenback (:jst)]

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

Comment 72

[[e-mail]]

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.

Comment 73

[Andreas Franke (gone)]

sehh: yes, this is the same problem. See also bug 21373 which is specifically
about javascript:history.back() not working.

Comment 74

[Warren Harris]

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().

Comment 75

[Martin Horwath]

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

Comment 76

[Blake Ross]

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

Comment 77

[Blake Ross]

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.

Comment 78

[Warren Harris]

I'll take this.

Comment 79

[Scott MacGregor]

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. 

Comment 80

[Blake Ross]

we still need QA for this. taking over unless someone else wants it.

Comment 81

[Warren Harris]

Attachment: my fix -- also eliminates file transport lock (for performance)

Comment 82

[Blake Ross]

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

Comment 83

[Johnny Stenback (:jst)]

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.

Comment 84

[Warren Harris]

It's got a bug I'm still looking at.

Comment 85

[Scott MacGregor]

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

Comment 86

[Warren Harris]

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... 

Comment 87

[Daniel Bratell]

The checkin seems to have increased leaks too. They went from 1 to 6 KB on 
Tinderbox.

Comment 88

[Dave]

Is the patch in the nightlies? Cuz my bug (40172) is still present in
2000062920/Linux

Comment 89

[Andreas Franke (gone)]

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.

Comment 90

[Andreas Franke (gone)]

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

Comment 91

[leger]

Adding verifyme keyword.

Comment 92

[leger]

Just verified with the www.ea.com test case on the dup.  Works fine with Win32 
2000-07-18-11 build.  Marking Verified.

Comment 93

[timeless]

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

Comment 94

[timeless]

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.

Comment 95

[John Morrison]

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.

Comment 96

[John Morrison]

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.

Comment 97

[R.K.Aa.]

it's back - see bug 57585 reported with 2000102108 Windows.