Closed Bug 55222 Opened 24 years ago Closed 12 years ago

extra browser window pops up when trying to fetch a plugin

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: buster, Unassigned)

References

(
URL
)

Details

(Keywords: relnote, Whiteboard: relnote-user) 

1. Using commerical build ID 2000100408 on WinNT.
2. Open http://baseball.espn.go.com/mlb/scoreboard
3. Click on "Gamecast: Pitch-by-pitch coverage link" which resolves to:
  onClick="launchGameCastWindow('sfo'); return false;"
4. a window pops up with a big box containing the "I don't know this plugin"
image and "Click here to get the plugin".  Click on that image.
5. You get a dialog about needing application/x-java-vm.
6. Click Get the plugin button.
7. You get a new browser window with
"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");"
in the URL bar and "[object Window]" in the content area.
Behind that is the window that has the page to get you to sun.

This first pop-up browser window is odd, and hides the window that I need to get
the plugin.
Here's the javascript that launches the window:
function launchGameCastWindow(hteam) {
window.name = "_gamecast";
var url =
"http://scores.espn.go.com/cgi/gamecast/mlb/index.asp?season=2000&date=20001004&hteam="+hteam+"&live=true";
var name = "gamecast_" + hteam;
launchWindow (url, name, 630, 600);
}

yep, this has been there for a while. Let me check if there is a bug filed 
against this.
A similar thing happens on the Sun site when you try to download Java for the
first time.

I think this could be a Mozilla-only bug since in commerical Netscape, we ship
with the Java plugin already installed and therefore you aren't prompted to
download anything. Works pretty good for me with PR3.

*** Bug 55223 has been marked as a duplicate of this bug. ***
This will not be a Mozilla-only bug. We only bundle the Sun JVM with Netscape 6 
Custom (default Custom == Complete since all options are turned on), not in 
Minimal or Typical.

The best user experience would be: (1) If you need Java, only the Java window 
pops up. (2) If you need a plug-in, only the plug-in finder window pops up.

It's unfortunate that two windows are popping up, but this may fall into the 
category of "things we can live with for RTM." Thoughts?

cc:ing johng as NavPM for thoughts on Navigator Plug-in download UE, rebron for 
Netscape.com plug-in downloading UE consideration, drapeau because this impacts 
the ease of getting the Java VM and Sun may be concerned enough about that 
distribution UE enough to supply a resource to fix this even if Netscape can't.
I think return false might not be working. I need to make a huge testsuite for 
it.
ekrock: this is not something that customers will live with. They'll see a
locked up app, assume that plugin installation is hopelessly buggy and give
up. When this happened to me I accidently noticed the modal dialog and
dismissed it. I doubt that most people will be that patient or care enough
to bother reading release notes.

Speaking of which, does this affect pr3? Should it be added to the release
notes? Adding relnote keywords just in case.

How about at least making the dialog non-modal.
Keywords: relnote, relnote3
I cannot see the lock up. Everything is alive, and this unwanted window can be 
easily dismissed. I also don't see step 7 as described. After step 6 I can see 
the browser window which gives you a choice between Windows and Linux plugin and 
the big empty window covering it. Is it launched by javascript on the page? Then 
there is little we can do.
"the big empty window" is step 7, I think, only it wasn't quite empty for me.
It had the text "[object Window]" in the content area

No lock up for me...i can dismiss the window and dialog easily.
Dawn endico's comments shud have been in bug 55261 rather than here. Ther eis no 
lock up issue on windows. I tried installating this today and I see two windows 
open up. One as mentioned by buster and the other window pops up after you have 
downloaded the file using ftp. The window says something like "Install success" 
while the installation is about to begin in the background.This window comes 
above all open windows and user has to minimize other windows to proceed with 
the jre installation.Why do we need full size windows popping up after every 
click? This certainly looks bad. (build used:2000100608). For the records, 
installation proceeds fine and java plugins gets installed.
I re-installed java with yesterday's build and no longer
had the problem of the hidden modal dialog locking things
up.

Additional Comments on bug 55261 From timeless@bemail.org 2000-10-05 14:01 
[object window] ? those are fun.  fwiw, on w32 10/05-08 talkback the dialog was 
not modal so i didn't really have problems.

The entire plugin stuff needs a lot of love. I have a chrome system set up in 
bug 55261, but i need someone who can convert the win and unix plugins to xpcom 
(I'm almost certain they're both legacy) or at the very least get mozilla to 
execute javascript urls.  I don't have a win32 build environment so i can't 
test hacking the win32 plugin.

av/ekrock, if you convert the plugin to use the chrome supplied in bug 55261 I 
think we'd be done.

[boy I can't wait for the new bugzilla schema]

I think I saw another bug where if the last function in a javascript: url 
returns a value, the Mozilla goes to a page whose url is the entire javascript: 
url and whose content area is just the value returned from the last function.  

For example,

<script>
 function f () { return 1; }
 fucntion g () {           }
</script>

<a href="javascript:g(); f();">do function f</a>

will take you to javascript:g(); f();, with "1" in the content area.


I can't find the bug, though :(  
Bug 36081 is similar to what I just described, but I don't it's the same bug.

I'm also not sure why in this case the javascript thing ends up in a third 
window instead of in the original window (the one with the espn page).

(The problem at the espn page doesn't happen for me, btw.)
I'm not sure what I was doing last week.  If I fix the typo "fucntion", I get 
the same results on IE, Moz, and NS 4.x.  Oops :)
Dawn, does this need an RTM release note of any sort?

The blurb:
It seems unclear to me whether this bug requires either of a "developer" or 
"user" release note for Netscape 6 RTM. If anyone feels it does, can they please 
draft one and then nominate with the relnote-user or relnote-devel strings in 
the Status Whiteboard.

Thanks :-)

Gerv
Someone else needs to right the relnote text, basically it's an explanation of 
how to get to the important window. I think it is as simple as closing a window 
whose content becomes [object window] after invoking the plugin downloader
Whiteboard: relnote-user
I added the relnote keyword because of the problem I had where
everything was locked up because of the hidden modal dialog.
If that's not a problem any more then I guess there's no need
for a relnote. (bug 55261)

Future. Not a N6 RTM blocker.
Target Milestone: --- → Future
Mozilla's behavior when the last statement of a javascript url returns a value 
is correct (I was wrong in my 2000-10-12 comment).  Browsers replace the 
current page with String(returnvalue).  Bookmarklet authors usually get around 
this behavior by enclosing the last command in void() or by adding void(0) 
after the last statement.

The bug in the plugin handler is around
http://lxr.mozilla.org/seamonkey/source/modules/plugin/default/windows/plugin.h#
94 and can be most likely be fixed by changing one or two lines.  See also 
plugin.cpp#347.
Is anyone still seeing this bug?
this is not happening anymore, if you do encounter a "freeze" please see bug 
131508. The extra pop-up is not happening. If you do encounter this problem, 
please reopen and specify steps to reproduce.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
hm, I think I saw it last week. Let me try this again. The jre installer is 
wrapped up in xpi but I still see the "blank object widnow'. Gotta confirm 
this.....
Like I guessed, This still does happen. ON today's breanch build on NT, if a 
user has one browser window open and clicks on the default plugin to download 
the java plugin..at the end of the installation, he ends up with 3 more windows 
(two browser windows : one that says '[object window]' and another one that 
gives you the installation results. The third window is the popup which allows 
you to choose the version of jre one wants.
In an ideal world, one would like to see only the "installation results" message 
window ( that too should be made to go away automatically..maybe" . Other two 
windows are useless after the installation. One has to close them manually. 
Reopening......
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I could not get this to happen on the trunk, I didn't test this on the branch
this needs to be resolved by the xpi team. A suggestion to resolve this could be:
-> check out the ipix download, see
http://www.ipix.com/cgi-bin/download.cgi?application/x-ipix
Assignee: av → greggl
Status: REOPENED → NEW
Priority: P3 → --
Target Milestone: Future → ---
*** Bug 156557 has been marked as a duplicate of this bug. ***
Assignee: greggl → nobody
QA Contact: shrir → plugins
This doesn't happen any more.
Status: NEW → RESOLVED
Closed: 22 years ago → 12 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.