GNOME Bugzilla – Bug 156466
[Reader] "unfocussed" context won't be read by gnopernicus.
Last modified: 2004-12-22 21:47:04 UTC
Steps to reproduce: 1. Launch Gnopernicus. 2. Launch mozilla and go to http://www.sun.com/ 3. Press F7 to turn into caret mode. 4. Press arrow key to move focus into html contexts. Expected result: Contexts should be read by gnopernicus. Actual result: Contexts can't be read by gnopernicus. Additional information: Brlmonitor works fine. And this bug can't be reproduced in the following testing environment: S10_67 SPARC + Cinnabar19 + Mozilla21
Bug appears in S10_69 + Cinnabar21 on Solaris Sparc. It may also happen on Linux; not tested there yet.
I can reproduce this bug on Cinnabar21-Linux and Gnopernicus from CVS gnome-2-8 branch(Oct 27). I will try to see what is the cause of this bug.
Created attachment 33115 [details] [review] proposed patch (a version)
Created attachment 33116 [details] [review] another proposed patch
This bug was introduced by the fix for 153920. Both patches are workarounds in gnopernicus. The root of the bug is the absence of FOCUSED state for current paragraph in mozilla.
The concept of "focus" in mozilla is a little different from at-tools. In mozilla, HTML text is not focusable and will never get focused although caret can move inside HTML text in caret browsing mode. UI elements and links in HTML are focusable and can be accessed by pressing "Tab". In caret browsing mode, UI elements and links can also get focused when the caret is inside them. I have tested adding "state_focusable" and "state_focused" (if the caret is inside the text) to accessible object of HTML text, which works fine with gnopernicus. My only concern is whether doing this will bring regression to mozilla's interaction with other AT-Tools, e.g. GOK. I'll integrated this workaround in mozilla side in next build if no regression.
Gnopernicus expects the AccessibleText object with the caret to have the FOCUSED state. I think this is the case with StarOffice, gnome-help, and other things that have multiple AccessibleText objects within a container (as compared to gedit). I would be surprised if GOK had troubles with this. If this works (as you say) with Gnopernicus, this may be the right solution.
*** Bug 156691 has been marked as a duplicate of this bug. ***
*** Bug 156688 has been marked as a duplicate of this bug. ***
*** Bug 156461 has been marked as a duplicate of this bug. ***
All these bugs: bug #156466 (which was already fixed in mozilla), bug #156461, bug #156688, #bug 156691 have the same root cause: the absence of FOCUSED state for the object which should be presented. The patch proposed in comment #3 fixes all these bugs.
Can we apply this patch ? It solve a lot of issues, I believe it should be applied.
I still don't like the patch, because it will cause all text events to be spoken, even if the objects are neither focussed nor watched. The logic seems too general to me, it will result in excess chatter.
*** Bug 157330 has been marked as a duplicate of this bug. ***
Bill, all events in this function (changed by patch) are proposed for presentation by srlow. So, they should be presented. The bug is: sometimes, an focus event is generated by srlow from another event. In this case, the object doesn't have the FOCUSED state, but it has to be presented to user. So, the patch will never present all text events except those for current gnopernicus focused object.
*** Bug 157622 has been marked as a duplicate of this bug. ***
Remus: can you explain why these events have already "filtered out" events from things like statusbars and text fields that aren't "the current gnopernicus focused object" ? Please indicate exactly which at-spi event types are being handled by this code (i.e. which event strings), and where this other filtering takes place.
by the way Remus: thanks for the explanations so far. I'd just like them to be a little more detailed - I am hoping to understand the details of this patch enough to feel OK about having it committed tomorrow, since I agree that we really want this fix in tomorrow's tarball release.
Bill, srlow module is responsable to filter events and to decide which events are important or not for user. Srcore is responsable to generate the output for them. In case of braille, is very simple, all event generates output. For speech, because some events are more important than others (window events vs focus tracking events, events for watched object vs focus tracking, etc) the output has to be sent to speech with a priority. Function in which bug is does this (assigning priorities to speech output). It should do this for all. It is _not_ its job to decide if event is or not important for user. I did that mistake when I have chose the second patch for bug 153920. First patch does same this as patch proposed here (it does also the required things for that bug). Witout this patch, only events for objects with FOCUSED state or watched objects are presented. In case of switching context (when moving from a group of objects to another, or changing the applet from bottom panel--eg bug with CD applet) the context-switch event will be never present becuse the context is neither focused or watched.See bugs 144315, 128289, 111854 . Also in case of tabs for gnome-terminal in case of bug 128970.
>>I still don't like the patch, because it will cause all text events to be >>spoken, even if the objects are neither focussed nor watched. >>The logic seems too general to me, it will result in excess chatter. >Remus: can you explain why these events have already "filtered out" events from >things like statusbars and text fields that aren't "the current gnopernicus >focused object" ? Major events filtering is in SRLow. >Please indicate exactly which at-spi event types are being handled by this code >(i.e. which event strings), and where this other filtering takes place. There is no special event. Some event may generate events which needs this patch: focus: for 111854, 128289,144315 object:selection-changed in case of tabs in gnome-terminal.
Comment on attachment 33116 [details] [review] another proposed patch I like this patch but because Remus indicated that the first one worked better for some context-switch events, I suggest a revised version of this patch which allows "context" events to be spoken without the srl_is_object_focused() check.
Created attachment 33635 [details] [review] reworked patch
Because in case of presenting current object when ALT+TAB-ing other events (text-changed:insert and delete) are received for this object, the patch has a change to retain this is last_focused object and return TRUE in case of srl_is_object_focused () call.
Comment on attachment 33635 [details] [review] reworked patch Patch applied to cvs head and gnome-2-8 branch.