Bug 742658 - Buttons in Qt applications (both KDE Platform and Qt-only) not clickable when run under gnome-shell
Summary: Buttons in Qt applications (both KDE Platform and Qt-only) not clickable when...
Alias: None
Product: Fedora
Classification: Fedora
Component: qt
Version: 16
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker
: 737417 747107 (view as bug list)
Depends On:
Blocks: qt-4.8
TreeView+ depends on / blocked
Reported: 2011-10-01 00:04 UTC by Tom Horsley
Modified: 2013-10-04 12:28 UTC (History)
23 users (show)

Fixed In Version: qt-4.8.0-0.17.rc1.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-20 07:42:41 UTC
Type: ---

Attachments (Terms of Use)
bzipped tar file (1.98 KB, application/octet-stream)
2011-10-03 23:26 UTC, Tom Horsley
no flags Details
LD_PRELOAD library for dumping X events (4.02 KB, application/octet-stream)
2011-10-15 20:48 UTC, Tom Horsley
no flags Details
Trace from running app under gnome3 (16.83 KB, text/plain)
2011-10-15 20:51 UTC, Tom Horsley
no flags Details
similar trace from running in KDE Plasma session (7.06 KB, text/plain)
2011-10-15 20:53 UTC, Tom Horsley
no flags Details
Patch (not yet compile tested) (2.89 KB, patch)
2011-10-17 21:33 UTC, Owen Taylor
no flags Details | Diff
Patch (4.14 KB, patch)
2011-10-18 03:47 UTC, Owen Taylor
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Qt Bug Tracker QTBUG-21900 0 None None None Never

Description Tom Horsley 2011-10-01 00:04:56 UTC
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

Version-Release number of selected component (if applicable):

How reproducible:
every time

Steps to Reproduce:
1.see above
Actual results:
clicking on buttons does nothing

Expected results:
clicking on buttons works

Additional info:

Comment 1 Kevin Kofler 2011-10-01 00:14:13 UTC
According to:
this also happens with other apps. Probably a Qt 4.8 regression.

Comment 2 Tom Horsley 2011-10-01 00:25:46 UTC
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?

Comment 3 Clyde E. Kunkel 2011-10-01 01:26:53 UTC
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 
k3b(3157)/kdeui (kdelibs): Attempt to use QAction "view_contents" with 
k3b(3157)/kdeui (kdelibs): Attempt to use QAction "location_bar" with 
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.

Comment 4 Kevin Kofler 2011-10-01 01:29:28 UTC
*** Bug 737417 has been marked as a duplicate of this bug. ***

Comment 5 Kevin Kofler 2011-10-01 01:30:56 UTC
Does this also happen with Qt-only applications?

Comment 6 Kevin Kofler 2011-10-01 01:32:14 UTC
(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.)

Comment 7 Tom Horsley 2011-10-01 01:41:14 UTC
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 :-).

Comment 8 Tom Horsley 2011-10-01 01:45:24 UTC
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.

Comment 9 Rex Dieter 2011-10-01 16:24:42 UTC
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:

and, some examples of those that exhibit the symptoms described here:

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.
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.

Comment 10 Rex Dieter 2011-10-01 16:40:15 UTC
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.

Comment 11 Tom Horsley 2011-10-01 17:36:55 UTC
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 :-).

Comment 12 Tom Horsley 2011-10-03 23:26:24 UTC
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.

Comment 13 Tom Horsley 2011-10-06 01:28:30 UTC
In case anyone was wondering, today's update with qt-4.8.0-0.12.20111002.fc16.x86_64 did not fix this problem.

Comment 14 Kevin Kofler 2011-10-06 06:09:06 UTC
Yes, we know that this is still broken. :-( Rex Dieter already tested this when he did the snapshot.

Comment 15 Kevin Kofler 2011-10-06 06:09:54 UTC
Is there already a bug filed at the upstream Qt bug tracker?

Comment 16 Adam Williamson 2011-10-07 18:48:41 UTC
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.

Comment 17 Kevin Kofler 2011-10-07 18:53:23 UTC
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.

Comment 18 Tom Horsley 2011-10-07 19:03:59 UTC
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.

Comment 19 Adam Williamson 2011-10-07 22:32:11 UTC
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.

Comment 20 Tom Horsley 2011-10-07 22:42:42 UTC
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?

Comment 21 Kevin Kofler 2011-10-08 00:25:39 UTC
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.

Comment 22 Tom Horsley 2011-10-08 03:06:56 UTC
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:


Comment 23 Adam Williamson 2011-10-08 05:12:43 UTC
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!)

Comment 24 Tom Horsley 2011-10-09 16:22:23 UTC
> 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.

Comment 25 Rex Dieter 2011-10-09 16:37:43 UTC
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.  


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?

Comment 26 Tom Horsley 2011-10-09 19:15:21 UTC
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:


Comment 27 Rex Dieter 2011-10-09 22:33:28 UTC
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.

Comment 28 Tom Horsley 2011-10-09 22:37:58 UTC
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?

Comment 29 Rex Dieter 2011-10-09 22:43:23 UTC
Cc'ding gnome-shell owner (otaylor), any advice, comment, feedback here? (esp in response to comment #28 )?

Comment 30 Tom Horsley 2011-10-09 22:44:10 UTC
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.

Comment 31 Tom Horsley 2011-10-09 22:54:44 UTC
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.

Comment 32 Rex Dieter 2011-10-09 23:07:49 UTC
OK, enough for me, reassigning officially to gnome-sheel for comment/feedback.

Comment 33 Tom Horsley 2011-10-09 23:59:37 UTC
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.

Comment 34 Rex Dieter 2011-10-10 12:54:35 UTC
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...)

Comment 35 Andy Grimm 2011-10-11 17:01:08 UTC
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.

Comment 36 Victor Rehorst 2011-10-11 18:32:34 UTC
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.

Comment 37 Kevin Kofler 2011-10-15 19:25:50 UTC
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?

Comment 38 Rex Dieter 2011-10-15 19:32:51 UTC
In my own testing with qt-4.8, no value for
QT_GRAPHICSSYETEM or QT_NO_GLIB made a difference

Comment 39 Tom Horsley 2011-10-15 20:21:29 UTC
I also see no change with any of the QT_GRAPHICSSYSTEM settings.

Comment 40 Tom Horsley 2011-10-15 20:48:07 UTC
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.

Comment 41 Tom Horsley 2011-10-15 20:51:11 UTC
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.

Comment 42 Tom Horsley 2011-10-15 20:53:33 UTC
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?" :-).

Comment 43 Tom Horsley 2011-10-15 21:41:24 UTC
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.

Comment 44 Tom Horsley 2011-10-15 21:55:30 UTC
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.

Comment 45 Adam Williamson 2011-10-17 19:07:02 UTC
has anyone checked if this affects running Qt apps under non-GNOME GTK+ environments - e.g. Xfce?

Comment 46 Rex Dieter 2011-10-17 19:15:01 UTC
xfce in particular was fine, when I tested it.

Comment 47 Dan Winship 2011-10-17 19:17:38 UTC
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?

Comment 48 Dan Winship 2011-10-17 19:18:17 UTC
mmm... actually, you'll need to log out and log back in after changing that

Comment 49 Andy Grimm 2011-10-17 19:24:43 UTC
Yes, Dan, that worked for me.  Thanks.

Comment 50 Rex Dieter 2011-10-17 19:28:20 UTC
Yes! problem gone after setting attach_modal_dialogs to false

Comment 51 Adam Williamson 2011-10-17 20:01:11 UTC
Jasper St. Pierre reports that this patch:


'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.

Comment 52 Owen Taylor 2011-10-17 20:11:02 UTC
If it's accurate this has to do with Qt's configure event handling, it almost certainly has to do with the two commits:


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.

Comment 53 Owen Taylor 2011-10-17 21:12:40 UTC
OK, think I understand the root cause, it's a logic bug in Qt - if we look at:


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


all sitting in the queue, then Qt trusts the position in the ConfigureEvent even though it is not allowed to trust the position.

Comment 54 Adam Williamson 2011-10-17 21:27:20 UTC
assigning back to qt4, then, thanks Owen. I guess this should also be reported upstream to Qt, if it hasn't been already.

Comment 55 Owen Taylor 2011-10-17 21:33:16 UTC
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.

Comment 56 Tom Horsley 2011-10-17 22:19:06 UTC
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.

Comment 57 Kevin Kofler 2011-10-18 03:28:46 UTC
> 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. ;-)

Comment 58 Owen Taylor 2011-10-18 03:47:03 UTC
Created attachment 528698 [details]

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


Comment 59 Kevin Kofler 2011-10-18 03:53:57 UTC
Comment on attachment 528657 [details]
Patch (not yet compile tested)

Marking the old version of the patch as obsolete.

Comment 60 Rex Dieter 2011-10-18 12:29:47 UTC
Thanks!  I'll take care of it.

Comment 61 Fedora Update System 2011-10-18 14:04:28 UTC
qt-4.8.0-0.17.rc1.fc16 has been submitted as an update for Fedora 16.

Comment 62 Rex Dieter 2011-10-18 14:18:09 UTC
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!

Comment 63 Bill Nottingham 2011-10-18 20:24:47 UTC
*** Bug 747107 has been marked as a duplicate of this bug. ***

Comment 64 Fedora Update System 2011-10-20 04:03:06 UTC
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.

Comment 65 Adam Williamson 2011-11-08 06:15:43 UTC

Fedora Bugzappers volunteer triage team

Comment 66 Red Hat Bugzilla 2013-10-04 00:21:03 UTC
Removing external tracker bug with the id '21900' as it is not valid for this tracker

Note You need to log in before you can comment on or make changes to this bug.