7.99 KB, text/plain
1.71 KB, patch
|Details | Diff | Splinter Review|
7.59 KB, patch
|Details | Diff | Splinter Review|
4.68 KB, patch
|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.
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.
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.
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.
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.
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.
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.
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
I'm running on a Fedora x86_64 system that's up to date as of a few minutes 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.
Component: Profile: BackEnd → Startup and Profile System
Product: Core → Toolkit
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?
Does this reproduce with -safe-mode?
Debug builds are available from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-12-25-mozilla-aurora-debug/ for example.
> 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
(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.
(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
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
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
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)
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)
and some more.
Attachment #696675 - Flags: review?(roc)
Attachment #696673 - Flags: review?(roc) → review+
Attachment #696674 - Flags: review?(roc) → review+
Attachment #696675 - Flags: review?(roc) → review+
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.
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
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: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
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?
Attachment #696673 - Flags: approval-mozilla-aurora? → approval-mozilla-beta?
(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.
There are various processes within FF that double clicking do not work (note 27). The second click indicates selection in these.
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.
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...
Thanks George. Just to confirm, both the Profile Manager and the SessionManager Addon work for you now with the latest Firefox Nightly?
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...
Thank you George for you help testing this bug.
Status: RESOLVED → VERIFIED
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+
Whiteboard: [c-n m-beta approved patch only]
(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.