280895 - javascript alert are not modal when input element exists

Status: RESOLVED DUPLICATE of bug 290862

(Core :: Widget: Gtk, defect)

Description

[Nian Liu(n/a in a long time)]

1.open test case
2.input in textbox and alert will pop up
3.focus on textbox and continue input, alert can still pop up

expect result: user should have no chance to input in textbox when javascript
alert pops up

Comment 1

[Nian Liu(n/a in a long time)]

Attachment: test case

Comment 2

[Boris Zbarsky [:bzbarsky]]

This worksforme in a 2005-01-25-06 build -- once the alert comes up, I can't
type anymore.

Reporter, what build are you using?

Comment 3

[Nian Liu(n/a in a long time)]

I use Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050204. This is
for Linux only. And to reprocude it, the key step is that use mouse click to
focus on textbox after alert pops up, then use keyboard to input in textbox

Comment 4

[Boris Zbarsky [:bzbarsky]]

Well, I'm testing this in a Linux GTK1 2005-02-09-05 nightly build, and I'm
definitely clicking in the textbox.  I can't reproduce the bug.

Are you using a GTK2 build, or GTK1 build?

Comment 5

[Nian Liu(n/a in a long time)]

GTK2 build. Thanks.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hmm.... I just tested a GTK2 Firefox build, and it works there too....

Comment 7

[Nian Liu(n/a in a long time)]

my config switch

--enable-optimize --enable-xft --disable-freetype2 --disable-tests
--enable-debug --with-xprint --enable-xinerama --enable-ldap --enable-crypto
--enable-x11-shm --disable-gtktest --disable-glibtest --disable-libIDLtest
--disable-auto-deps --enable-ctl --enable-default-toolkit=gtk2
--enable-ldap-experimental --enable-extensions=default,sroaming
--enable-application=suite 

Comment 8

[Nian Liu(n/a in a long time)]

And I can reproduce it on my firefox based on GTK2 which is checked out on Tue
Jan 18 17:42:58 CST 2005

Comment 9

[Nian Liu(n/a in a long time)]

Attachment: patch

Comment 10

[Nian Liu(n/a in a long time)]

I use GTK2.4.9 

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 174560 [details] [diff] [review]
patch

I'm sorry, but I can't review this.  I'm not a module owner for this code, and
I don't even know what it's doing...

Please request review from the module owner or peer.

Comment 12

[Christopher Blizzard (:blizzard)]

This is pretty sensitive code.  Focus handling is pretty fragile.  I suspect
that this needs to walk up the widget chain and make sure that it's a child of
the grab widget, not just the grab widget.

Bryner, any ideas since you've looked at focus code too?

Comment 13

[Nian Liu(n/a in a long time)]

Blizzard, do you think it's really a Mozilla bug or a potential GTK bug?

Comment 14

[Christopher Blizzard (:blizzard)]

Probably a mozilla bug.

Comment 15

[Nian Liu(n/a in a long time)]

Attachment: patchv2

How about this one? make sure widget not in the child chain of grabWidget

Comment 16

[Nian Liu(n/a in a long time)]

Blizzard, please...

Comment 17

[Nian Liu(n/a in a long time)]

both GTK2 and Mozilla needs to modify the code to fix this bug.

For GTK2, grab with group should be implemented

For Mozilla, grab condition judge should be done in OnContainerFocusInEvent

Comment 18

[Nian Liu(n/a in a long time)]

Attachment: patch

Comment 19

[otaylor]

Isn't the problem simply that the alert dialog isn't being placed into
the grab group of the parent browser window? 

(The patch seems to try to emulate modality by ignoring focus in
when there is a grab in effect, but this isn't right.)

This may be related to:

 http://bugzilla.gnome.org/show_bug.cgi?id=69934

which is a request for global grabs that span the whole application.

It should be simple to get things right when there is only one browser
window, which is the normal case.

In the multiple browser window case, it's going to be harder... 
Mozilla *could* emulate global grabs by grabbing in each separate
grab group.

Comment 20

[Nian Liu(n/a in a long time)]

(In reply to comment #19)
> Isn't the problem simply that the alert dialog isn't being placed into
> the grab group of the parent browser window? 
> 
from nsWindow::NativeCreate, popop is added into same window group of browser window

             if (parentArea) {
                nsWindow *parentnsWindow =
                    get_window_for_gdk_window(parentArea->inner_window);
                NS_ASSERTION(parentnsWindow,
                             "no nsWindow for parentArea!");
                if (parentnsWindow && parentnsWindow->mWindowGroup) {
                    gtk_window_group_add_window(parentnsWindow->mWindowGroup,
                                                GTK_WINDOW(mShell));
                    // store this in case any children are created
                    mWindowGroup = parentnsWindow->mWindowGroup;
                    LOG(("adding window %p to group %p\n",
                         (void *)mShell, (void *)mWindowGroup));
                }
            }

For the gtk_grab_get_current error, it shows in nsWindow::SetModal if you add a
gtk_grab_get_current just after gtk_grab_add. Once gtk_grab_add is called,
gtk_grab_get_current returns null.

Comment 21

[Nian Liu(n/a in a long time)]

owen, any more comments?

Comment 22

[Frank Wein [:mcsmurf]]

Comment on attachment 183135 [details] [diff] [review]
patch

This user does not exist anymore in Bugzilla. bryner's current bugmail is bryner@b (just enter it in the review field). Make sure the patch is against trunk so, this patch looks like it was diffed against Mozilla 1.7.