662770 - noautohide panels unresponsive if opened from a modal window

Status: NEW

(Core :: XUL, defect)

Description

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: test case

I guess the title says it all. If a modal window opens (on linux) a noautohide
panel, the entire panel is unresponsive. No UI element works inside it.
This bug does not affect Mac OS X and I haven't tested yet on windows.

I have written a small xpi for Firefox that show the bug. It's attached here.
It adds a "Panel bug" entry to the Tools menu. Selecting it will open a modal
window and a button inside that window opens a noautohide panel. The button
inside that panel is unresponsive on

  ubuntu 10.04 i386
  ubuntu 10.10 x86_64
  ubuntu 11.04 i386

Comment 1

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

FWIW, the bug blocks the CSS Pro Editor for BlueGriffon on linux.

Enn, do you think this is fixable in Gecko or is GTK guilty here? I'd
like to know if I can expect some kind of fix or if I need to rewrite
my own code to get rid of noautohide panels on linux. Thanks!

Comment 2

[Neil Deakin]

Attachment: testcase

The panel is not receiving any mouse button events (press or motion). The parent modal dialog does receive events when moved or pressed over.

Comment 3

[Neil Deakin]

(In reply to comment #1)
> Enn, do you think this is fixable in Gecko or is GTK guilty here? I'd
> like to know if I can expect some kind of fix or if I need to rewrite
> my own code to get rid of noautohide panels on linux. Thanks!

Likely fixable but Karl will likely need to investigate as it's beyond my gtk knowledge.

Comment 4

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #3)

> Likely fixable but Karl will likely need to investigate as it's beyond my
> gtk knowledge.

Thanks. Yeah, mine too. I tried a few things in nsXULPopupManager and
gtk2/nsWindow but it went nowhere.

Comment 5

[Karl Tomlinson (:karlt)]

Neil: what do you do to run your testcase?
(I tried setting dom.allow_XUL_XBL_for_file and using -chrome modalpanel.xul, but the window opened when pressing the "Window" button was not modal.)

Comment 6

[Karl Tomlinson (:karlt)]

What's happening is that the gtk_window_set_modal call does gtk_grab_add on the toplevel window.  That means that any events on other windows (including the noautohide panel) are sent to the widget for the toplevel modal window.  We don't listen for mouse events on that widget.  If we did, then our modal windows would not be modal (i.e. other windows would get events).

I guess it would be possible to

-    gtk_window_set_modal(GTK_WINDOW(mShell), aModal ? TRUE : FALSE);
+    gdk_window_set_modal_hint(mShell->window, aModal);

and either implement modality within Gecko,
or change the grab to the container widget where we do listen for events and send them off only if their windows are descendants or associated popups.

I wonder how modality is implemented on other platforms.

Comment 7

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #6)

> I guess it would be possible to
> 
> -    gtk_window_set_modal(GTK_WINDOW(mShell), aModal ? TRUE : FALSE);
> +    gdk_window_set_modal_hint(mShell->window, aModal);
> 
> and either implement modality within Gecko,
> or change the grab to the container widget where we do listen for events and
> send them off only if their windows are descendants or associated popups.

Karl, thanks for the answer. Do you think this is fixable in a reasonable
timeframe or do you suggest I work around the issue on Linux? This is
blocking my CSS Editor on Linux (while the Mac and Windows version work
absolutely fine with noautohide panels opened from a modal window) and
tweaking my code to fix the linux issue will imply probably a full week
of work. Thanks!

Comment 8

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

This maybe stupid, but could a temporary fix (until a more complex and full
implementation is done) be to make noautohide panels themselves modal? Then
a noautohide panel opened from a modal window is itself an undecorated modal window
and even if that's not _exactly_ what a panel is, at least the panel is
responsive to UI events? I am willing to add that as a patch to BlueGriffon's
core instead of adding that "hack" to mozilla-central but this goes beyond
my personal gtk knowledge... If you think it is workable, can you tell me
how?

Comment 9

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: workaround for bug 662770

Ok, I tried the strategy exposed here earlier and it seemed to work fine.
I am attaching a patch that does exactly what I meant. Karl, is it the
right place to do that and the right thing to do as a workaround?

With that hack in, noautohidable panels become modal and ARE responsive.
Granted, it's not perfect but at least there is no loss of functionality
in BlueGriffon on Linux. I am perfectly fine to live with that until a
cleaner solution is found and implemented in mozilla-central.

Comment 10

[Karl Tomlinson (:karlt)]

(In reply to comment #7)
> Karl, thanks for the answer. Do you think this is fixable in a reasonable
> timeframe or do you suggest I work around the issue on Linux?

I expect this is fixable but I'm not clear on what what be the appropriate fix and I don't think this would be a priority.  User interfaces are moving away from modal dialogs, modal dialogs are usually short-lived and noautohide panels are more likely long-lived, so this seems an unusual situation.

(In reply to comment #8)
> This maybe stupid, but could a temporary fix (until a more complex and full
> implementation is done) be to make noautohide panels themselves modal? Then
> a noautohide panel opened from a modal window is itself an undecorated modal
> window and even if that's not _exactly_ what a panel is, at least the panel is
> responsive to UI events?

I expect making the panel modal will block events from the dialog to which it belongs, and it would also do similarly when a noautohide panel is opened from a non-modal window.

As a workaround, I would suggest the gtk_window_set_modal/gdk_window_set_modal_hint change in comment 6, and explicitly setting enabled to false on windows that should not accept input.
http://hg.mozilla.org/mozilla-central/annotate/9b43783ab8ec/widget/public/nsIBaseWindow.idl#l195

Perhaps that is even the appropriate fix for this bug - I'm not clear.

Comment 11

[Firefox Bug Husbandry Bot]

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336