55261 - GTK modal dialog locks up browser when installing plugin

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[Dawn Endico]

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.

Comment 1

[drapeau]

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.

Comment 2

[timeless]

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

Comment 3

[timeless]

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)

Comment 4

[timeless]

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.

Comment 5

[timeless]

Attachment: chrome://navigator/content/nullpluginDialog.xul

Comment 6

[timeless]

Attachment: chrome://navigator/content/nullpluginDialog.js

Comment 7

[timeless]

Attachment: chrome://navigator/locale/nullpluginDialog.dtd

Comment 8

[timeless]

Attachment: Patch [doesn't work, probably a security violation]

Comment 9

[timeless]

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.

Comment 10

[Dawn Endico]

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

Comment 11

[Gervase Markham [:gerv]]

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

Comment 12

[Dawn Endico]

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)

Comment 13

[shrirang khanzode]

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

Comment 14

[shrirang khanzode]

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

Comment 15

[Dawn Endico]

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.

Comment 16

[Dawn Endico]

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

Comment 17

[shrirang khanzode]

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. 

Comment 18

[shrirang khanzode]

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

Comment 19

[shrirang khanzode]

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

Comment 20

[shrirang khanzode]

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

Comment 21

[shrirang khanzode]

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.

Comment 22

[shrirang khanzode]

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

Comment 23

[shrirang khanzode]

severity: major.

Comment 24

[ekrock's old account (dead)]

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

Comment 25

[Peter Trudelle]

marking rtm need info to get on radar.

Comment 26

[shrirang khanzode]

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

Comment 27

[shrirang khanzode]

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

Comment 28

[shrirang khanzode]

logged bug 58644 for the problem for flash.

Comment 29

[selmer (gone)]

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?

Comment 30

[Dawn Endico]

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?) 

Comment 31

[Dawn Endico]

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.

Comment 32

[Dawn Endico]

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.

Comment 33

[Peter Trudelle]

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.

Comment 34

[Phil Peterson]

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. 

Comment 35

[Dawn Endico]

wrote an item for this in vera's RTM release note bug

http://bugzilla.mozilla.org/show_bug.cgi?id=50809

Comment 36

[serge (gone)]

Attachment: a simple test case

Comment 37

[serge (gone)]

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.

Comment 38

[shrirang khanzode]

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

Comment 39

[R.K.Aa.]

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

Comment 40

[R.K.Aa.]

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

Comment 41

[R.K.Aa.]

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

Comment 42

[shrirang khanzode]

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

Comment 43

[Rich Burridge]

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

Comment 44

[Dan M]

  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?

Comment 45

[av (gone)]

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

Comment 46

[Dan M]

  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?

Comment 47

[Gregory McLean]

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.

Comment 48

[av (gone)]

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.

Comment 49

[Dan M]

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.

Comment 50

[Dan M]

Attachment: safer storage for the dialog pointer

Comment 51

[av (gone)]

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

Comment 52

[Stuart Parmenter]

r=pavlov

Comment 53

[David Hyatt]

a=hyatt

Comment 54

[Dan M]

.

Comment 55

[Masaki Katakai]

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?

Comment 56

[Dan M]

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.

Comment 57

[Masaki Katakai]

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.

Comment 58

[shrirang khanzode]

does not happen anymore. VERIFIED on branch and trunk.