GNOME Bugzilla – Bug 356041
GNOME Help (yelp) is inaccessible
Last modified: 2008-09-15 17:43:37 UTC
Please describe the problem: Orca fails to read the revious link in yelp. Steps to reproduce: 1. Enable desktop assistive support. 2. Run orca screen reader. 3. Invoke desktop helper in Launch menu->Help. 4. Go to theOverview of Accessibility page. 5. Press Tab to move focus to the previous link "Introduction to Accessibility" at the bottom of right pane. 6. Press Tab again to move focus onto the next link "Configuring the Mouse and Keyboard". Actual results: Nothing will be reported after step 5 while the link will be reported after step 6. Expected results: The link should be reported by orca after step 5 and step 6. Does this happen every time? Yes. Other information: This bug can be found with orca1.0.0 and gnome2.14.
Tracking.
This is indeed an important bug. The desktop helper (yelp) uses the Gecko rendering engine. Since we're going with Firefox 3 for accessibility to HTML content, we will get much better access to yelp once it moves over to the newer Gecko rendering engine from Firefox 3. Until that time, we will postpone addressing this bug.
> Since we're going with Firefox 3 for accessibility to HTML content, we will get > much better access to yelp once it moves over to the newer Gecko rendering > engine from Firefox 3. Until that time, we will postpone addressing this bug. Based upon this, I'm going to mark this as [blocked], indicating we are waiting for yelp to migrate.
Removing target milestone from [blocked] bugs. We have little control over them, so we're better off letting priority and severity be our guide for poking the related components.
Created attachment 101997 [details] Script which replacesYelp and allows to display Gnome help screens with Firefox 3 or Lynx Here's a script from a community member that might help us for a while. http://mail.gnome.org/archives/orca-list/2007-December/msg00199.html: "As Yelp is not accessible now, I wrote a small script which replaces Yelp and allows to display Gnome help screens with Firefox 3 or Lynx. I tested it on both my PLD Linux box and fresh Ubuntu 7.10 installation - seems to be working. You can download this script from http://www.polip.com/ayer.tgz and follow instructions in README file. At now this script works only with gnome help (not info and man pages) but I think it's most important, as both info and man should be accessible from terminal. Error messages are spoken directly by Orca. It's my first program written in Python... :) Bohdan R. Rau (sorry for bad English but it's not my native language)"
The blocking bugs have been marked as FIXED. We need to figure out how to test the fixes.
Dear Will and another Orca developers! The Firefox 3.0 final version is coming out. Possible upgrade Yelp Gecko engine with newest version? Will working better the structural navigation with help topics this step? Bohdane script is very good with normal help operations with any applications, but for example the Ubuntu Help Center topics is not converted this script, and it is important topics. If the python script is /usr/bin/yelp command, the help center topics is not displayed. I tryed solve the problem with this steps: 1. Rename the new /usr/bin/yelp python script (Bohdane script) with /usr/bin/yelp2 2. Deleted the /usr/bin/gnome-help simbolic link. 3. Make a new simbolic link with this command: ln -s /usr/bin/yelp2 /usr/bin/gnome-help 4. Copying /usr/bin/yelp-original /usr/bin/yelp When any application click the help menu item, the help topic converting automaticaly and displaied with Firefox web browser. But the Ubuntu Help Center menu item (/system menu) is displayed help topics with yelp application. Attila
Marking this for 2.24.0 since yelp has apparently moved to Gecko 1.9 (see bug #484991 and bug #499744). At a minimum, we need a kind soul to try the new yelp out with Orca.
Sorry -- making that [to confirm] and "---".
I just took a look at this on one of my Intrepid machines. The good news is that Accercising Yelp presents the sorts of Gecko-y things I expect to see (yea!). The bad news is that Orca is not JustWork(tm)ing with Yelp now. In fact, it's not really working at all with Yelp. :-( As an experiment, I tried changing the mapping in settings.py from Mozilla to Gecko (as we current give up and try GAIL). That seems to force the correct toolkit script to be used, but we still aren't working with Yelp. My very strong suspicion is that some fundamental methods (e.g. inDocumentContent) will need to be overridden in a yelp-specific script -- just like we had to do in the Thunderbird script. Targeting this for 2.23.90: * It needs doing (hopefully it will be easy, but ya never know) * Changes made to the Gecko toolkit now impact Thunderbird AND Yelp. It would be nice to get some Yelp regression tests written sooner rather than later to ensure that the remainder of the Gecko work done for this cycle (and beyond) doesn't break Yelp access.
Created attachment 115065 [details] debug.out from launching yelp At line 88: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vvvvv PROCESS OBJECT EVENT window:activate vvvvv OBJECT EVENT: window:activate detail=(0,0) ---------> QUEUEING EVENT object:state-changed:active app.name='yelp' name='Loading...' role='frame' state='active enabled resizable sensitive showing visible' relations='' Script mapping for yelp is Mozilla Looking for script at orca-scripts.Mozilla.py... ...could not find orca-scripts.Mozilla.py Looking for script at scripts.Mozilla.py... ...could not find scripts.Mozilla.py Looking for script at scripts.apps.Mozilla.py... ...found scripts.apps.Mozilla.py NEW SCRIPT: yelp (module=orca.scripts.apps.Mozilla) Orca is controlling the caret. [...] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ That looks promising. What follows are several accessible-name change events. Most of those seem harmless and have app.name of yelp, which is good. The last of the sane events is at line 146: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vvvvv PROCESS OBJECT EVENT object:property-change:accessible-name vvvvv OBJECT EVENT: object:property-change:accessible-name detail=(0,0) app.name='yelp' name='Ubuntu Help Center' role='frame' state='active enabled resizable sensitive showing visible' relations='' ^^^^^ PROCESS OBJECT EVENT object:property-change:accessible-name ^^^^^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Then at line 154 I see: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vvvvv PROCESS OBJECT EVENT object:property-change:accessible-name vvvvv OBJECT EVENT: object:property-change:accessible-name detail=(0,0) ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add app.name='' name='Ubuntu Help Center' role='document frame' state='active enabled focusable horizontal opaque sensitive showing visible' relations='node child of embeds' NEW SCRIPT: (module=orca.default) ^^^^^ PROCESS OBJECT EVENT object:property-change:accessible-name ^^^^^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'm still debugging/trying to wrap my head around this, but it seems that because the app associated with the document frame has no name (or maybe is null) we get yet another script -- based on default rather than on the Gecko toolkit script. Brilliant insight is welcome as always. :-)
More data.... I'm poking at this with Accerciser. It seems that getApplication() normally returns an application, but in Yelp it returns an accessible. I suspect all bets are off at that point. :-( Will: YAYB or something we should try to be clever about (or both)?
I just tried "being clever" <insert snarky comments here>. :-) I thought we could check to see if the object returned by getApplication() was indeed an application rather than an accessible. If not, get the application accessible by ascending the hierarchy and then use queryApplication() to get the accessible Application interface. It works for some items (like the Yelp frame), but it fails for other items (seemingly anything within the document frame) with a not implemented error.
Definitely a nasty bug -- I've opened yelp bug #545162 to track this. I'll also contact the Gecko folks to see if there's anything special that needs to be done to hook up a document frame to a GTK+ hierarchy.
Created attachment 116513 [details] [review] work in progress only This is here for safe keeping primarily. And also as an indication to Will as to where things are. * Lots of defunct objects * Objects with zeroed-out extents (more so than we're accustomed to) * Interesting table hierarchy for table of contents on pages * Etc., etc. Also not saying this patch is the right thing to do. I'm just trying to get things working and sort out where things are failing. Finally, Ginn's patch helps a ton (thanks Ginn!!). But often I'm seeing the app switch from being Yelp to being nameless at which point all bets are off. Your mileage will vary, but for me, starting Yelp first and then starting Orca seems to be more reliable (i.e. strictly from the point of testing this patch, which you shouldn't do because it's not ready for testing. :-))
Created attachment 118137 [details] [review] Patch to hopefully prevent the no-name issue > I'm seeing the app switch from being Yelp to being nameless This patch builds upon the previous patch. It took a hell of a lot of debugging, but it seems as though this section of code in the prior patch was tickling some sort of bug somewhere which would result in the no-name problem: + elif role == pyatspi.ROLE_FRAME: + # The window was just activated. Look from the top down, + # looking at the current Yelp hierarchy for now (until we + # work out exactly what's going on). + # + roleList = [pyatspi.ROLE_FILLER, + pyatspi.ROLE_SPLIT_PANE, + pyatspi.ROLE_FILLER, + pyatspi.ROLE_DOCUMENT_FRAME] + for role in roleList: + for child in obj: + if child.getRole() == role: + if role == pyatspi.ROLE_DOCUMENT_FRAME: + return child + else: + obj = child + break This patch merely just returns None instead of doing this logic and avoids tickling the no-name bug. I haven't tried to replicate this section of code in a simple test app for bug #545162 yet, and I'm also not sure of the implications of just returning None. But, it took so long to actually discover this, I need to post this patch before I forget about it. :-)
Created attachment 118183 [details] [review] Slightly modified patch against latest trunk This is just a quick re-diff against the latest trunk. I also commented out the print's. Seems to work OK. If we can't do any better, and this pylint's/tests well, I'd be happy with it for 2.24. I'll still poke more at it, though.
Still looking at this. One "I forgot to mention" and one question so far: 1. I kept working on this after the patch I attached and then got side-tracked. Yelp sometimes identifies itself as gnome-help rather than yelp. We'll need to add mapping for that (and then ask for special dispensation I presume). 2. Does this work for you at all if you start Orca first? Yelp is still becoming nameless for me. :-(
On the nameless thing, looks like I had old cruft on this machine from when I was working on it earlier. I deleted my Orca site packages and added the mapping I mentioned in my previous comment, and things seem to be working. Sorry 'bout that! I'll play around with it a bit more, though.
Created attachment 118253 [details] [review] Deal with the frame without tickling the hierarchy and breaking everything Obsoleting my work-in-progress patch. * Deals with the app begin called gnome-help (which seems to happen if you press F1 in an app). * Deals with identifying the document frame so that we can get the caret context when the locusOfFocus is the frame (and speak the document, not have the user at the bottom of the page, etc.). Does so without tickling the hierarchy as far as I can tell. Still testing for side effects, but I think might be an improvement.
Created attachment 118276 [details] [review] slight tweak to the previous version The regression tests indicated that the previous version introduced a slight regression (occasionally shifting the visible braille to the end of the line rather than the beginning). This version eliminates that regression and, amazingly enough, still works. <grin> Committed to trunk.
Created attachment 118534 [details] debug.out showing a lack of caret-moved events when using Yelp from trunk Good news: Don checked in Ginn's patch. Yea!!! Bad news: He changed a previous hack which was causing us to get caret-moved events. This change means that things will work as expected on the initial page you are viewing. But if you follow a link and then try to Tab and/or arrow around the new content, Orca won't say a thing because we are no longer getting caret-moved events. See the attached debug.out. Note that I trimmed out the boring stuff (i.e. things working nicely on the initial page - gnome-terminal help) and then failing horribly after I pressed Return on the Introduction link. :-(
Don just committed a fix to Yelp trunk for the aforementioned issue. I've confirmed that we are now getting the correct events even after one presses Return on a link within Yelp. Yea! All things being equal, especially for an initial stab at providing access to Yelp, things are looking pretty good. Seeing as how GNOME Help (yelp) is no longer inaccessible, closing this one as FIXED. We can open up new, specific bugs for issues that crop up.
Created attachment 118682 [details] [review] new version of the yelp script to work with Ginn's latest patch Ginn attached a new patch to bug 545162 which makes things a lot better from our perspective: We get the events we expect, no more dramatic pauses as we wait for the timeout hack to do its thing, etc. However, the change necessitates that we do things a bit differently within the yelp script. The attached seems to work quite nicely and the changes are limited to the yelp script (i.e. no risk of last-minute breakage elsewhere). Pylints to a 10. Will, please review. Thanks!
Reopening to address the changes described in comment #24.
(In reply to comment #24) > The attached seems to work quite nicely and the changes are limited to the yelp > script (i.e. no risk of last-minute breakage elsewhere). Pylints to a 10. Looks good, and I like the note on things being snappier as well. Does it require the new patch from bug #bug 545162, though? That is, do we need to block on that until we can submit this one?
> Looks good, and I like the note on things being snappier as well. Does it > require the new patch from bug #bug 545162, though? That is, do we need to > block on that until we can submit this one? Correct. We do NOT want to commit this patch without Ginn's Yelp patch being committed.
Don committed Ginn's patch. I just committed ours. Yea! Re-closing as FIXED.