Description of problem: Run a game like same-game (klickety) or Shisen-Sho in a gnome 3 session. Play till you actually finish, and a dialog pops up with top scores and a "Remember" and "Forget" button. Clicking "Remember" or "Forget" with the mouse does nothing. Hitting enter on the keyboard does act like you clicked "Remember", so you can get out of this apparently stuck state. Start a Yclept KDE Plasma Desktop session and play the same games in there, and the remember and forget buttons are clickable and seem to function correctly. Version-Release number of selected component (if applicable): kdegames-4.7.1-1.fc16.x86_64 How reproducible: every time Steps to Reproduce: 1.see above 2. 3. Actual results: clicking on buttons does nothing Expected results: clicking on buttons works Additional info:
According to: http://lists.fedoraproject.org/pipermail/kde/2011-September/010306.html this also happens with other apps. Probably a Qt 4.8 regression.
Yea, I was just noticing that. I think this is also the same as bug 737417. I figured out I can tab through the buttons with the keyboard and hit space and that works. The interesting question is, why the heck do the mouse buttons work fine in a KDE Plasma session. You'd think if Qt 4.8 screwed up mouse events, they'd be screwed up no matter which desktop you were running. It also appears to be only the buttons in dialogs which are hosed. The button in the main application work fine. I wonder if Qt is putting some strange and wondrous windows hints on dialogs which doesn't play well with the gnome 3 window management?
I see the same behavior in both rawhide and F16 when using k3b from the gnome shell. You can select a button, but have to hit the enter key to activate the button's action. Here is what shows up on the gnome terminal during a k3b session: [kunkelc@P5K-EWIFI <17> ~]$ k3b QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3400004 specified for 0x3400013 (k3b). [kunkelc@P5K-EWIFI <17> ~]$ k3b(3157)/kdeui (kdelibs): Attempt to use QAction "view_projects" with KXMLGUIFactory! k3b(3157)/kdeui (kdelibs): Attempt to use QAction "view_dir_tree" with KXMLGUIFactory! k3b(3157)/kdeui (kdelibs): Attempt to use QAction "view_contents" with KXMLGUIFactory! k3b(3157)/kdeui (kdelibs): Attempt to use QAction "location_bar" with KXMLGUIFactory! UPnP device entered: "uuid:64f219fe-ffcd-f732-9957-a760c5d287c4" UPnP device entered: "uuid:522699cc-a7c9-41b0-8473-398d53c66343" UPnP device entered: "uuid:74da16bf-0147-86fc-346d-7c813842c420" QCoreApplication::postEvent: Unexpected null receiver<--when k3b killed.
*** Bug 737417 has been marked as a duplicate of this bug. ***
Does this also happen with Qt-only applications?
(According to bug #737417, this affects Qt-only applications at least when the KDE plugins are getting loaded. I guess trying without kdelibs installed is the only way to test a completely non-KDE environment.)
This definitely seems to be something Qt 4.8 is doing. If I boot back to fedora 15, then use LD_LIBRARY_PATH to point at the /fedora16 partition, running a KDE app from /fedora16/usr/bin in a fedora 15 gnome 3 session also results in mouse clicks in dialogs not working. Conversely, if I boot fedora 16 and point LD_LIBRARY_PATH at /fedora15 libraries and run the f15 version of a KDE app in a fedora 16 gnome 3 session, the mouse clicks in dialogs seem to work fine. So, the questions are: What is Qt 4.8 doing different? and Why is only gnome-shell having problems? (I tried several other window managers and desktops, and none of them had any problem clicking buttons in dialogs of KDE apps). I tried getting info with xwininfo to see if I could see anything different between Qt versions, but didn't notice anything obvious. I anticipate a long drawn out ambiguous standards interpretation war between Qt and Gnome once someone finds out what the difference actually is :-).
I ran a plain Qt app under strace and got the same dialog button problem and did not see anything obviously kde specific loaded in the strace output (at least no .so files with kde as part of the name), so I think it does indeed happen in pure Qt programs.
Tested on f15 (with kde-4.7.1 + qt-4.8.0 from kde47/kde-unstable repos), and here's what I've found so far. Only *some* apps misbehave, examples of ones that work ok: amarok juk konqueror konsole marble yakuake and, some examples of those that exhibit the symptoms described here: digikam gwenview k3b mixed results kstars: startup wizard fails, but other dialogs (like settings->configure kstars ok) For "misbehaving apps" I often (but not always see one or both messages such as the following in ~/.xsession-errors): QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. and: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x2000004 specified for 0x200003d (digikam). Window manager warning: Invalid WM_TRANSIENT_FOR window 0x2000004 specified for 0x2000013 (k3b). Window manager warning: Invalid WM_TRANSIENT_FOR window 0x2c00004 specified for 0x2c00012 (kstars). Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3c00004 specified for 0x3c00012 (kstars). Window manager warning: Log level 16: STACK_OP_RAISE_ABOVE: sibling window 0x3c00012 not in stack Note too, I did tests using now explicit --style option (which ends up using gtkstyle), and explicitly setting --style oxygen . All testing results were the same Now, for giggles, I'll revert qt-4.8.0 -> qt-4.7.4, and retry the tests.
With qt-4.7.4, those "misbehaving" ones, worked ok again, though * still had all the same "Window manager warning" messages in ~/.xsession-errors * the "QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave." ones do not appear (though this may well be a new warning introduced in qt-4.8) So, all-in-all, confirms this is in some way specific to qt48 somehow.
I've been playing around with xprop and xwininfo -all to try and find anything different about the way the window describes itself to the window manager, and I haven't spotted a single difference between f15 and f16 yet. In particular the windows seem to have the same event masks - no one is throwing away button release events :-).
Created attachment 526155 [details] bzipped tar file OK, I wrote this silly library you can LD_PRELOAD to trace incoming X events. I have verified that both ButtonPress and ButtonRelease events are indeed getting into the Qt program. Why they don't result in a button click is a total mystery at this point.
In case anyone was wondering, today's update with qt-4.8.0-0.12.20111002.fc16.x86_64 did not fix this problem.
Yes, we know that this is still broken. :-( Rex Dieter already tested this when he did the snapshot.
Is there already a bug filed at the upstream Qt bug tracker?
Discussed at the 2011-10-07 blocker review meeting. Agreed this is rejected as a blocker: as no default apps on a Desktop install are Qt-based, and this bug doesn't happen in KDE, it doesn't meet any criteria. KDE team, I'm afraid you might have to finesse your blockers a bit, as we can't leave this in a state where it blocks F16Blocker - so this either has to come off the Qt tracker, or the Qt tracker can't block F16Blocker any more.
I think you might have to finesse your blocker criteria a bit. It's just not possible to ship a release where you cannot run Qt apps (at least a random subset) under GNOME.
I'm with Kevin on this. There are Qt apps available to run from the menus that you can access from top left corner in a gnome 3 session. If apps that can be launched by gnome 3 in the normal course of events don't run, that sure seems like it ought to be a blocker to me.
Tom: but not in a default install, and that's all we require in the criteria. We don't require $ANY_OLD_APP in the repos to work by default. We don't even require $ANY_OLD_APP to *run* by default. I'm quite sure we've shipped at least one app that doesn't run usefully in every single Fedora release; we can't make 'any app you try and run should work' a criterion, it's just not practical. The criterion we settled on is 'apps present in default installs of the release blocking desktops should work' - i.e. all the apps you get when you do a default KDE install should work in KDE, and all the apps you get when you do a default GNOME install should work in GNOME. This bug does not violate that criterion, hence it is not a blocker.
OK, so you can go all nit-picky and say the official release criteria lawyer rules have not been violated. Or you can say: You know, zillions of people use things like k3b because it works better than any of the gnome apps, do we really want to enrage all these folks by releasing a product we know is broken? Shouldn't there be a "Wait a minute, this is dumb" release criteria that can override any of the others for things no one happened to think of and enumerate in detail beforehand?
So, to elaborate on my previous message: * The point of the qt-4.8 tracker is to collect any issues caused by Qt 4.8, i.e. regressions from 4.7. Those are not necessarily release blockers, so I guess qt-4.8 should indeed not block F16Blocker-kde. * However, I think this particular bug should be treated as a blocker. We're going to get really bad press if K3b and Digikam don't work in GNOME. * But to have any chance of getting this fixed by F16, we need upstream to know about this. So let me reiterate comment #15: Is there already a bug filed at the upstream Qt bug tracker? If not, please file one.
Well, the dashboard search facility utterly defeats me, so I couldn't tell if an existing report of the same problem exists (though I did see bugs saying mouse events are broken on the mac in OS X, possibly the same problem). Anyway, I filed this bug: https://bugreports.qt.nokia.com/browse/QTBUG-21900
Tom: it's not mindless rule-chasing. We adjust the criteria when it seems appropriate. But this doesn't seem appropriate: it's just not a significant enough impact. There's lots of other ways to get what you need to do done. One helpful way to look at issues like this is - is it overall better for people if we release the product on time and release an update that fixes it a week later, or better if we delay the entire product a week? People who would suffer from this bug will get a working product at exactly the same point in time either way... (A bug not being a release blocker does not, of course, mean it won't be fixed in the release. It means we won't hold the release to fix it. No-one's going to complain if you fix it!)
> People who would suffer from this bug will get a working product at exactly the > same point in time either way... Except for the people who would have had a working release but they upgraded from f15 under the impression that a released f16 means f16 is working :-). I don't really have a personal stake in this, I despise both gnome and kde and switch to fvwm as soon as I can after the install, but if you think it is a perfectly wonderful idea to give an even larger crowd of people even more reasons to hate gnome 3, then by all means go ahead with a broken release.
A personal request, please keep comments *here* focused on the technical aspects of the bug. The rest is noise that makes it harder to track and find the important information required to fix this. Thanks. Now, I'll try adding some information to the upstream tracker and hopefully try to find a pure-Qt reproducer (all the apps I've tried so far are kde ones). any suggestions?
There are a slew of Qt examples in the Qt source trees. I'm pretty sure one or more of them ought to have an example of a printing app. The Qt print dialog seems to be one that consistently has the problem. If there isn't a simpler example app, my "kewpie" program exhibits the problem in the printer dialog: http://home.comcast.net/~tomhorsley/software/kewpie/kewpie.html
OK, simplest Qt only test-case so far, qtconfig-qt4, make any change, on quit, the "Save changes to settings: Cancel, No, Yes" dialog fails.
So, I'm trying various things in gdb with qt debuginfo installed, and I just found a very interesting fact: If I click on one of the problem buttons which doesn't get clicked(), I actually do get into the QAbstractButton::mousePressEvent() and QAbstractButton::mouseReleaseEvent() code, so the events are making it all the way to the button, but then if I step through the code (which is a little confusing because the optimizer interleaves instructions from different lines), I think it does the test if (hitButton(e->pos())) { and that test fails, and it goes into the else case which calls e->ignore(); Window manager and Qt not on the same page with event x,y coordinate translations maybe?
Cc'ding gnome-shell owner (otaylor), any advice, comment, feedback here? (esp in response to comment #28 )?
Woa! If I step into the hitButton() test, I see this nonsense: 1033 return rect().contains(pos); (gdb) p rect() $2 = {x1 = 0, y1 = 0, x2 = 84, y2 = 30} (gdb) p pos $3 = (const QPoint &) @0x7fffffffb7e8: {xp = 1123, yp = 115} That rect looks like a rectangle relative to the top left corner of the button itself, but that xp and yp look like the absolute screen coordinates of the mouse.
And now, debugging the same button click in the same button, but when running under KDE Plasma, in the QAbstractButton::hitButton routine again I see: 1033 return rect().contains(pos); (gdb) p rect() $1 = {x1 = 0, y1 = 0, x2 = 90, y2 = 24} (gdb) p pos $2 = (const QPoint &) @0x7fffffffb538: {xp = 49, yp = 10} So it sure looks like something screws up the event position info when running under gnome 3.
OK, enough for me, reassigning officially to gnome-sheel for comment/feedback.
Another interesting clue: I see some big differences in the Qt 4.7 versus 4.8 source code in the vicinity of the code that is keeping window position rectangles computed on configure, resize, move type operations. If I bring up a dialog that doesn't work, click a button and watch it not work, then grab the dialog and move it, the next button click works :-). Something about the initial window configuration messes up Qt's internal idea of the coordinates, but if you move the window, Qt gets back in sync with reality.
Tom, mind adding some (esp the recent information) into the upstream bug you already opened? (I'd hope your investigative insight could help those more familiar with the code find the cause and a solution...)
I ran into this over the weekend with a Qt-only app I was attempting to package (Quackle). If you need any data points from me on this, let me know.
This bug is tickling me as I run gnome3, but my favourite editor is kate. A workaround that fixes the problem on a per-dialog basis is to drag the corner of the dialog a bit to re-size it. That seems to reset whatever is messed up.
Does this also happen if you run the application with: QT_GRAPHICSSYSTEM=native applicationname ? And what if you run it with: QT_GRAPHICSSYSTEM=raster applicationname under Qt 4.7.x?
In my own testing with qt-4.8, no value for QT_GRAPHICSSYETEM or QT_NO_GLIB made a difference
I also see no change with any of the QT_GRAPHICSSYSTEM settings.
Created attachment 528349 [details] LD_PRELOAD library for dumping X events Here's a newer version of my library to use with LD_PRELOAD to dump all the X events. This one prints more details of events related to window position and button presses.
Created attachment 528350 [details] Trace from running app under gnome3 Here's a trace of the X events generated when running my "kewpie" Qt app under gnome 3, popping up the Qt print dialog and trying to press the Cancel button. I'm not entirely certain there is any relevant information here, but I am suspicious of the window size and position in the ConfigureNotify event generated when the printer dialog is popped up.
Created attachment 528351 [details] similar trace from running in KDE Plasma session For comparison, here are the similar events generated by the trace when running the same program under KDE Plasma. In this case, once I try to push the cancel button the printer dialog really goes away, so things are considerably different after that. The real question is "What the heck is different before that?" :-).
OK, if I poke around in the traces, I see the gnome 3 trace has a slew of ConfigureNotify events, but none of them for the print dialog (window ID 0x2000017) ever says send_event TRUE. The last event does have the correct x,y,width,height info (according to xwininfo): Call XCheckTypedWindowEvent window=0x2000017 type=ConfigureNotify return event type=ConfigureNotify serial=447, send_event=FALSE, event=0x2000017, window=0x2000017, x=10, y=18, width=410, height=217, border_width=0, above=0x0, override_redirect=FALSE returns True I see lots of code in the Qt libraries dealing with ConfigureNotify looking for send_event == TRUE and ignoring them otherwise. If I look in the events that happen running under KDE, I see one ConfigureNotify with send_event == FALSE, followed by a ConfigureNotify with send_event == TRUE: Call XCheckTypedWindowEvent window=0x380004f type=ConfigureNotify return event type=ConfigureNotify serial=911, send_event=TRUE, event=0x380004f, window=0x380004f, x=112, y=287, width=391, height=178, border_width=0, above=0x0, override_redirect=FALSE returns True and the info in that event seems to have the correct window geometry. So my conclusion is that gnome-shell isn't ever telling Qt anything about the print dialog, and Qt isn't handling that lack of information very well. But that's just a theory based on a really fuzzy idea of what might be going on in Qt innards.
On the other hand, that may all be complete nonsense. I just hacked my preload library to set send_event TRUE in that final configure notify, and there was no change in behavior. The other mysterious thing I see in gnome-shell and not in KDE is the weird intermediate window 0x200000f that does have a send_event TRUE and seems to be created just before the printer dialog 0x2000017. (Though maybe 0x200000f is the File menu window). I don't see any interactions with an extra window like that in the same vicinity of events from the KDE trace.
has anyone checked if this affects running Qt apps under non-GNOME GTK+ environments - e.g. Xfce?
xfce in particular was fine, when I tested it.
If you do gconftool-2 -s /desktop/gnome/shell/windows/attach_modal_dialogs -t boolean false before starting the app, does the problem go away?
mmm... actually, you'll need to log out and log back in after changing that
Yes, Dan, that worked for me. Thanks.
Yes! problem gone after setting attach_modal_dialogs to false
Jasper St. Pierre reports that this patch: http://fpaste.org/cu3j/raw/ 'fixes' the bug, which proves that it's the lack of a configure event that triggers the bug. Owen Taylor reckons that the window manager is not actually required to send a configure event in this case: Qt should cope correctly with there being no event. He says Qt does attempt to handle this correctly but he believes there's a bug there, which he's currently looking into.
If it's accurate this has to do with Qt's configure event handling, it almost certainly has to do with the two commits: http://qt.gitorious.org/qt/qt/commit/cdd776a91e65bf5c30cea1bab9823134a3f797d0 http://qt.gitorious.org/qt/qt/commit/ed4c28b08412211bf547340a05ca4bd987b4fbf7 Where in the first one, Qt starting relying on it's ability to track the root window position, and the second is a fix to try and work with/work around various window managers. Would be interesting, perhaps, to build a Qt with those two commits omitted and check. It's hard for me to say with certainty whether there's a Mutter/Metacity bug here or not - it's possible that we're missing some case where we are supposed to send synthetic notify events in Mutter for attached dialogs, though we're not required to send synthetic notify events as long as we are sending real notify events.
OK, think I understand the root cause, it's a logic bug in Qt - if we look at: QETWidget::translateConfigEvent It has: bool trust = isVisible() && (d->topData()->parentWinId == XNone || d->topData()->parentWinId == QX11Info::appRootWindow()); Saying that we can trust the position in non-synthetic configure events for windows which _have not been reparented_ - the parent window ID is unset or the root window. That's fine - but the problem is that the tracking of parentWindowId is done in normal event handling, but Qt gets ConfigureEvent it "peeks ahead" in the window queue: while (XCheckTypedWindowEvent(X11->display, internalWinId(), ConfigureNotify, &otherEvent)) { and looks for other configure events - _ignoring intermediate reparent events_ - and those reparent events might contain information that would invalidate the value of 'trust'. So, if we get ConfigureEvent ReparentEvent ConfigureEvent all sitting in the queue, then Qt trusts the position in the ConfigureEvent even though it is not allowed to trust the position.
assigning back to qt4, then, thanks Owen. I guess this should also be reported upstream to Qt, if it hasn't been already.
Created attachment 528657 [details] Patch (not yet compile tested) To save duplicate work, attaching a patch I came up with, trying to build a local RPM to test, but will take a while.
I added a note to the upstream bug pointing at comment 53. It is no wonder I never had any luck with my debugging - that looks like a pretty complicated case, I'm glad someone was able to figure it out.
> assigning back to qt4, then, thanks Owen. Please use qt as the component next time, not qt4. Orphan Owner is not a good bug assignee. ;-)
Created attachment 528698 [details] Patch Here's a tested, working patch. Would appreciate if people would take care of: - Updating the upstream bug to point to this - Getting the patch into Fedora Thanks!
Comment on attachment 528657 [details] Patch (not yet compile tested) Marking the old version of the patch as obsolete.
Thanks! I'll take care of it.
qt-4.8.0-0.17.rc1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/FEDORA-2011-14348
tested things out for about 10 minutes in all the known-trouble maker qt/kde apps under gnome shell, and it looks like a have a wiener! Owen rocks the mustard. relish the victory!
*** Bug 747107 has been marked as a duplicate of this bug. ***
qt-4.8.0-0.17.rc1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Removing external tracker bug with the id '21900' as it is not valid for this tracker