GNOME Bugzilla – Bug 515923
'Area' labels of Calc Headers/Footers dialog not always announced
Last modified: 2009-03-10 00:05:51 UTC
Steps to reproduce: 1. Launch Calc. 2. Get into the Headers/Footers dialog (Edit -> Headers & Footers) Expected results: At the end of the speech context, Orca would announce that focus is in "Left Area". Actual results: At the end of the speech context, Orca announces "blank" 3. Press Tab to move from Left Area to Center Area. Tab again to move from the Center Area to the Right Area. Expected results: "Center Area" and "Right Area" would each be announced when they gain focus. Actual results: Orca either says nothing or "blank". Note: If you press Tab again after step #3 and then press Shift Tab, "Right Area" gets announced. Likewise, if you Shift Tab from there all the way to the Header page tab and then press Tab once, "Left Area" gets announced.
Created attachment 105068 [details] Orca debug output whilst testing this problem. Commentary to follow...
Here's what's happening: If we do Alt-e, "h" to bring up the Calc Headers/Footers dialog, we get the following events (after the "window:activate" event): ... OBJECT EVENT: window:activate detail=(0,0) app.name='soffice' name='Headers/Footers (Page Style: Default)' role='dialog' state='active enabled sensitive showing visible' relations='' OBJECT EVENT: object:state-changed:active detail=(1,0) app.name='soffice' name='Headers/Footers (Page Style: Default)' role='dialog' state='active enabled sensitive showing visible' relations='' OBJECT EVENT: object:text-caret-moved detail=(0,0) app.name='soffice' name='Paragraph 0' role='paragraph' state='enabled focusable focused multi line sensitive showing visible' relations='' OBJECT EVENT: object:state-changed:active detail=(1,0) app.name='soffice' name='Headers/Footers (Page Style: Default)' role='dialog' state='enabled modal sensitive showing visible' relations='' OBJECT EVENT: focus: detail=(0,0) app.name='soffice' name='Paragraph 0' role='paragraph' state='enabled focusable focused multi line sensitive showing visible' relations='' OBJECT EVENT: object:text-caret-moved detail=(187,0) app.name='gnome-terminal' name='Terminal' role='terminal' state='enabled focusable focused sensitive showing visible' relations='' OBJECT EVENT: object:text-changed:insert detail=(133,53) app.name='gnome-terminal' name='Terminal' role='terminal' state='enabled focusable focused sensitive showing visible' relations='' It's the "window:activate" that speaks: SPEECH OUTPUT: '' SPEECH OUTPUT: 'Headers/Footers (Page Style: Default)' (at line 698). The "window:activate" event sets a new locus of focus. The "object:text-caret-moved" event sets a new locus of focus. It also sets the BRAILLE line to: BRAILLE LINE: 'soffice Application Headers/Footers (Page Style: Default) Dialog TabList Header Page Left area Panel $l' VISIBLE: ' $l', cursor=1 but it doesn't speak anything or sometimes when I tried this it speaks "blank". By the time we get to the "focus:" event, when we call orca.setLocusOfFocus, it's the same locus of focus, so we just return. ---- When we Tab to the Center panel we generate the following events: OBJECT EVENT: object:state-changed:focused detail=(0,0) app.name='soffice' name='Paragraph 0' role='paragraph' state='enabled focusable focused multi line sensitive showing visible' relations='' OBJECT EVENT: object:state-changed:focused detail=(1,0) app.name='soffice' name='Paragraph 0' role='paragraph' state='enabled focusable focused multi line sensitive showing visible' relations='' OBJECT EVENT: object:text-caret-moved detail=(0,0) app.name='soffice' name='Paragraph 0' role='paragraph' state='enabled focusable focused multi line sensitive showing visible' relations='' OBJECT EVENT: focus: detail=(0,0) app.name='soffice' name='Paragraph 0' role='paragraph' state='enabled focusable focused multi line sensitive showing visible' relations='' It's the second "object:state-changed:focused" event that speaks: SPEECH OUTPUT: 'Center area panel' SPEECH OUTPUT: 'Paragraph 0 Sheet1' (at line 967). It's a new locus of focus, so we process it. ---- This suggests to me YAOOOB. When the Headers/Footers dialog is initially activated, to be consistent, shouldn't we have gotten an "object:state-changed:focused" first? I'm open to suggestions on how to work around it in the StarOffice.py script. The component hierarchy when we are in the Left area is: +- app.name='soffice' name='soffice' role='application' state='' relations='' +- app.name='soffice' name='Headers/Footers (Page Style: Default)' role='dialog' state='enabled modal sensitive showing visible' relations='' +- app.name='soffice' name='None' role='page tab list' state='enabled focusable sensitive showing visible' relations='' +- app.name='soffice' name='Header' role='page tab' state='enabled focusable selectable selected sensitive showing visible' relations='' +- app.name='soffice' name='None' role='panel' state='enabled sensitive showing visible' relations='' +- app.name='soffice' name='Left area' role='panel' state='editable enabled multi line multiselectable showing visible' relations='' +- app.name='soffice' name='Paragraph 0' role='paragraph' state='enabled focusable focused multi line sensitive showing visible' relations='' In the onCaretMoved() method in StarOffice.py, we could look for that role list. If it was found, and the locus of focus isn't the same, then we could speak: SPEECH OUTPUT: '<Left|Center|Right> area panel' SPEECH OUTPUT: 'Paragraph 0 Sheet1' or rather handle it the way that we do for the Center area or Right area "object:state-changed:focused" events. Thoughts?
Created attachment 105182 [details] [review] Revision #1 Another Orca debug output file and commentary to follow.
Created attachment 105183 [details] Orca debug output generated whilst testing the patch.
Well we can't trigger off an "object:text-caret-moved" event, like I'd previously hoped, because we don't always get one. In the latest Orca debug output all we initially get when the Headers/Footers dialog is displayed is: Line 661: OBJECT EVENT: window:activate detail=(0,0) app.name='soffice' name='Headers/Footers (Page Style: Default)' role='dialog' state='active enabled sensitive showing visible' relations='' Line 740: OBJECT EVENT: object:state-changed:active detail=(1,0) app.name='soffice' name='Headers/Footers (Page Style: Default)' role='dialog' state='active enabled sensitive showing visible' relations='' So I think this is YAOOB. Will, do you agree? Having said that, when we Tab to the Center and Right areas, and/or Shift-Tab back through these three areas, then we get "object:state-changed:focused" events, so I've added a chunk of code to the onStateChanged() method in StarOffice.py, that does a better job of speaking and brailling where we are. That's ready for testing. If it works, I think we should commit that patch, open a bug against OOo for the lack of an initial "object:state-changed:focused" or "focus:" event, and block this bug against it. Seem reasonable?
I notice a couple of things: 1. We say "grayed" after the name of the panel, presumably because the panel lacks STATE_SENSITIVE. (YAYAOOB?) 2. We say "paragraph x" (where x is the number of the paragraph in which the caret is located) after the name of the panel.
(In reply to comment #5) > Well we can't trigger off an "object:text-caret-moved" event, > like I'd previously hoped, because we don't always get one. > In the latest Orca debug output all we initially get when the > Headers/Footers dialog is displayed is: > > Line 661: > OBJECT EVENT: window:activate detail=(0,0) > app.name='soffice' name='Headers/Footers (Page Style: Default)' > role='dialog' state='active enabled sensitive showing visible' relations='' > > Line 740: > OBJECT EVENT: object:state-changed:active detail=(1,0) > app.name='soffice' name='Headers/Footers (Page Style: Default)' > role='dialog' state='active enabled sensitive showing visible' relations='' When I look at this via accerciser, I see the following events generated after I select the "Headers & Footers" menu item immediately after running soffice and creating a new spreadsheet (i.e., it's the first time I open the dialog): .....(bunches of stuff to tear down the menu)..... .....(more bunched of stuff to create the new window)..... window:activate(0, 0, Headers/Footers (Page Style: Default)) source: [dialog | Headers/Footers (Page Style: Default)] application: [application | soffice] object:state-changed:active(1, 0, None) source: [dialog | Headers/Footers (Page Style: Default)] application: [application | soffice] object:property-change:accessible-parent(0, 0, [application | soffice]) source: [dialog | Headers/Footers (Page Style: Default)] application: [application | soffice] object:text-caret-moved(0, 0, None) source: [paragraph | Paragraph 0] application: [application | soffice] object:state-changed:active(1, 0, None) source: [dialog | Headers/Footers (Page Style: Default)] application: [application | soffice] focus:(0, 0, None) source: [paragraph | Paragraph 0] application: [application | soffice] The "focus:" event above seems to be right on. If there's a bug here, it's that we're not getting a redundant "object:state-changed:focused" event for the object. But, we should be handling "focus:" and "object:state-changed:focused" events the same, as long as the detail1 of the "object:state-changed:focused" event is 1. So, I'm not sure I'm seeing the same issue you are. (In reply to comment #6) > I notice a couple of things: > > 1. We say "grayed" after the name of the panel, presumably because > the panel lacks STATE_SENSITIVE. (YAYAOOB?) I think the general problem is that the patch is circumventing the speech context generation code. Ideally, we could just let that code work. The crux of the problem may be due to this portion of the analysis from Rich: The "object:text-caret-moved" event sets a new locus of focus. It also sets the BRAILLE line to: BRAILLE LINE: 'soffice Application Headers/Footers (Page Style: Default) Dialog TabList Header Page Left area Panel $l' VISIBLE: ' $l', cursor=1 but it doesn't speak anything or sometimes when I tried this it speaks "blank". By the time we get to the "focus:" event, when we call orca.setLocusOfFocus, it's the same locus of focus, so we just return. That is, we're ending up in a situation where the locus of focus has already been set to the object in question by the time we get the event that triggers Orca to speak the object. So, I wonder if it might make sense to try to force the locus of focus change to be propagated for a caret moved event if we detect the isDesiredFocusedItem logic returns true? A possible area for this might be somewhere in StarOffice.py:onCaretMoved.
> So, I wonder if it might make sense to try to force the locus of focus change > to be propagated for a caret moved event if we detect the isDesiredFocusedItem > logic returns true? A possible area for this might be somewhere in > StarOffice.py:onCaretMoved. And that was my initial thought (see comment #2). But unfortunately we do not seem to get the "object:text-caret-moved" event every time (see comment #5). If you look at the two different Orca debug output, you'll see that we get a totally different set of events. I'm not sure there is a simple fix in the StarOffice.py script for this. Perhaps a better solution would be to get OOo to do the right thing and be consistent...
The thing I want to understand is if we might be doing something we shouldn't be doing before declaring this is totally YAOOB. An interesting case I'm seeing is this kind of debug that happens after pressing Tab: 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-caret-moved KEYEVENT: type=1 hw_code=23 modifiers=0 event_string=(Tab) is_text=True time=1202937121.845547 orca.isModifierKey: returning: False app.name='soffice' name='Paragraph 0' role='paragraph' state='enabled focusable multi line sensitive showing visible' relations='' LOCUS OF FOCUS: app='soffice' name='Paragraph 0' role='paragraph' event='object:state-changed:focused' ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^ In this case, the LOCUS OF FOCUS is being set, but nothing is being output. That would indicate something somewhere is purposely not causing the the focus change to be propagated. In looking at StarOffice.py:onStateChanged, I see the following code: # Two events are received when the caret moves # to a new paragraph. The first is a focus event # (in the form of object:state-changed:focused # instead of focus:). The second is a caret-moved # event. Just set the locusOfFocus for the first event. # if event.type.startswith("object:state-changed:focused") and \ event.source.getRole() == pyatspi.ROLE_PARAGRAPH and \ event.source != self.currentParagraph: self.currentParagraph = event.source orca.setLocusOfFocus(event, event.source, False) return Interesting. So, it looks as though it depends upon a caret-moved event to output something.
Created attachment 105256 [details] [review] Patch to propagate locus of focus change under special hierarchy conditions This patch propagates the change to the locus of focus under the special hierarchical conditions. It seems to work for me.
Your patch certainly gets rid of the "grayed" problem reported by Joanie, but all I hear when I initially bring up the Header/Footer panel is: SPEECH OUTPUT: '' SPEECH OUTPUT: 'Headers/Footers (Page Style: Default)' SPEECH OUTPUT: 'blank' This is the original problem reported by Joanie. Is it now speaking "Left area" for you? If so, could you attach your debug.out so I can see what's different? Thanks.
Created attachment 105263 [details] Debug output when running with previous patch > Is it now speaking "Left area" for you? If so, could you attach > your debug.out so I can see what's different? Sure thing. Look at lines: 1) 548 - window is initially activated and we speak 2) 620 - Left area is presented 3) 792 - Tab to Center area and it is presented 4) 900 - Tab to Right area and it is presented 5) 1072 - Shift+Tab back to Center area and it is spoken 6) 1184 - Shift+Tab back to Left area and it is spoken This is with SOffice 8 on Solaris Express build 79b.
The reason this is working for you is because you are getting an "object:state-changed:focused" for that Left area (line 563). I don't get that with OOo 2.3 on my Ubuntu Gutsy system. What version of OOo does StarOffice 8 equate to?
It's not saying "Left area" for me either (OOo 2.3, Hardy).
Just tried OOo 2.4-dev still no "left area".
If this used to give us an "object:state-changed:focused" event for StarOffice 8, and it's no longer doing that, that looks like YAOOOB (or at least a regression) to me.
(In reply to comment #13) > What version of OOo does StarOffice 8 equate to? Got me - all I see is "Product Update 9" in the "About StarOffice" dialog. I'd guess this equates to "older than what you have". (In reply to comment #16) > If this used to give us an "object:state-changed:focused" event for > StarOffice 8, and it's no longer doing that, that looks like YAOOOB > (or at least a regression) to me. With repeated banging, I'm also seeing that it also *sometimes* doesn't emit this event for the "Left" area when the dialog first appears. But, it always manages to do so when I tab around. I haven't narrowed down the exact sequence of steps to make it work or fail. I'm curious if the patch addresses this part of the bug opener: 3. Press Tab to move from Left Area to Center Area. Tab again to move from the Center Area to the Right Area. Expected results: "Center Area" and "Right Area" would each be announced when they gain focus. Actual results: Orca either says nothing or "blank". Note: If you press Tab again after step #3 and then press Shift Tab, "Right Area" gets announced. Likewise, if you Shift Tab from there all the way to the Header page tab and then press Tab once, "Left Area" gets announced. If so, we might be able to reduce this YAOOB to an initial focus event not being emitted.
(In reply to comment #17) > I'm curious if the patch addresses this part of the bug opener: > > 3. Press Tab to move from Left Area to Center Area. Tab again to > move from the Center Area to the Right Area. > > Expected results: "Center Area" and "Right Area" would each be > announced when they gain focus. > > Actual results: Orca either says nothing or "blank". > > Note: If you press Tab again after step #3 and then press Shift > Tab, "Right Area" gets announced. Likewise, if you Shift Tab from > there all the way to the Header page tab and then press Tab once, > "Left Area" gets announced. > > If so, we might be able to reduce this YAOOB to an initial focus event not > being emitted. > I'm afraid it doesn't for me. :-(
Darn. OK. Well...I think this bug may be more on the lower use case side of things. As such, we probably shouldn't hack around the YAOOB issue. Instead, we should open YAOOB with clear detail about what is broken and what the desired behavior is. It seems as though we should be getting appropriate focus: and object:selection-changed:focused events for objects in question, and we should be getting them when the dialog first appears as well as when tabbing between the objects. Does that sound right? If so, I say feel free to block this bug after you've logged the OOo bug. Thanks!
I think I agree with you Will, but just a quick check. Joanie, did my original patch almost to the right thing when Tabbing around, modulo saying the wrong thing (i.e. "grayed")? If so, maybe we should try to fix up/adjust that patch so it says something better as well as filing YAOOB.
In 2.3, yes; in 2.4 we don't say anything even with your patch.
(In reply to comment #20) > I think I agree with you Will, but just a quick check. > > Joanie, did my original patch almost to the right thing when > Tabbing around, modulo saying the wrong thing (i.e. "grayed")? > > If so, maybe we should try to fix up/adjust that patch > so it says something better as well as filing YAOOB. If you can guarantee that the patch will present the same information in speech and braille before and after the OpenOffice organization fixes the bug, it's OK to commit it. I'm trying to avoid a situation like we had with planner where the fix in planner caused us to remove code on our side. That kind of situation tends to be brittle because it requires a number of separate things to be at a specific rev. The more we can avoid those situations, the better.
> If you can guarantee that the patch will present the same information in speech > and braille before and after the OpenOffice organization fixes the bug, it's OK > to commit it. My crystal ball is broken, so I'll just file YAOOB. Bug number in a few moments.
I've opened OpenOffice issue #86112 http://www.openoffice.org/issues/show_bug.cgi?id=86112 Hang you hat on the cc: hook if you are interested in it. Blocking this one. Thanks for all your feedback.
Setting Target Milestone to FUTURE as we have no control over other accessibility bugs that we are blocked against.
I have confirmed that the OOo bug is fixed. We now announce the labels. We also announce a role of UNKNOWN and the numbered paragraph, for example tabbing into the Center area which contains the text "Sheet1", Orca says: 'Center area unknown' 'Paragraph 0 Sheet1' I think we should lose the unknown. What about the "paragraph 0"? (Note that if the "paragraph" part is desirable, but counting from "0" is not, we have an OOo RFE for that along with a tracking bug (bug #539773).) Removing "to confirm", replacing it with Mike's name for feedback, and assigning it to me.
Yes please lose the "unknown".
Created attachment 114746 [details] [review] proposed patch (maybe) This loses the 'unknown'. In talking with Mike, we agreed that in this particular case, we really don't want to say the name "paragraph 0" either. This patch seems to get the job done and pylints. Notes and questions: 1. Haven't yet regression tested this. We need to update the regression tests for OOo and/or figure out why they tend to fail on my box. 2. You need OOo 3.0 dev (m24 or later, I believe). 3. In the default speechgenerator, we don't speak the role for ROLE_PARAGRAPH. I'm good with that, but that means that we're not saying anything to let the user know that the thing they've just given focus to is a thing they can type in. Should we fudge and speak the role for ROLE_TEXT? Should we speak the real role (paragraph) in this particular case? Something else?
> 3. In the default speechgenerator, we don't speak the role for ROLE_PARAGRAPH. > I'm good with that, but that means that we're not saying anything to let the > user know that the thing they've just given focus to is a thing they can type > in. Should we fudge and speak the role for ROLE_TEXT? Should we speak the real > role (paragraph) in this particular case? Something else? > I normally don't like doing this sort of thing but in this case to be consistant I think we should speak the role "text" If anyone feels strongly that this is a bad idea I'll be OK with "paragraph"
Created attachment 117965 [details] [review] revision 4 This patch does a few things: * narrows down the new _getSpeechForText() in the soffice.speech_generator.py to see if we're in a dialog. * adds support for the newly-invented "text frame" role in the soffice.speech_generator.py * implements parallel whereAmI support for both of the above * handles some goofy descriptions introduced by OOo. Now for some reason, the description of some paragraphs is the object name plus the displayed text plus some punctuation tossed in for good measure. If we don't do anything, where am I will essentially double-speak the bulk of what it's presenting. * Makes a change to the default speechgenerator's getSpeechContext() and also the default whereAmI (throughout). In both cases we're getting the speech for the role directly from rolenames.py. This doesn't give the scripts the ability to special-handle goofy role-related issues. As a result, we speak the role "text frame" as part of the context. Given the nature of the change, I need to run all of the regression tests. In the meantime, it pylints. :-) Will, are these changes okay (pending the test results)?
Created attachment 117972 [details] [review] revision 5 (change method name to be more descriptive) This version makes the new where_am_I method for obtaining the speech for the rolename more accurately reflect what it does. :-) Thanks Will! Please test.
This patch seems to work well for me.
Thanks Mike. Will shall we check this one in?
(In reply to comment #33) > Thanks Mike. Will shall we check this one in? By all means, please do! Thanks!
Done. Thanks Will. Closing as FIXED.
Created attachment 118200 [details] [review] just.... one.... more.... tweak I could've sworn that I ran the Firefox regression tests as part of my work on this bug, but apparently not. My bad.... In Gecko there are roles we just don't want the speechgenerator to speak when we're navigating in document content (like paragraph, section, document frame, list item, etc.) We do however want these roles spoken during a whereAmI -- and they were spoken prior to the original check in for this bug. :-) This patch restores that functionality. It also adds a "just in case" sanity check. Regression tests re-run. Pylinted. Committed.