GNOME Bugzilla – Bug 323633
Accessible name changes in tab popup are one step behind
Last modified: 2006-03-11 16:23:31 UTC
1) Run several applications. For example: gnome-terminal, gaim, gedit, etc. 2) Run the attached application in an xterm window using the python interpreter. 3) Press Alt+Tab and watch the output from #2 - you'll see that the text events and the object label are for the last window, not the current window.
This problem seems to be introduced with Rev. 1.30, which addressed bug #164590. The ultimate culprit seems to be the call to gtk_label_set_markup in tabpopup.c, which replaced the call to gtk_label_set_text. If I change the calls to gtk_label_set_markup back to gtk_label_set_text, the desired accessibility behavior is restored. This may indeed be a gtklabel bug, but I couldn't make heads or tails of what gtklabel.c was really doing. I'm attaching a patch that reverts the calls back to gtk_label_set_text, but this may violate the fix for #164590 - I'm guessing it was intended to show apps that need attention in bold face in the tab popup.
Created attachment 55808 [details] Standalone python app that demonstrates the bug
Created attachment 55810 [details] [review] Proposed patch that reverts gtk_label_set_markup calls to gtk_label_set_text. I think think the ultimate culprit may be gtklabel not doing the right accessibility thing in the call to gtk_label_set_markup, but this patch restores the proper accessibility behavior to metacity.
Comment on attachment 55810 [details] [review] Proposed patch that reverts gtk_label_set_markup calls to gtk_label_set_text. Patch created using cvs diff -RN -u5 src/tabpopup.c > patch.txt
Thanks for finding this - if it's a GTK bug we should fix it there, since otherwise we'll have to patch every single app that uses set_markup - the metacity patch can't be right, since either the string is plain text or it's markup; if it's markup, you can't set it as text (people will see the markup) - so there has to be more to the patch, to unescape the XML entities and pull out tags or avoid creating markup in the first place Anyway, I think we should reassign to gtk.
Reassigning to gtk+ then.
I have no idea what could be the problem here. AFAICS, set_markup goes through the same path as set_text, namely gtk_label_set_text_internal().
While things seem to point in this direction, I'm not guaranteeing this is a gtk+ label bug. The main thing I've done is provide a standalone app that demonstrates the problem in metacity and a not-so-good workaround that makes the problem go away in metacity. The guts of GTK+ are a bit foreign to me, so I've been unable to track down the ultimate source of the problem.
We recently had a bug report in Orca that seems to be related to this problem. In synaptic, we discovered that the "version" label in the Help->About... dialog ends up with the label name and the accessible text information out of sync. In looking at the synaptic sources, I've discovered that it is a Glade-based application, and the label is initially set up with the label "Synaptic version". The synaptic source uses gtk_label_set_markup to change the string to "synaptic 0.57.4" after retrieving the label. My guess is that perhaps something is going awry here and the AccessibleText information is not being properly updated when the gtk_label_set_markup method is called. I'm not sure if this helps any, but it seems related and might help provide clues as to where to find the ultimate culprit of this problem.
I fixed a few small things wrt to notification in gtklabel today, but I'm not positive it will make any difference to this problem.
Can you check if it works with GTK+ 2.8.10 ?
I hope to take a look very soon. Thanks!
It took longer than expected for me to be able to check this out, but I just verified that this problem does not exist in the latest gtk, so I think you can close this bug. Thanks!
Cool, thanks for checking