Bug 742658

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