GNOME Bugzilla – Bug 347691
In standard print dialog, printer table items not always spoken/displayed
Last modified: 2008-02-04 16:28:41 UTC
Please describe the problem: When you get into the standard print dialog (e.g. the one belonging to Evolution and Gedit), focus is automatically placed in the table of printers. At this point, pressing Up or Down Arrow moves you to another printer, but that printer name is not spoken or displayed. If you Arrow one or two more times, printer names are then spoken and displayed as expected. Steps to reproduce: 1. Launch Gedit or Evolution 2. Press Control P for the Print dialog. The currently selected printer is spoken/displayed correctly. 3. Press Up or Down Arrow ONCE to move to a different printer. The currently selected printer is not spoken/displayed. 4. Continue to press Up or Down Arrow. After one or two more presses, printers are correctly spoken/displayed as they get selected. Actual results: (Outlined in the steps above) Expected results: The selected printer would always be spoken/displayed. Does this happen every time? Yes, on both of my machines. Other information: This is with Orca 0.2.6, but I *believe* the problem was present in 0.2.5 as well.
This appears to be a duplicate of bug #341371. There is a patch attached to that bug that seems to fix both that problem and this problem, but it includes a Gross Hack. Awaiting comments from Will on whether we wait to apply it, or if there is a better solution.
The fix for bug #341371 seems to have nicely fixed this problem tool.
Changes for bug #341371 are now in CVS HEAD. Marking this bug as FIXED.
I've backed out the fix for bug #341371. It has bad side-effects. Reopening this bug.
By the Bugzilla definition of critical [1], this bug isn't critical. Bumping it down a notch. Thanks for the clarification Will. [1] http://bugzilla.gnome.org/page.cgi?id=bug-status.html#bug_severity
The new fix for bug #341371 seems to fix this also. See my last comment there for more information. Joanie, before I just close it out again this time, could you please build and try the latest CVS HEAD and confirm that things are now working for you? Thanks.
Upon further investigation, the fix for bug #341371 won't fix this. In the Open File dialog, when you move from one row to another, you get an "object:active-descendant-changed" event. That's where the 341371 fix went. When moving around in the print dialog, we don't get that event. Will, would you consider this a bug with the Gtk+ print dialog?
I'm not sure if this is a print dialog problem or not. If we're not getting any events as you arrow between the icons in the print dialog, then something seems like there is definitely something going wrong with their AT-SPI implementation.
Oh we're getting an "object:selection-changed" event too, but last time we tried adjusting the logic there, StarOffice Open File dialog broke. Perhaps this is something else that can be special cased in processObjectEvent() in default.py ...
Created attachment 70201 [details] [review] Potential fix for the problem.
Will and I reworked how "object:selection-changed events are handled. The code is a lot cleaner now. The reworked version seems to nicely fix this problem. The changes have also affected two other bugs (bug #345462 and bug #341371). This patch seems to also nicely fix them. This was a relatively big change that can potentially affect a lot of areas. It will need to be fully tested before the 0.3.8 release next week. Closing the bug as FIXED for now. If problems arise as side-effects of these changes, I'll open a new bug (as the symptoms of this bug are apparently nicely fixed).
I'm afraid this is back, both for Dapper and Edgy. I don't know at what point it was reintroduced since I very rarely print. Here's what I do know: On my Dapper box the problem appeared as originally reported, namely the initial item with focus is spoken, but you have to arrow several times before other items are spoken. Then I built from CVS HEAD. The problem is now worse: The initial item with focus is not spoken and no amount of arrowing around causes subsequent items to be spoken. Plus there is now a *significant* delay between pressing an arrow key and focus actually moving. Next I built from CVS HEAD on one of my Edgy boxes. No items are spoken, significant delay. Finally I *didn't* build from CVS HEAD on my other Edgy box. It is behaving as originally reported. I don't recall exactly when I last built from CVS HEAD on this final machine, but the most recent entry in my ChangeLog is: 2006-08-10 Willie Walker <william.walker@sun.com> * src/orca/flat_review.py: fix for bug 349465 - take some defensive actions in the event that the AT-SPI implementation has implemented getTextAtOffset incorrectly (i.e., it gives back garbage for offsets). Hope this helps! And sorry to be the bearer of bad news!
To follow up: I'm seeing similar behavior in the Deskbar Applet in Edgy, namely as I arrow Up and Down, items are not read if I am using the very latest CVS build. They are read with the earlier build.
What's happening here is that when you Up/Down arrow to a different printer in the printer dialog, one of the events that is generated is "object:selection-changed". In default.py, in the onSelectionChanged() routine there is the following piece of code: # Avoid doing this with objects that manage their descendants # because they'll issue a descendant changed event. # if event.source.state.count( atspi.Accessibility.STATE_MANAGES_DESCENDANTS): return The onSelectionChanged() routine is returning at this point. Unfortunately there is no following "object:active-descendant-changed" event to trigger the speaking/brailling of the new printer information. As we've seen, this used to work. Something somewhere else has changed, and had the side-effect of changing this. Still looking...
More details on what is going on here. I have two "printers": "Create a PDF Document" "Generic Postscript" The initial focus is on the "Generic Postscript" one. I see a "focus:" event for the printer "table" and this gets nicely read: OBJECT EVENT: focus: detail=(0,0) app.name='gedit' name=None role='table' state='ENABLED FOCUSABLE FOCUSED SENSITIVE SHOWING VISIBLE MANAGES_DESCENDANTS' BRAILLE LINE: 'gedit Application Print Dialog TabList Printer ScrollPane Table Generic Postscript ' VISIBLE: ' Generic Postscript ', cursor=1 SPEECH OUTPUT: 'tab list Printer page table' SPEECH OUTPUT: ' Generic Postscript ' I then hit the Up key. The following events are seen: OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:selected detail=(0,0) OBJECT EVENT: object:state-changed:selected detail=(1,0) OBJECT EVENT: object:state-changed:selected detail=(0,0) OBJECT EVENT: object:state-changed:selected detail=(1,0) OBJECT EVENT: object:state-changed:selected detail=(0,0) OBJECT EVENT: object:state-changed:selected detail=(1,0) OBJECT EVENT: object:state-changed:selected detail=(0,0) OBJECT EVENT: object:state-changed:selected detail=(1,0) OBJECT EVENT: object:state-changed:selected detail=(0,0) OBJECT EVENT: object:state-changed:selected detail=(1,0) OBJECT EVENT: object:selection-changed detail=(0,0) OBJECT EVENT: object:state-changed:showing detail=(1,0) OBJECT EVENT: object:state-changed:visible detail=(1,0) OBJECT EVENT: object:state-changed:showing detail=(1,0) OBJECT EVENT: object:state-changed:visible detail=(1,0) OBJECT EVENT: object:selection-changed detail=(0,0) OBJECT EVENT: object:state-changed:showing detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:state-changed:showing detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:text-changed:delete detail=(0,10) OBJECT EVENT: object:text-changed:insert detail=(0,10) OBJECT EVENT: object:property-change:accessible-name detail=(0,0) OBJECT EVENT: object:property-change:accessible-name detail=(0,0) OBJECT EVENT: object:property-change:accessible-name detail=(0,0) OBJECT EVENT: object:property-change:accessible-name detail=(0,0) OBJECT EVENT: object:state-changed:showing detail=(1,0) OBJECT EVENT: object:state-changed:visible detail=(1,0) OBJECT EVENT: object:state-changed:showing detail=(1,0) OBJECT EVENT: object:state-changed:visible detail=(1,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:selected detail=(0,0) OBJECT EVENT: object:state-changed:selected detail=(0,0) OBJECT EVENT: object:state-changed:selected detail=(0,0) OBJECT EVENT: object:state-changed:selected detail=(0,0) OBJECT EVENT: object:state-changed:selected detail=(0,0) OBJECT EVENT: object:selection-changed detail=(0,0) The ones of interest are the "object:selection-changed" ones. There are three of them. The first one is: OBJECT EVENT: object:selection-changed detail=(0,0) app.name='gedit' name=None role='table' state='ENABLED FOCUSABLE FOCUSED SENSITIVE SHOWING VISIBLE MANAGES_DESCENDANTS' When this one causes onSelectionChanged() in default.py to be called, it just returns because of: # Avoid doing this with objects that manage their descendants # because they'll issue a descendant changed event. # if event.source.state.count( atspi.Accessibility.STATE_MANAGES_DESCENDANTS): return The second one is: OBJECT EVENT: object:selection-changed detail=(0,0) app.name='gedit' name='File' role='combo box' state='ENABLED SENSITIVE SHOWING VISIBLE' Because this was for a "combo box", onSelectionChanged() in default.py called: if event.source.role == rolenames.ROLE_COMBO_BOX: orca.visualAppearanceChanged(event, event.source) The third one is: OBJECT EVENT: object:selection-changed detail=(0,0) app.name='gedit' name=None role='table' state='ENABLED FOCUSABLE FOCUSED SENSITIVE SHOWING VISIBLE MANAGES_DESCENDANTS' This is similar to the first one and just returns. There was no "object:active-descendant-changed" following to cause the new selection to be spoken/brailled. At least for this "Up" keyboard event. I then hit "Down" to go back to the "Generic Postscript" printer. That generated the following events: OBJECT EVENT: object:state-changed:showing detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:state-changed:showing detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:selection-changed detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:sensitive detail=(1,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:visible detail=(0,0) OBJECT EVENT: object:children-changed:add detail=(0,0) OBJECT EVENT: object:state-changed:selected detail=(1,0) OBJECT EVENT: object:state-changed:selected detail=(1,0) OBJECT EVENT: object:state-changed:selected detail=(1,0) OBJECT EVENT: object:state-changed:selected detail=(1,0) OBJECT EVENT: object:state-changed:selected detail=(1,0) OBJECT EVENT: object:state-changed:selected detail=(0,0) OBJECT EVENT: object:selection-changed detail=(0,0) OBJECT EVENT: object:active-descendant-changed detail=(10,0) There were two "object:selection-changed" events. The first one is: OBJECT EVENT: object:selection-changed detail=(0,0) app.name='gedit' name='lpr' role='combo box' state='ENABLED SENSITIVE SHOWING VISIBLE' This is similar to event #2 above and onSelectionChanged() in default.py calls: if event.source.role == rolenames.ROLE_COMBO_BOX: orca.visualAppearanceChanged(event, event.source) The second one is: OBJECT EVENT: object:selection-changed detail=(0,0) app.name='gedit' name=None role='table' state='ENABLED FOCUSABLE FOCUSED SENSITIVE SHOWING VISIBLE MANAGES_DESCENDANTS' This just returns in onSelectionChanged() because of: # Avoid doing this with objects that manage their descendants # because they'll issue a descendant changed event. # if event.source.state.count( atspi.Accessibility.STATE_MANAGES_DESCENDANTS): return But we then get an "object:active-descendant-changed" event. This calls onActiveDescendantChanged() in default.py and calls: child = atspi.Accessible.makeAccessible(event.any_data.value()) orca.setLocusOfFocus(event, child) The problem here is that orca_state.locusOfFocus is still set to the "Generic printer" table cell, so when we call orca.setLocusOfFocus() again, with obj pointing there again, it's just returning via: if obj == orca_state.locusOfFocus: return The question now is why aren't we getting an "object:active-descendant-changed" event for the initial Up key event?
With the latest Orca, I now get the following: Up - no "object:active-descendant-changed" event. Nothing spoken. Down - "object:active-descendant-changed" event. But focus was on the same printer. Nothing spoken. Up - "object:active-descendant-changed" event. Printer spoken. Down - "object:active-descendant-changed" event. Printer spoken. So the problem is we are now just not getting the "object:active-descendant-changed" event the very first time, but this has the side-effect of also causing the second time to not work.
I've opened a new bug #351946 against the gnome-print module for the problem of the missing "object:active-descendant-changed" event. I'm not sure there is anything more we can easily do in Orca until that has been resolved.
Joanie, as this bug has a workaround (do Up, Down, Up, Down a couple of times and it should start speaking), I'm reducing the priority/severity down to normal. Please file a separate bug for the Deskbar applet problem you are seeing otherwise it'll get lost in the noise. Thanks.
*** Bug 319675 has been marked as a duplicate of this bug. ***
Add accessibility keyword. Apologies for spam.
Removing target milestone from [blocked] bugs. We have little control over them, so we're better off letting priority and severity be our guide for poking the related components.
Marking the patch as committed. It looks like it was checked in (see comment #11), and the bug was closed as FIXED, but then reopened as the bug came back. It's probably easier to wait for the RealFix(tm) in the gnome-print dialog code.
Reassigning to Rich to be the person to track the blocking bug.
The underlying bug appears to be now fixed. Closing this one as well.