With a new mozilla installation i visited a page containing java. The 'go here to install this plugin' dialog popped up prompting me to install the jvm. I clicked, and the jvm download page poppped up but I couldn't do anything with it because the stupid modal dialog was still hanging around on my screen buried under other windows. I figured mozilla had locked up yet again and was about to kill it. Dismissing the dialog fixed everything.

Well, the problem is that a (hidden) modal dialog blocked the app, but isn't this really just a symptom of bug 55222? I think this is a duplicate. Looks like we should have somebody investigate this. Seems like there should be a way to tell JavaScript to pop the modal dialog on top; otherwise, what's the point of a modal dialog? Also, copying our resident student XUL expert in case he can offer any JavaScript advice here. Timeless: if you have anything helpful to say, I'd appreciate it.

[object window] ? those are fun. fwiw, on w32 10/05-08 talkback the dialog was not modal so i didn't really have problems. I'm going to examine this in linux.

the dialog is very different between win32 and linux, i'm going to rewrite the gtk dialog using xul (and i guess i'll write the hookup code too)

Setting MY priority [P1] and milestone [M19] for pr3 we should explain that the linux plugin downloader dialog might not go away when you click the ok button. For me it didn't go away the first time, but when i went to reproduce it the dialog worked correctly. In order to reproduce I created a new profile.

the chrome works. test: javascript:window.openDialog("chrome://navigator/content/nullpluginDialog.xul","NullPlugin","","application/x-java-vm","http://home.netscape.com/plugins/jvm.html") goes to the jvm page javascript:window.openDialog("chrome://navigator/content/nullpluginDialog.xul","NullPlugin","","audio/midi") goes to get a midi plugin. however, activating the plugin fails <output> WARNING: not calling OnDataAvailable, file nsAsyncStreamListener.cpp, line 403 InstantiateEmbededPlugin for application/x-java-vm Inside nsPluginHostImpl::FindStoppedPluginForURL... debug: edburns ns4xPlugin::CreatePlugin debug: edburns ns4xPlugin::CreatePlugin: cleared callbacks debug: edburns: ns4xPlugin::CreatePlugin: callbacks->newstream: 0x4115f4a8 Inside ns4xPluginInstance::Start(void)... Inside ns4xPluginInstance::SetWindow(0x8a9d72c)... About to create new ws_info... About to create new xtbin of 120 X 150 from 0x8a9df08... About to show xtbin(0x8a9e988)... completed gtk_widget_show(0x8a9e988) About to call CallNPP_SetWindowProc()... This->pluginsFileUrl: (null) url: javascript:window.openDialog("chrome://navigator/content/nullpluginDialog.xul","NullPlugin","","application/x-java-vm","http://home.netscape.com/plugins/jvm.html") timeless:~/mozilla/dist/bin: </output> I think it's because of a security violation (trying to execute a javascript: url) a non javascript url did work. DEBUG_timeless is defined. I just realized there might be an example of functional javascript in the plugin (looking) If I can't figure this out, helpwanted getting the last steps linked together.

I re-installed java with yesterday's build and no longer had the problem of the hidden modal dialog locking things up.

Is this bug still present (see Dawn's comments)? 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

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. if it is a problem then maybe something like this: Browser locks up when installing plugin - Sometimes new windows obscure modal dialogs when installing plugins. If the browser locks up when installing a plugin, try minimizing browser windows until the dialog is visible and dismiss it. (it might be good to say "dismiss the dialog by pressing 'OK'", but i'm not sure what the buttons say)

I am pretty sure that this problem does not happen anymore. Dawn, pls confirm with a latest build and comment. Thanks.

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

I just tried this again with today's build (and a new ~/.mozilla directory since the last time) and the problem showed up again. I visited http://mozillazine.org/ and the plugin dialog popped up asking whether to download the java plugin or not. I pressed the button to go ahead and download the plugin. A new browser window popped up containing the java download page. http://home.netscape.com/plugins/jvm.html I pressed the 'linux' button to install the java plugin for linux. Nothing happened. I moved the browser window out of the way and the modal dialog was still sitting there. I dismissed it by hitting 'cancel' and was able to continue downloading the plugin. I see two problems here: 1. Modal dialogs should always be on top no matter what. 2. The act of clicking the button to download the plugin should have dismissed the dialog but it did not. The only way to make that dialog go away is to hit cancel. I think the real subject of this bug is item 2.

the same thing happened to me trying to load the flash plugin as well.

I see the problem Dawn mentioned 1 The modal dialog does not go away automatically 2 Clicking on "Get Linux Java Plugin" does not do anything. The problem mentioned in 2 is really bad and how the heck does a user download jre if this thing does not work ? This should be fixed for rtm.

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

spoke too early, I observe that this works fine on java.sun.com(I can doenoad plugin and modal box goes away) but on http://www.amazing-bargains.com (which I marked as a dup of this one since I tested that one before I commented here) I see the problem what Dawn mentions. Strange...

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

http://www.chinatimes.com shows another version of this. The modal dialog just keeps popping up even after you close it. This problem is_a_bad_one. I am removing the 'RelnoteRTM' keyword and renominating this for rtm.

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

severity: major.

Per chat with trudelle, reassigning to danm. cc:ing serge b/c Andrei thinks serge is working on a bug that may be related.

marking rtm need info to get on radar.

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

I see weird behaviour when flash plugin is absent too. This is a bad problem :(

logged bug 58644 for the problem for flash.

So, the flash problem is another bug and this one seems focused on the java plugin. Seems like the people who want java would take it from our installer and never see this. I think I also saw a bug where there are problems taking just any old java anyway. Is it time to let this go rtm- now?

As I noted earlier, this problem also happens with flash. The bug Shrirang filed above is for a separate issue. (the flash download page has layout or html problems). This seems like a problem with the mechanism that directs people to download plugins, not with the plugin site itself. (would that be the null plugin or something on netcenter?)

i just verified that this is still a problem with the flash plugin on this morning's trunk build. Theoretically, this could be tested with the realplayer plugin too, but I don't know of any pages that have embedded realmedia content.

I just found a page with embedded realmedia. http://www.support.dsu.edu/multimedia/RealMedia/embed/embed28k.htm The dialog isn't dismissed in this case either.

I agree with Steve, this sounds pretty marginal. I don't see how it fits the current 'pull it off the wire' criteria, or even comes close.

PDT marking [rtm-]. N6 users will already have the most important plugins, and even for the plugins they don't have, the plugin works after it's been installed.

wrote an item for this in vera's RTM release note bug http://bugzilla.mozilla.org/show_bug.cgi?id=50809

I was playing around this bug for awhile, here is what I found: default plugin dialog on linux is hanging around in case <embed> tag is inside <td></td> tags and if that table cell has some more tags after <embed> I've attached a simple test case to reproduce.

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

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

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

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

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

Please see the evaluation and fix attached to bug 60064. We believe it also fixes this problem.

I don't understand how the fix for bug 60064 could help. That bug (and patch) are about the problems that happen when circumstances conspire to give you more than one of these (modal) dialogs simultaneously. I can't vouch for it, but the patch attempts to limit you to just one. This bug complains that even one is problematic. Looks to me like the dialog's OK button queues up two simultaneous asynchronous tasks: open a new browser window and close the dialog. For some reason the dialog closing doesn't go through. (Perhaps it would after the browser window is closed, but since that's impossible...) My love for modal windows is largely limited to those moments they spend mud wrestling. And this one's not doing much of that. We could play stoopid timer delay tricks, or just this patch, which fixes the problem nicely: --- nullplugin.c 2000/10/12 00:20:34 1.2 +++ nullplugin.c 2000/11/29 00:29:07 @@ -202,7 +202,6 @@ This->dialogBox = dialogWindow; gtk_window_set_title(GTK_WINDOW(dialogWindow), PLUGIN_NAME); /* gtk_window_set_position(GTK_WINDOW(dialogWindow), GTK_WIN_POS_CENTER); */ - gtk_window_set_modal(GTK_WINDOW(dialogWindow), TRUE); gtk_container_set_border_width(GTK_CONTAINER(dialogWindow), 0); PR_snprintf(message, sizeof(message) - 1, MESSAGE, This->type); any reason not to?

Now when the window is not modal, what is going to happen if user goes to another page not dismissing this window first?

Ooo. Well, you crash. But I'm inclined to think of that as a separate plugins bug. It's just a download window. What naughty thing is it doing that it depends on the contents of the parent browser?

The other bit about making this modal is the modal dialog blocks _all_ threads which can be confusing to a user.. I normally have more then one Browser window open, mail/news open. Typical situation, try to open a slow sight in one window, wait... get tired of waiting, minimize that window, flip to another browser instance. Do some reading on the page that is loaded there, (all this is happening on multiple desktops) Go to click on something, nothing works? Flip back to the orginal window, lo and behold it wants you to click on something. As for non-modal dialogs and what should happen to em, leave the page? kill the dialog.

When we leave the page we should destroy all windows that belong to the plugin. Otherwise crash is inevitable. So with this addition I think we could go with the fix.

Gotta agree; modal windows are pretty much never your friend. But I'm not prepared to write the code to kill this dialog when the user navigates elsewhere. Regardless, I've finally figured out what the real problem is. The value of the PluginInstance's member variable dialogBox has been altered by the time it comes back to to OK button event handler. That pointer was the handler's only means of killing the dialog box, and that's why the dialog doesn't die. I don't know why (presumably) the caller is doing such rude things with dialogBox. I'm attaching a patch which stores the dialog pointer someplace else, from which it can be safely retrieved. Solves the problem.

Although we still don't know why it is altered (could be a tip of a bigger problem), I think associating private date with the window itself is generally good thing to do. This approach looks right to me. r=av

r=pavlov

a=hyatt

.

I have a simple question, why do we still use GTK widget? I understand that using GTK native widget in Mozilla causes a problem of I18N/L10N because there is no common way for L10N contributors to localize the messages on the dialog. Is there another bug that changing to xul based window?

This bug has gone through a few different owners and meant a few different things. At one time rewriting the dialog in XUL seemed to be the answer. Look above for a comment from timeless dated 2000-10-5 18:08. He's no longer cc:ed on this bug, though. I'll ping him to see where that effort ended up.

Thanks, danm. I've filed new bug 62513 for XUL dialog. All GUI compoments on Mozilla need to be created by XUL for I18N/L10N. The same problem was reported in bug 47553 that Editor still uses GTK+ filewidget.

does not happen anymore. VERIFIED on branch and trunk.