44022 - javascript:window.open(...), possibly other js urls busted

Status: VERIFIED FIXED

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

Description

[Sherry Shen]

From Bugzilla Helper:
User-Agent: Mozilla/4.51 [en] (X11; U; SunOS 5.7 sun4u)
BuildID:    

When the browser doesn't has a JVM installed and hits
a page with APPLET tag, the default plugin mechanism
leads user to get Plugin due to the fix for BUG 41197.

However, the default plugin mechanism is broken when 
the option, "Enable JavaScript for Navigator" is selected.
That is,  an error dialog is shown as when the applet 
window is clicked.  The correct behavior is to show a 
message dialog, "Plug-in Not Loaded".  

Note that the default plugin mechanism works when the
JavaScript is disabled.

Reproducible: Always
Steps to Reproduce:
1. start browser.
2. enable JavaScript from Edit-Preference-Advanced.
3. load a URL with applet tag (see attachment).
4. click around text, "click here to get the plugin".


Actual Results:  See the error dialog as
 ASSERTION: NS_ENSURE_TRUE(callbacks)failed:'callbacks', file
 C:\mozilla\dom\src\jrurl\nsJSProtocolHandler.cpp, line 108.

Expected Results:  See a message dialog, "Plug-in Not Loaded".  


Bug 41197 provided source code for the default plugin.
Bug 43500 will put default plugin in the Mozilla tree.
I used the binary npnul32.dll from [e-mail] in my test.

Comment 1

[Sherry Shen]

Attachment: A textcase with APPLET tag.

Comment 2

[av (gone)]

The correct behaviour in your testcase with JavaScript enabled should be not 
popping up Plugin Not Found dialog, but rather appearing a new Navigator window 
because in this case the default plugin is just saying Navigator to open the 
following URL: javascript:window.open("http://...");

Those kind of URL don't currently work, I am pretty sure should be dup 
somewhere.

BTW, it does not use javascript:-type URL if you have codebase attribute in the 
applet tag even with enabled JavaScript, like you can see on java.sun.com. I am 
not sure if this is a right behaviour.

Adding myself to the cc list.

Comment 3

[av (gone)]

And the full command is:

javascript:window.open("http://home.netscape.com/plugins/jvm.html?mimetype=appli
cation/x-java-vm","plugin","toolbar=no,status=no,resizeable=no,scrollbars=no,hei
ght=252,width=626");'

Comment 4

[ekrock's old account (dead)]

Vidur, Johnny -- Any idea what's going on here or which of the window.open bugs 
it's a DUP of? I reviewed the open bugs with "window.open" in Summary and it 
didn't seem an obvious DUP of any of them.

Nominating as an nsbeta2 stopper for these reasons:
1) It's really bad for us to fail w/ a JS error on pages with applets when the 
JVM isn't installed (embarrassing glitch)--much better to fail silently
2) We want this feature enabled in nsbeta2 so that it can be broadly tested to 
identify any bugs

Comment 5

[leger]

Putting on [nsbeta2+] radar.

Comment 6

[Phil Schwartau]

Not an engine bug; reassigning to Browser-General 

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Marking confirmed based on previous comments.  Existing bugs on javascript: URLs 
that could be relevant include bug 36081, bug 43652, and bug 25821.  It's not 
clear to me whether any of those would fix this.

Comment 8

[Doron Rosenberg (IBM)]

any idea where this should go? plugins perhaps?

Comment 9

[av (gone)]

This is not a plugins issue. To isolate the problem one can just type 
javascript:window.open("http://home.netscape.com/"); in the URL bar and see that 
it is not working.

Comment 10

[Asa Dotzler [:asa]]

this is either bug 38537 or bug 31818 I think.

Comment 11

[av (gone)]

Hm. And both are resolved.

Comment 12

[Sherry Shen]

From Bugzilla, 38537 fixed the part and 31818 handled 
the rest of the problems such as
 javascript:window.open( "http://www.mozilla.org" );

However, the problem here was found after the fix of 31818 
was checked in at June 13, 2000,  i.e.  the 44022 was based 
on my build checked out from the TIP at June 26, 2000.

Hence, other work may be needed for 31818 on Window NT.

Comment 13

[Brendan Eich [:brendan]]

Someone needs to debug this a little, see where things go south.  Adding mstoltz 
and hoping someone beats me to it.

/be

Comment 14

[Brendan Eich [:brendan]]

Re-summarizing.

Comment 15

[Andreas Franke (gone)]

This may be XP. On PC/Linux, build 070120, I get the following shell output:
Entry at index 0 is javascript:window.open("http://www.mozilla.org");
JavaScript error: 
 line 0: 

Document: Done (0.476 secs)
Error loading URL javascript:window.open("http://www.mozilla.org"); 

Comment 16

[Andreas Franke (gone)]

On PC/Linux, build 2000070608, the output is even more verbose:

Entry at index 0 is javascript:window.open( "http://www.mozilla.org");
JavaScript error: 
 line 0: 

JavaScript error: 
 line 0: uncaught exception: [Exception... "Access to property denied"  code:
"1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)"  location:
"<unknown>"]

Adding url javascript:window.open( "http://www.mozilla.org"); to SH
Document: Done (0.46 secs)
Error loading URL javascript:window.open( "http://www.mozilla.org"); 

Comment 17

[Doron Rosenberg (IBM)]

think this is a issue in the js engine? Or rather a dom 0?

Comment 18

[Asa Dotzler [:asa]]

updating component and setting default owner.

Comment 19

[Johnny Stenback (:jst)]

There were two problems with loading javascript: URL's from a plugin, the first
problem was that the plugin didn't set a notifiacation callback reciever on the
channel, this is used by the javascript URL for accessing the script global
object. The second problem was that the plugin code didn't supply a owner
principal to the channel, that caused most (all?) security checks to fail and
thus javascript: URL's weren't working...

I just checked in a fix for both those problems, marking FIXED.

Comment 20

[Prashant Desale]

Verified with 2000-12-15.