GNOME Bugzilla – Bug 513238
Flat review is broken in Evolution
Last modified: 2008-07-22 19:33:45 UTC
Steps to reproduce: 1. Start Orca 2. Start Evolution. 3. Press KP-8 Expected results: Should speak/braille current location. Actual results: Zip. Zilch. Nada. Orca debug log to follow.
Created attachment 104058 [details] Orca debug output whilst testing flat review.
Created attachment 104091 [details] [review] revision 1 Looks like the Evo table column headers (status, flagged, etc.) don't implement the component interface -- or pretty much anything else for that matter. YAEB? (The column headers in gtk-demo implement the component interface). Anyhoo, this is a defensive patch. With it I can flat review in Evo -- and amusingly enough, use flat review to access the headers that don't implement anything. <shrugs> Please test.
Slight correction: With this patch, I can flat review in Evo and *we draw rectangles around the offending column headers*, but what Orca reads in that instance is the text in the first row (i.e. from the first message in the list). Still.... Flat review in Evo has never been quite right....
Thanks Joanie. So is bug #268473: http://bugzilla.gnome.org/show_bug.cgi?id=268473 related to this?
My guess would be yes. :-) In that bug the reporter indicates "For example if we run at-poke and check none of these fields 'To', 'Subject' & 'Date' in viewbar are not accessible." I'm not sure how "accessible" is being defined here: 1. "They don't show up at all in the hierarchy" or 2. "They show up but are minimally implemented to the point of being nearly useless in and of themselves." (i.e. they're still useful as-is w.r.t. the table as a whole because when we ask for the column header we get the column header, and they do have the expected associated Sort action.) If you go with the latter interpretation, bug 268473 caused this bug. If the headers didn't have associated accessible objects (former interpretation), we wouldn't have done a queryComponent() on them.
(In reply to comment #3) > Slight correction: With this patch, I can flat review in Evo and *we draw > rectangles around the offending column headers*, but what Orca reads in that > instance is the text in the first row (i.e. from the first message in the > list). Still.... Flat review in Evo has never been quite right.... Joanie - do bug 415812 and bug 415705 look like they might be related to this problem?
I think the patch looks fine and say commit if you have done the appropriate regression/pylint testing. Thanks!
It pylints just fine. In terms of regression testing, I found four tests that test flat review: * gtk-demo/role_text_multiline_navigation.py * firefox/flat_review_text_by_line.py * firefox/flat_review_text_by_word_and_char.py * oowriter/bug_361624.py The gtk-demo and firefox tests use assertions and those three tests ran just fine. The oowriter test does not use assertions, therefore I figured I would update the test so that it does and then compare before and after the patch for this bug. Unfortunately, when I run the oowriter test, after pressing Control+Home, using flat review to review the current line causes the menu bar to be reviewed rather than the first line of the document. However, when I run the test manually (i.e. by performing the same steps), flat review begins on the first line as expected. I cannot figure out what magical command or step to insert into the test to cause it to do "the right thing" (namely, starting from the top of the document rather than the top of the window). :-( Any ideas? Since the patch is a sanity check that fixes a serious bug and doesn't seem to introduce any regressions based on functional testing along with running the few flat review tests we do have, I went ahead and committed it. Moving this to pending.
> this bug. Unfortunately, when I run the oowriter test, after pressing > Control+Home, using flat review to review the current line causes the menu bar > to be reviewed rather than the first line of the document. However, when I run > the test manually (i.e. by performing the same steps), flat review begins on > the first line as expected. I cannot figure out what magical command or step > to insert into the test to cause it to do "the right thing" (namely, starting > from the top of the document rather than the top of the window). :-( Any > ideas? I'm not sure. I wonder if you might need to force a caret movement somewhere to make sure Orca knows where the locus of focus is? In addition, this might also be a synchronous/asynchronous issue, but I cannot imagine how it would be since this is just flat review. Lastly, maybe there's just some event we need to wait for before telling Orca to do the flat review?
(In reply to comment #9) > I'm not sure. I wonder if you might need to force a caret movement somewhere > to make sure Orca knows where the locus of focus is? Yeah, that's what I thought too. I would have hoped that Control+Home would have been sufficient. When it wasn't, I added a Control+Right followed by a Control+Left. Still no difference. :-( > Lastly, maybe there's just some event we need > to wait for before telling Orca to do the flat review? Dunno. But I'll take another look. Thanks!
This does seem to fix the problem of no flat review in evolution. Flat review in evolution is still a mess in general but that is not what this bug was about. OK to close.
Thanks Mike. Closing as FIXED.