Closed Bug 91366 Opened 23 years ago Closed 23 years ago

blank window pops up when I click on 'get java plugin' button

Categories

(SeaMonkey :: UI Design, defect, P2)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.4

People

(Reporter: shrir, Assigned: paulkchen)

References

(
URL
)

Details

(Whiteboard: pdt) 

seen on win NT , 98 on today's branch builds. bad bug..i would say

not sure if this is OJI or plugins
steps:

1 without installing java, launch the browser
2 go to this page above
3 on the right, click inside the puzzle icon to get the plugin where it says
  "click here to get the plugin"
4 The "Plugin not loaded' dialog pops up.
5  click on "Get the plugin' button
6  observe that a blank window pops up with the following text inside the url 
bar :

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


7 If I click inside the url bar and hit ENTER, then the small window that allows 
me to choose between windows and linux java...appears. 

We don't expect the user to click inside the url bar and then see the download 
dialog..this sucks
serverty:major
Severity: normal → major
Summary: blank window pops up whien I click on 'get java plugin' button → blank window pops up when I click on 'get java plugin' button
I think it's neither plugin nor OJI bug. JavaScript?
BTW, in the trunk buils I see an empty URL bar, which is even worse and which is 
probably our bug.
cc: jst 
It comes all right up to nsWebShell::OnLinkClick() with to my eye normally 
looking unichar url.

--> browser-general for reconsidering component
Assignee: av → asa
Component: Plug-ins → Browser-General
QA Contact: shrir → doronr
when in doubt XPApps.
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
*** Bug 95712 has been marked as a duplicate of this bug. ***
I just stepped through this on the trunk while looking at Bug 95712 and I see
exactly the same thing as Andrei. I verify that a OnLinkClickEvent is placed on
the event queue with the correct URL. From there, I don't know what happens.
Is this the correct owner for this bug? Could it be a URILoader problem as the
console spits out:

WARNING: js returned no result -- not replacing window contents, file
S:\mozilla\uriloader\base\nsURILoader.cpp, line 186
I accept that bug 95712 might be a dup of this bug.  But if that is the case,
then this bug should have information about how 'codebase' attribute appears to
be the culprit.  I'm cutting and pasting my comments from bug 95712 , which I
believe are instructive about 'codebase.'

Here are the preconditions for
this bug:

1. Have an install of Moz' (or, say, N6.1) which does NOT have Java Plugin (OJI
plugin) installed also.

Here's how to induce this bug to occur:
1. Suppose you access a page with an invocation to an applet using the applet
tag.  Suppose the Applet tag looked like this:

<APPLET CODE="WordWriter.class" WIDTH="250" HEIGHT= "250">
</APPLET>

2. Since you don't have the plugin, you'll see that immediately after clicking
on the broken jigsaw piece ('click here to obtain the plugin'), an HTML window
is opened that allows you to choose the version of the plugin you wish to
download.  This page comes from the Netscape plugin finder page.  A click
prompts the XPI download.  You'll have to restart your browser, but at least
you've obtained the desired Java Plugin.

3. NOW, here's the bug: suppose your invocation to the Applet looked like this

<APPLET CODE="WordWriter.class" CODEBASE="." WIDTH="250" HEIGHT= "250">
</APPLET> Note that all I've done is add the CODEBASE attribute.  Note also that 

I don't have the JRE 1.3.x installed (no plugin).  Click on the "Plugin Not
Found" box.  Now, you'll get an additional dialog box asking you if you want to
download the plugin.  Clicking "Get the Plugin" causes a new window to be opened
with this URL:

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

This JavaScript is never evaluated, and therefore a window is never *really* opened.

Note that the URL portion of it, and the specs given to window.open, specify a
window that's exactly the same as the window that opens so smoothly *WITHOUT*
the CODEBASE attribute.

Expected Behavior: Adding the CODEBASE atrribute should cause a smooth download
if you don't have Sun's plugin.

Actual Behavior: The download never occurs unless a 'savvy' user (aren't we all
savvy?) edits the URL above and drops the "javascript:" portion.  This is bad.
Test cases to follow, but any applet will do.


Nominating 'nsenterprise.'  Please get it daignosed and reassigned soon, if it
doesn't belong to plugins.
Keywords: nsenterprise
nav triage team:

marking nsbeta1+, p2, and mozilla0.9.5
Keywords: nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.5
This works for me under mozilla linux build 2001081715. Can someone else try
this out on a recent build under windows? My windows machine doesn't have a
network connection because my powerbook is using it to update its tree.
I had retried this today morning on 0821 trunk winNT...still does not work for 
me.

Message in javascript console:
" Attempt to load a javascript: URL from one host in a window displaying content 
from another host was blocked by the security manager. "
I tried today's Win32 trunk build, but I didn't see the URL field filled. 
It was blank. Have you seen this problem both ways -- with or without URL
field filled in? 
Kat, see av's comment here: (I see the same too)
------- Additional Comments From Andrei Volkov (av) 2001-07-18 15:25 -------


PLEASE set the appropriate target milestone.  I'll escalate if need be, but this
should be on the Moz' 0.9.4 radar.  It is already tagged nsenterprise.
Target Milestone: mozilla0.9.5 → mozilla0.9.4
Ok, found out who returns the NS_ERROR_DOM_RETVAL_UNDEFINED. It's the code
checked in by mstoltz in nsJSProtocolHandler.cpp in version 1.63 to fix bug
77485. Check-in comment is "defining a function in another window using a
targeted javascript: link. Prevent running javascript: urls cross-domain and add
a security check for adding and removing properties." Adding mstoltz to cc-list.
pchen,

Cool! But why does this issue only get created when the APPLET tag contains the
CODEBASE attribute? nsJSProtocolHandler.cpp isn't providing any clues :-( but
this isn't surprising.  for testcases using applets with and without codebase,
you can look at bug 95712 .


 
The problem seems to be that we don't alow scripts from a host execute a
javascript: URL targetted at a window where about:blank is loaded. Mitchell, do
we need to alow this in nsJSProtocolHandler (i.e. special case "about:blank"),
or is that exploitable somehow?
Could someone test and see if this is fixed now, I'm guessing that Mitchell's
fix for bug 92061 fixed this problem as well.
Anyone?
Seemed to work much better for me on with my debug build on Windows 2000.
hm, bugzilla never sent me a mail updating me on the status of this bug,weird!  
Anyway, good news! This is working fine on 0904 win and linux trunk. Can 
download the jre fine. marking fixed..pls verify.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
OK, I'm on the verge of marking this verified. But I need some explanation first. 

 I tested on today's Trunk Build (09/05/01).  However, some things are certainly
worthy of note:

Applets that use the CODEBASE attribute generate additional dialog boxes.  The
first dialog box is the non-XUL based "Get the Plugin" dialog box.  Then, you
open a new window, which in turn opens a new window!  This intermediate new
window is fed the following URL: 
javascript:window.open("http://home.netscape.com/plugins/jvm.html?mimetype=application/x-java-vm","plugin","toolbar=no,status=no,resizeable=no,scrollbars=no,height=252,width=626");
Previous to Mitch's fix, the operation would choke at this stage.  But now, the
intermediate window has content.  This content says "[object Window]" and then
the javascript: url above opens a smaller window on which the user can click to
finally obtain the XPI plugin.
  Question: WHY does the CODEBASE attribute result in this behavior?  Is this
desired/necessary behavior?
arun, hope you don't mind my handing this to you [considering your last comment]?
QA Contact: sairuh → aruner
Arun,

For as long as I can remember, this has been the behavior I've always seen when
downloading the Java plugin. I'm not sure if CODEBASE is the exact trigger as I
think I can reproduce your results without it. The "[object Window]" is the
result of the evaulated Javascript command and I think this is doing what is
expected. We should probably change the Javascript to be a bit smarter. Any
suggestions? We should probably open a new bug.
yep, Arun, the java.sun.com page does not use the codebase attrib too.
OK, I'm VERIFYING this one, but also marking it PDT since I've nominated it. 
Hopefully it can make branch landing soon for more QA.
Status: RESOLVED → VERIFIED
Whiteboard: pdt
This is in 0.9.4, correct?  Are you adding PDT for tracking purposes?
I haven't concluded that this is on the branch yet, whoops!  this was as a
result of mitch's fix,since nothing happened check-in wise as a result of this
bug report. so i'll check bonsai/etc. and test a branch build.  marking nsbranch
Keywords: nsbranch+
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.