GNOME Bugzilla – Bug 355893
Network Preferences - Port label will not be reported by orca.
Last modified: 2006-10-23 13:03:29 UTC
Please describe the problem: Network Preferences - Port label will not be reported by orca. Steps to reproduce: 1. Enable assistive technology support. 2. Run orca. 3. Select Launch menu->Preferences->Network Proxy. 4. Press Tab and Down arrow key to select radio button of Manual proxy configuration. 5. Press Tab to move focus to Port number. Actual results: The label "Port" is not reported by orca. Expected results: The label "Port" should be reported by orca. Does this happen every time? Yes Other information: In looking at the gnome-network-preferences application with at-poke, the "Port:" labels do not have their "label for" property set and the spin buttons do not have their "labelled by" property set.
This bugs belongs to gnome-control-center.
The label-for and labelled-by atk relations do exist in the glade file...
Yep - looks like the 2006-08-07 submit of the glade file by Sebastien Bacher fixed this for GNOME 2.16: http://cvs.gnome.org/viewcvs/gnome-control-center/capplets/network/gnome-network-preferences.glade?rev=1.22&view=log
This bug is still reproducible with gnome2.16 on solaris nevada_46/vermillion_50. Reopen it.
Tim, What do you see with at-poke. It looks to me that the relations are present?
Yes, I could find the relations in at-poke too, but the orca could not report the first port label of http proxy.
Created attachment 74334 [details] test script
I'm noticing something odd in general with text areas in GTK+ now - when one *first* tabs to them (i.e., you've never tabbed to it before), Orca doesn't speak the label of the text area. When one tabs away and then back to the text area, Orca speaks the label. I also notice this with the "Port:" label in gnome-network-preferences. I'm happy with reassigning this back to Orca for now for more exploration.
Thank you Will, that's the problem I found.
Created attachment 74534 [details] Orca debug output generated whilst navigating the Network Proxy Preferences window. I can see the original problem reported by Time (Port label not spoken). I do *not* see a problem with labels associated with text areas not being spoken. What is worrying is that I tested this against Ubunto Edgy Eft with all the latest updates from this morning, so that suggests that the supposed fix by Sebastien Bacher isn't working. Will, if you are getting text areas failing, I think you'll need to investigate this one further for that problem. I'll just investigate the original problem some more tomorrow.
Some more observations: 1/ If there is text in the Manual Proxy Configuration text areas, Orca is nicely speaking it for me. (The previous debug.out was for empty text areas). 2/ at-poke shows LABEL_FOR and LABELLED_BY relationships between the labels and the port spin buttons. 3/ Looking at the debug.out, tabbing to the spin button generates: vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv OBJECT EVENT: object:state-changed:focused detail=(0,0) ---------> QUEUEING EVENT object:state-changed:focused ---------> QUEUEING EVENT object:text-selection-changed ---------> QUEUEING EVENT object:text-caret-moved ---------> QUEUEING EVENT focus: app.name='gnome-network-preferences' name=None role='text' state='EDITABLE ENABLED FOCUSABLE FOCUSED SENSITIVE SHOWING SINGLE_LINE VISIBLE' relations='LABELLED_BY' ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^ So this means that the onStateChanged() method in default.py is being called. (Notice also the LABELLED_BY relationship too). But the state_change_notifiers dictionary at the bottom of default.py doesn't have an entry for ROLE_SPIN_BUTTON. Will, it suggests that maybe there should be such an entry, and that we are interested in "focused" state, yes?
The general model we depend upon in Orca is that a "focus:" event is issued when an object gets focus. The object itself may also issue an "object:state-changed:focus" event, but we tend to ignore this because we're looking for a "focus:" event. That is, we have two redundant things telling us an object has focus, and the one we're using is "focus:". I did a quick test with the gnome-terminal properties dialog - I brought it up, gave focus to the "General" tab, and then ran Orca with debug turned on. I then tabbed to the "Profile name" text area and then quit Orca. Upon analyzing the debug log, it looks like we get the following sequence of events: state-changed:focused lost event on the tab state-changed:focused gained event on the text area text-selection-changed event on the text area text-caret-moved on the text area focus: on the text area We ignore the state-changed:focused events, looking for the focus: event. The text-caret-moved handler (default.py:onCaretMoved) checks to see if the object has the FOCUSED state set; if it does, it silently sets the locus of focus to the text area. onCaretMoved then calls _presentTextAtNewCaretPosition. This updates braille nicely. However, the remainder of _presentTextAtNewCaretPosition will only speak if it can infer why the caret moved. It does so by looking at the last key press, and it doesn't care at all about "Tab". For what to do? I'd really like to see the focus: event issued at the same time as the state-changed:focused event. However, I'm not sure we can reliably depend upon this. So....maybe the very last thing to in _presentTextAtNewCaretPosition (i.e., a final "else" clause) could be to just punt and call self.sayLine(event.source). I'd be hesitant to base any logic on "Tab" because that can be used both to navigate between objects and to enter a real tab in text.
Created attachment 74563 [details] Debug log from previous comment
On second thought - punting and speaking the line is probably not the right thing to do: it seems we might end up speaking the line any time the user entered any text in the text area. Hmmm...I'm not sure what to do here. Rich, I'm definitely open to your thoughts here. For example, maybe we should set the locus of focus appropriately as the first check in onStateChanged (i.e., you need to look at the event detail to see if something gained or lost focus) when we see state-changed:focused events. For example: if event.type == "object:state-changed:focused": if event.detail1: self.onFocus(event, event.source) else: orca.setLocusOfFocus(event, None) return The orca.setLocusOfFocus method has checks in it to detect (and not propagate) calls that indicate the same object has just 'gained' focus. The reason I put a call to "self.onFocus" in here instead of orca.setLocusOfFocus is that onFocus is the place where we tend to morph what we think really has focus. Not sure if this will work, but it might be worth a try. You may also search the rest of the code for "state-changed:focused" to see if there is already any special handling for it going on.
Created attachment 74581 [details] [review] Possible patch to fix the "spin button not speaking" problem. Will, my last comments w.r.t. "object:state-changed:focused" are for the spin button not the text area. I do *not* see the problems you are seeing with text areas on my Ubuntu Edgy Eft system (with latest updates and latest Orca). So I concentrated on fixing the original reported problem. The attached patch seems to do just that. But is it the correct approach? Should the spin button by issueing a "focus" event instead of a "object:state-changed:focused" event.
Ah, I can see why you were confused Will. I cut & pasted the wrong event from the debug.out file. Here's the correct one (from about line 1898): vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv OBJECT EVENT: object:state-changed:focused detail=(1,0) app.name='gnome-network-preferences' name=None role='spin button' state='EDITABLE ENABLED FOCUSABLE FOCUSED SENSITIVE SHOWING SINGLE_LINE VISIBLE' relations='LABELLED_BY' ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^ It could well ne that the text areas are exhibiting a similar problem; I'm just not seeing it. Or, more likely, I'm not following a set of steps that show it.
Ignore the speechgenerator.py debug print statements in the attached patch. That's from another bug.
Created attachment 74668 [details] [review] Patch to hopefully fix the problem. Patch based on what Will was suggesting in comment #14. It seems to work very nicely, both for text areas and spin buttons. Could others please try this too and see if it works for them? Will, if it does work, do you want this one checked in before you make the Orca 2.17.1 tarball? Thanks.
Hi Rich: thanks for checking this one. I'm still a bit nervous about putting it in 2.17.1 due to the nearness of that release. We should, however, get it in soon after 2.17.1 goes out and let it soak a bit for 2.17.2.
Okay, understood.
Will's not created the Orca 2.17.1 tarball, so it's safe to check this into CVS HEAD. Closing as FIXED. If this change introduces any strange side-effects, please let me know.
Seems this fix breaks the fix for bug #361670. Reopening. Thanks Joanie.
Created attachment 74828 [details] [review] Reworked patch that fixes this problem. And doesn't break the fix for bug #361670. Thanks to Joanie for this fix!
Changes checked into CVS HEAD. Closing (again) as FIXED. If you see any further problems with this fix, please let me know.
*** Bug 364391 has been marked as a duplicate of this bug. ***