GNOME Bugzilla – Bug 157330
Gnopernicus Speech stops working with Yelp
Last modified: 2004-12-22 21:47:04 UTC
Using a Solaris Sparc nightly build from 2nd November 2004 -Launch gnopernicus speech -Launch Yelp -Initially gnopernicus reads the contents of the Yelp window -Select : Desktop Bug Report Tool Section 1 Introduction -'F7' to bring caret to start of text Gnopernicus speech stops working, it no longer reads on contents of Yelp. This occurs for various pages in Yelp A possible workaround would be to use the layers option for screen reader. i.e. layer 03 and option 7
*** This bug has been marked as a duplicate of 156466 ***
I am mreopening this bug as I do not think that it is fixed in gnopernicus 0.9.17. I started yelp with gnopernicus running. I heard "create window loading". I did not hear anything when window name changed to "Help Contents". (issue 1) First focus is on the Home button on the toolbar. Press tab. Focus moves to Desktop link but nothing is spoken. (issue 2) Press tab again. Focus is moved to Applications link and it is spoken. Press spacebar. Press tab until focus is moved to Internet Applications link. Press spacebar. Press tab until focus is on mozilla. Press tab. Focus moves to "Back" button on toolbar. Press tab again. Foc us moves to Contents. Press F6. Focus moves to "About this article" link but nothing is spoken (issue 3). Tab to Section 1. Press spacebar. Focus is on "Table of Contents" link. Press F7. Nothing is spoken (issue 4) Press DownArrow key. Nothing is spoken. (issue 5).
I tried to reproduce all steps above, using last gnopernicus version from cvs, gnome-2-8 branch on a machine running build 20. >I heard "create window loading". I did not hear anything when window name >changed to "Help Contents". (issue 1) This is the normal behaviour. Both are window events. When these events are presented, only the last one is presented to user. All links are reported, also the text. But, when caret is on, on Desktop/Administration Guide, in the right part of the window, on text "Java Desktop" (window is small to have only this text in first line), left/righr arrows refuse to move to next line. In caret is moved down (down arrow), left/right arrow will move the caret back to first line. Also, the page for mozilla is missing on my computer (I don't know if this an instalation issue).
I will raise a separate bug about issue 1. You seem to be hitting bug #157328. This is fixed in build 23, the build on which I did the test described above.
I was only able to reproduce this bug after I focused one link from the bottom of the page. As long as I move between the text line (the text meight contains links), everything works fine. I move the focus to one link from the botom af the page and the link was reported. I moved back to the text and the text is not reported. This bug is not present in Cinnabar 20 and 19 with gnopernicus-0.9.16. Details: In order to report the text, gnopernicus shearch for a "FOCUSED" parent, in this case html-container is the parent that gnopernicus is looking for. It seems that focusing a link from the botom of the page, makes html-container to loose the "FOCUSED" state.I was only able to reproduce this bug after I focused one link from the bottom of the page. As long as I move between the text line (the text could be with links), everything works fine. I move the focus to one link from the bottom of the page and the link was reported. I moved back to the text and the text is not reported. This bug is not present in Cinnabar 20 and 19 with gnopernicus-0.9.17. Details: In order to report the text, gnopernicus searches for a "FOCUSED" parent, in this case html-container is the parent that gnopernicus is looking for. It seems that focusing a link from the bottom of the page, makes html-container to loose the "FOCUSED" state. In this moment, the link is the "FOCUSED" object. Moving back to the text does not make html-container to be "FOCUSED" again. So, the text does not have a "FOCUSED" parent. This is the reason why gnopernicus does not report it. In this moment, the link is the "FOCUSED" object. Moving back to the text does not make html-container to be "FOCUSED" again. So, the text does not have a "FOCUSED" parent. This is the reason why gnopernicus does not report it.
This problem seems to be the same like the one described in bug #143502.
Can you try with cinnabar 23 and gnopernicus 0.9.17?
Please ignore my previous comment. When I read the comments initially I thought that you were not able to reproduce the problem. On reading more carefully I see you can and have identified the probable cause of the problem.
Created attachment 34033 [details] [review] Proposed patch Does the proposed patch to gtkhtml2 fix the problem?
I am not able to test the patch on Cinnabar 23 because I can't compile gtkhtml2 and gnopernicus on this build. I tested the patch on Cinnabar 22 with Gnopernicus from CVS HEAD November 23, and gtkhtml2 form CVS HEAD November 23. The patch solves the problem.
Please refer to my comments in #2. The patch seems to fix issue 5. Issue 2, 3 and 4 still seem to be present.
I checked on Cinnabar 19 (where this bug is not present), Cinnabar 22 with the patch applied to gtkhtml2 and Cinnabar 23 without the patch. The differences are the events coming from at-spi: *issue 2: - Cinnabar 19 (issue not present): - 'focus' event for the text - 'object-link-selected' event for the text - Cinnabar 22 and 23 (issue present): - 'focus' event for 'html-container ' Moving up/down (the bug is not present in this case), two events are received from at-spi on all systems: -'focus' event for text -'object-link-selected' for text * issue 3 - same as issue 2 (the same events are received) * issue 4 - is not present, gnopernicus reports the link * issue 5 - Cinnabar 19 - not present - Cinnabar 22 - solved - Cinnabar 23 - unable to test with the patch
It looks like the fix applied for bug 156589 may be causing the problem. I will investigate.
Created attachment 34067 [details] [review] Updated patch The updated patch fixes problems 2 and 3. the change is to connect to the grab_focus signal after it has done its work. Issue 4 is still present. I will raise a separate bug about that.
Patch committed to CVS HEAD.