GNOME Bugzilla – Bug 143502
missing SPI_STATE_FOCUSED
Last modified: 2004-12-22 21:47:04 UTC
1. Start yelp. 2. Press Arrow down to go to the document. The document has 2 static texts ("Help contents" and "Categories") and 3 links ("Desktop", "Applications" and "Development"). 3. Turn caret on (by pressing F7). 4. While you are on static text (without being on a link before) gnopernicus reports something (pressing navigation keys). 5. Visit a link. 6 Go back to a static text. 7. Repeat same operation as described at #4. Now, gnopernicus reports nothing. This is because gnopernicus tries to convert a caret-moved event into a focus one when an ancestor of current object has SPI_STATE_FOCUSED state. But, after visiting a link, this condition is not valid anymore, and gnopernicus behaviour is not the corect one.
I am not clear what the problem is. When navigating from a link to static text the link remains focused. Are you saying that the link should be unfocused?
Created attachment 28235 [details] [review] Proposed patch Does this patch which unsets focus element when navigating from link to static text fix the problem?
if the link would still be activated by the spacebar or Enter, then it should remain focussed (visually and programmatically)
I think the problem reported here might be better fixed with a gnopernicus patch. see 138091
If the focus element is unset the link cannot be activated by Sp[acebar or Enter. The reason why I propsoed the patch to unset the focus element is that mozilla does that when navigating away from a link.
OK, if Mozilla does this in its caret-browsing mode, it makes sense for us to emulate it. Sounds good. However it's not clear to me that unsetting the focus element (without changing FOCUSSED state onto the paragraph into which the caret has moved) will solve the gnopernicus issue. Does mozilla put the focus anywhere in this case, or just set it to "undefined" ?
It looks like mozilla just sets it to "undefined" as pressing Enter does not activate anything.
I am not sure that's OK (to have things in a "no focus" state) from a general accessibility POV, or for gnopernicus. Peter?
I'd like Earl's comments on this as well (cc-ing him separately). My read of Section 508 1194.21(c) is that this is legal ["A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes."]. Mind you, 508 is not the only authority; merely a necessary one. My personal sense is if (a) the focus state is properly reflected in a clear visual fashion [nothing visually suggests focus where there is none], and (b) pressing Tab/Arrow/etc. will bring focus into the focus chain immediately, and in a logical fashion [e.g. to the logical "next"/"previous" item after/before the defocused item], then we are OK.
Sounds reasonable so far... if this is true, then of course gnopernicus' logic will need to be changed, to support the possibility of "needed" caret events when nothing is FOCUSSED.
With Gnopernicus from CVS HEAD (June 4) and gtkhtml2 from CVS HEAD (June 4)with patch from #bug 138091 and from the current bug applied,the problem is partial solved. Please see #bug 138091 for details.
Patch committed to CVS HEAD.
The patch solves the problem, except one case: when moving from a link to a static text. When moving from that static text to another one, the problem is not present. This is the situation described in bug 138091 comment #19.
I am confused by comment #19 in bug 138091. Please supply a test case for this bug and explain what gtkhtml2 is doing wrong when moving from a link to static text.
Examples for #bug 138091: The general idea is to move from a link to a new paragraph. 1) * launch Yelp-> Desktop-> System administration Guide -> Contents Try to 'read' the content of html container. * press F7 to enable caret movement * press 'down' key to "Table of Contents" (static text) => gnopernicus outputs: 'table of contents '----this is ok * press 'down' key again to "About this book " (link) => gnopernicus outputs: 'about this book link'---- this is ok * press 'Up' key to return to 'Table of contents' => gnopernicus outputs:....nothing - THIS IS NOT OK * press 'Up'/ 'Down' key once => gnopernicus outputs the current text line - OK. 2) * launch yepl -> Desktop -> Search for files -> Titlepage * enable caret movement....move into html container * at "Feedback" is a link : 'GNOME Feedback Page' * move from the link down * listen for speech => gnopernicus doe not report the new line/paragraph So, gnopernicus does not report the new paragraph when moving from a link to a new paragraph .
But why is gnopernicus not outputting the correct result a gtkhtml2 bug? What is gtkhtml2 doing wrongly from gnopernicus point of view in these cases?
Created attachment 28538 [details] [review] a tester
Created attachment 28539 [details] [review] ... and its output
The tester will display states for current object (which generated the event) and for its ancestor with HTML_CONTAINER role. Always an object (current one or HTML Container) should have FOCUSED state. But, for events 7, 11, 15, 19, 24, 31 this state is present for none of them. This is the case when moving from a link to a static (non link) text. Also this move must be done from one paragraph (object) to another.
I think I pointed out in a recent meeting (that BAUM attended) that SPI_STATE_FOCUSSED will not always be present if we follow what Mozilla and some other content agents are doing for multi-line text. Padraig pointed out that when focus is not on a paragraph with a link, the keyboard focus becomes (programmatically) undefined. It's not clear that this is the most correct behavior, but we would need to coordinate with Mozilla in any case.
Remus, What did you do to produce the output in comment #18?
Created attachment 28542 [details] [review] New patch I think thatr the problem was that the focus object was being updated after the cursor was moved. This meant that when gnopernicus called back to get the state of the HtmlContainer it was not focused. The new patch should fix this problem. Does this patch fix the problem? Bill, When focus is moved from a link the object with role html-container has focus.
Thanks for the clarification Padraig. Sounds OK then, I believe I misunderstood your previous comments to mean that focus became "undefined" in Mozilla and/or gtkhtml2.
Padraig, the patch solves the problem. Please apply it.
Created attachment 28585 [details] [review] proposed patch for gnopernicus This patch solves a problem in gnopernicus when move from a link to a static text.
Patch commited to CVS.
gtkhtml2 patch applied to CVS HEAD.
This bug is no longer present in my computer, due to Remus's patch.