821749 - Profile manager UI does not respond to mouse button press with oxygen-gtk

Status: VERIFIED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[aleth [:aleth]]

Starting Firefox with the -P option on Linux/KDE brings up the profile manager, but the UI elements in the profile manager dialog box no longer respond to clicking (e.g. "Create Profile", "Exit", and the checkboxes). 

Everything works fine if you use the keyboard to access the same elements. The wizard which opens when you select "Create profile" does work with the mouse, but when returning to the profile manager afterwards the problem there persists.

This is a regression, but I don't know how far back it goes.

Comment 3

[aleth [:aleth]]

I've just noticed by accident that the same behaviour appears when FF is started with a profile with a lock file present. The "FF is already running" dialog also won't respond to clicking. It is less noticeable there as the dialog window can just be closed using the window manager's default window close control.

Comment 4

[Alex Keybl [:akeybl]]

Let's try to find a regression window here - our testers rely upon the profile manager, and this has been filed at least a couple of times now.

Comment 5

[u279076]

I can't even count how many times a day I use Profile Manager on Linux every day and I've never seen any problems with it. However, I'm always in a GTK environment (Gnome, XFCE, etc). I'll set up a VM with KDE and see if I can reproduce any issues.

Comment 6

[u279076]

Actually, it would be helpful to know the exact distribution and KDE version so I can most closly match aleth's system. I'll hold off trying to reproduce until I have that info.

Comment 7

[Matthias Versen [:Matti]]

Anthony: 
the KDE systeminformation from a dupe 
https://bug818192.bugzilla.mozilla.org/attachment.cgi?id=688368

Comment 8

[u279076]

(In reply to Matthias Versen (Matti) from comment #7)
> Anthony: 
> the KDE systeminformation from a dupe 
> https://bug818192.bugzilla.mozilla.org/attachment.cgi?id=688368

For the record, OpenSUSE 12.2 beta 2 32-bit running KDE 4.8.5 and Linux 3.4.11.

Comment 9

[u279076]

It's going to take me a couple days to get a VM set up and test this. In the meantime, aleth, it would be useful if you could start find a regression range. Start by testing progressively older Firefox releases until you find one where it starts working.

Comment 10

[u279076]

I managed to get the live CD running. Firefox 14.0.1 (bundled) does not reproduce this bug, latest-mozilla-aurora (19.0a2) does reproduce this bug. I'll see if I can narrow it down further without having to go through the SUSE install process.

Comment 11

[u279076]

Last Good: 2012-10-23
First Bad: 2012-10-24
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=48502b61a63e&tochange=93cc1ee94291

Nothing immediately stands out to me in the changeset.

Comment 12

[Matthias Versen [:Matti]]

bug 793501 ?

Comment 13

[Alex Keybl [:akeybl]]

Hopefully Karl/roc can look at this in the FF19 timeframe, although this is definitely a lower priority than other tracked bugs (non-standard UX and on Linux). Our users are running into this, however.

Comment 14

[George R. Goffe]

I'm running on a Fedora x86_64 system that's up to date as of a few minutes ago.

Comment 15

[u279076]

(In reply to George R. Goffe from comment #14)
> I'm running on a Fedora x86_64 system that's up to date as of a few minutes
> ago.

Thank you George. We already have a regression range. We are currently trying to fix the issue as soon as possible.

Comment 16

[Karl Tomlinson (:karlt)]

I haven't reproduced here with kwin 4.8.5, and a trunk build or a 19.0a1 nightly from 2012-11-19.

For those experiencing the bug, which window managers are in use, and which version of GTK2 is installed?

Can someone download a debug build and run with NSPR_LOG_MODULES=Widget:5 in the environment, reproduce, and attach the log, please?

Comment 17

[Karl Tomlinson (:karlt)]

Does this reproduce with -safe-mode?

Comment 18

[Karl Tomlinson (:karlt)]

Debug builds are available from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-12-25-mozilla-aurora-debug/ for example.

Comment 19

[u279076]

Attachment: debug.log

> I haven't reproduced here with kwin 4.8.5

Reproduced with Firefox 19.0a1 2012-10-24 in SUSE 12 with the following packages installed by default.
> KDE: 4.8.4
> KWin: 4.8.4
> Qt: 4.8.1
> GTK2: 2.24.10
> GTK3: 3.4.4

After checking for and installing system updates I now have the following packages installed. However the bug continues to reproduce with Firefox 19.0a1 2012-10-24.
> KDE: 4.8.5
> KWin: 4.8.5
> Qt: 4.8.1
> GTK2: 2.24.10
> GTK3: 3.4.4

> Does this reproduce with -safe-mode?
Yes, it reproduces with -safe-mode. However, as I understand Safe Mode does not come into play until after the Profile Manager

> Can someone download a debug build and run with NSPR_LOG_MODULES=Widget:5
See attached log file

Comment 20

[Karl Tomlinson (:karlt)]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #19)
> Yes, it reproduces with -safe-mode. However, as I understand Safe Mode does
> not come into play until after the Profile Manager

Ah, yes, thanks.

> OnEnterNotify: 8598050
> Button 1 release on 8598050
> Button 1 release on 8598050
> Button 1 release on 8598050
> Button 1 release on 8598050
> OnLeaveNotify: 8598050

Now that is interesting.  We seem to be getting button release events but not button press events, assuming you tried to click 4 times.

Comment 21

[u279076]

(In reply to Karl Tomlinson (:karlt) from comment #20)
> Now that is interesting.  We seem to be getting button release events but
> not button press events, assuming you tried to click 4 times.
Yeah, sorry I left off this information. Here is more detail about the action I performed as it relates to the debug message

> > OnEnterNotify: 8598050
Moved mouse onto the Profile Manager window

> > Button 1 release on 8598050
Clicked the Create Profile button, nothing happened

> > Button 1 release on 8598050
Clicked the Rename Profile button, nothing happened

> > Button 1 release on 8598050
Clicked the Delete Profile button, nothing happened

> > Button 1 release on 8598050
Clicked the Exit button, nothing happened

> > OnLeaveNotify: 8598050
Clicked the X button to close the window, window closed

Comment 22

[Karl Tomlinson (:karlt)]

Thanks, I can reproduce here with oxygen-gtk 1.3.1.

Comment 23

[Karl Tomlinson (:karlt)]

oxygen-gtk listens to events on our widgets and reports back to GTK to say that it has handled the event, and so GTK does not pass the event on to Gecko.

oxygen-gtk does this so that holding button 1 down on an insensitive part of a window can be used to drag the window (as one would with the titlebar).  This is similar to bug 566480, but perhaps a little different.  It seems quite useful UI, and perhaps bug 566480 could be extended to other chrome, but I won't address it here.

oxygen-gtk tries not to intercept events on windows that are already listening to events, but what is going wrong is that oxygen-gtk only checks this when the GtkWidget is realized.

Gecko dialogs without parent windows (Profile Manager) are special here in that they are realized before gtk_widget_add_events is called.  The code for this was added in bug 194323.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/gtk2/nsWindow.cpp&rev=1.113&mark=2110-2114#2101

Comment 24

[Karl Tomlinson (:karlt)]

Attachment: remove code to give transient-for-none dialogs a separate ICCCM group leader

Rather than rearrange code to set the event mask before the widget is
realized, which would make it messier, I'd like to remove the code added in
bug 194323.  The change there was a questionable solution.  There may well be
dialogs that really are app-wide dialogs if they are not transient for a
particular window and those dialogs should behave like similar dialogs in
other apps.

The code is not needed for the Profile Manager dialog because it is the only
Adam window, with its dependent (transient for) dialogs.

The code is also no longer needed for bug 194323 because Preferences is a
normal (not dialog nor transient) window in Nightly.  It was also not needed
in Firefox 17 (and I don't know how many other versions) because there the
Preferences window is a dialog transient for the its parent.

Comment 25

[Karl Tomlinson (:karlt)]

Attachment: remove mWindowGroup, handled by gtk_window_set_transient_for

We can actually remove quite a bit more code.

This GtkWindowGroup code is not the same as setting the ICCCM group leader though
https://bugzilla.gnome.org/show_bug.cgi?id=59724 proposes making
GtkWindowGroups affect the group leader.

As pointed out in comment 6 there, gtk_window_set_transient_for() handles
GtkWindowGroups for us.

Comment 26

[Karl Tomlinson (:karlt)]

Attachment: remove unnecessary mTransientParent

and some more.

Comment 27

[George R. Goffe]

I'm using the session manager add on and am experiencing the mouse event(s) missing problem. I have to double click on items in the menu or buttons.

Comment 28

[Karl Tomlinson (:karlt)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fa77c707befa
https://hg.mozilla.org/integration/mozilla-inbound/rev/6a0204462838
https://hg.mozilla.org/integration/mozilla-inbound/rev/8ed517f540d1

Comment 29

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/fa77c707befa
https://hg.mozilla.org/mozilla-central/rev/6a0204462838
https://hg.mozilla.org/mozilla-central/rev/8ed517f540d1

Comment 30

[Karl Tomlinson (:karlt)]

Comment on attachment 696673 [details] [diff] [review]
remove code to give transient-for-none dialogs a separate ICCCM group leader

[Approval Request Comment]
Bug caused by (feature/regressing bug #): interaction between bug 793501 changes and oxygen-gtk theme.

User impact if declined: Users with the oxygen-gtk theme, perhaps the default in some KDE distributions, cannot use the mouse in some less common dialogs.

Testing completed (on m-c, etc.): on m-c.
Risk to taking this patch (and alternatives if risky): Moderate to high likelihood of risk, but any problems are probably minor.  If there could be some independent dialogs that we haven't considered, then they will be above all normal windows under some window managers.  That may be the intended behavior but could be a problem if the dialog wants to open a normal window, which would open under the dialog in some window managers.

String or UUID changes made by this patch: none.

Comment 31

[Alex Keybl [:akeybl]]

(In reply to Karl Tomlinson (:karlt) from comment #30)
> Testing completed (on m-c, etc.): on m-c.
> Risk to taking this patch (and alternatives if risky): Moderate to high
> likelihood of risk, but any problems are probably minor.  If there could be
> some independent dialogs that we haven't considered, then they will be above
> all normal windows under some window managers.  That may be the intended
> behavior but could be a problem if the dialog wants to open a normal window,
> which would open under the dialog in some window managers.

We're going to let this change bake on Nightly for a little while longer, and consider uplift for FF19 Beta 2. If this behavior can be worked around by double clicking, and we're concerned about risk, we may choose to relnote for FF19.

Comment 32

[George R. Goffe]

There are various processes within FF that double clicking do not work (note 27). The second click indicates selection in these.

Comment 33

[Karl Tomlinson (:karlt)]

Double clicking is enough to work around for some actions in the profile manager, if trying to select a profile, double clicking will automatically start with the selected profile.

To rename or delete a profile, the arrow keys need to be used.

There may be other issues in different dialogs from extensions or other apps.

There should always be a way to use the keyboard (tab, ctrl-arrow i guess), but users may not think of these.

I'd prefer to get this on Beta early, to get maximum testing, if we are going to have it in FF19 at all.
Perhaps Beta 2 is early enough.  I don't know when that will be.

Comment 34

[George R. Goffe]

I'm afraid I misspoke with my earlier comment. The sessionmanager addon works fine now as well as the profile prompt at startup. Please accept my apologies.

George...

Comment 35

[u279076]

Thanks George. Just to confirm, both the Profile Manager and the SessionManager Addon work for you now with the latest Firefox Nightly?

Comment 36

[George R. Goffe]

Anthony,

Yes they sure do. I typically do an UPDATE EVERY night or whenever a newer version is released.

Thanks for all your (and others) hard work AND for checking on this.

Regards,

George...

Comment 37

[u279076]

Thank you George for you help testing this bug.

Comment 38

[bhavana bajaj [:bajaj]]

Comment on attachment 696673 [details] [diff] [review]
remove code to give transient-for-none dialogs a separate ICCCM group leader

Approving on beta based on comment# 33 and considering the verification we have got on this issue.

Comment 39

[Karl Tomlinson (:karlt)]

https://hg.mozilla.org/releases/mozilla-beta/rev/911573624801

Comment 40

[u279076]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #37)
> Thank you George for you help testing this bug.

Forgot to set the status flag.