Closed
Bug 821749
Opened 12 years ago
Closed 12 years ago
Profile manager UI does not respond to mouse button press with oxygen-gtk
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
VERIFIED
FIXED
mozilla20
Tracking | Status | |
---|---|---|
firefox18 | --- | unaffected |
firefox19 | + | verified |
People
(Reporter: aleth, Assigned: karlt)
References
Details
(Keywords: regression)
Attachments
(4 files)
7.99 KB,
text/plain
|
Details | |
1.71 KB,
patch
|
roc
:
review+
bajaj
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
7.59 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
4.68 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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.
Updated•12 years ago
|
tracking-firefox19:
--- → ?
Keywords: regression
Reporter | ||
Comment 3•12 years ago
|
||
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•12 years ago
|
||
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.
status-firefox18:
--- → unaffected
status-firefox19:
--- → affected
Keywords: qawanted,
regressionwindow-wanted
QA Contact: anthony.s.hughes
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.
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•12 years ago
|
||
Anthony:
the KDE systeminformation from a dupe
https://bug818192.bugzilla.mozilla.org/attachment.cgi?id=688368
(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.
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•12 years ago
|
||
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•12 years ago
|
||
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.
Keywords: qawanted,
regressionwindow-wanted
Comment 12•12 years ago
|
||
Comment 13•12 years ago
|
||
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.
Assignee: nobody → karlt
Comment 14•12 years ago
|
||
I'm running on a Fedora x86_64 system that's up to date as of a few minutes ago.
Comment 15•12 years ago
|
||
(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.
Updated•12 years ago
|
Component: Profile: BackEnd → Startup and Profile System
Product: Core → Toolkit
Assignee | ||
Comment 16•12 years ago
|
||
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?
Assignee | ||
Comment 17•12 years ago
|
||
Does this reproduce with -safe-mode?
Assignee | ||
Comment 18•12 years ago
|
||
Debug builds are available from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-12-25-mozilla-aurora-debug/ for example.
Comment 19•12 years ago
|
||
> 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
Assignee | ||
Comment 20•12 years ago
|
||
(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•12 years ago
|
||
(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
Assignee | ||
Comment 22•12 years ago
|
||
Thanks, I can reproduce here with oxygen-gtk 1.3.1.
Summary: Profile manager UI is broken when used with the mouse → Profile manager UI does not respond to mouse button press with oxygen-gtk
Assignee | ||
Comment 23•12 years ago
|
||
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
Assignee | ||
Comment 24•12 years ago
|
||
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.
Attachment #696673 -
Flags: review?(roc)
Assignee | ||
Comment 25•12 years ago
|
||
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.
Attachment #696674 -
Flags: review?(roc)
Assignee | ||
Updated•12 years ago
|
Attachment #696675 -
Attachment description: remove unnecessary mTransientFor → remove unnecessary mTransientParent
Attachment #696675 -
Attachment filename: remove.mTransientFor → remove.mTransientParent
Attachment #696673 -
Flags: review?(roc) → review+
Attachment #696674 -
Flags: review?(roc) → review+
Attachment #696675 -
Flags: review?(roc) → review+
Comment 27•12 years ago
|
||
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.
Assignee | ||
Comment 28•12 years ago
|
||
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
Flags: in-testsuite-
Comment 29•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/fa77c707befa
https://hg.mozilla.org/mozilla-central/rev/6a0204462838
https://hg.mozilla.org/mozilla-central/rev/8ed517f540d1
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Assignee | ||
Comment 30•12 years ago
|
||
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.
Attachment #696673 -
Flags: approval-mozilla-aurora?
Assignee | ||
Updated•12 years ago
|
Attachment #696673 -
Flags: approval-mozilla-aurora? → approval-mozilla-beta?
Comment 31•12 years ago
|
||
(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•12 years ago
|
||
There are various processes within FF that double clicking do not work (note 27). The second click indicates selection in these.
Assignee | ||
Comment 33•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
Thanks George. Just to confirm, both the Profile Manager and the SessionManager Addon work for you now with the latest Firefox Nightly?
Comment 36•12 years ago
|
||
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•12 years ago
|
||
Thank you George for you help testing this bug.
Status: RESOLVED → VERIFIED
Comment 38•12 years ago
|
||
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.
Attachment #696673 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Assignee | ||
Updated•12 years ago
|
Keywords: checkin-needed
Whiteboard: [c-n m-beta approved patch only]
Assignee | ||
Comment 39•12 years ago
|
||
Keywords: checkin-needed
Whiteboard: [c-n m-beta approved patch only]
Comment 40•12 years ago
|
||
(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.
You need to log in
before you can comment on or make changes to this bug.
Description
•