GNOME Bugzilla – Bug 539075
Navigation problems with Firefox 3 & Aria example
Last modified: 2009-03-10 00:05:03 UTC
Please describe the problem: 1. When navigating the checkboxes in this example (see URL below), the arrow keys don't move the focus as they should. 2. After moving from the "lettuce" checkbox to the "tomato" checkbox with the tab key, typing shift-tab to return to the "eletuce" checkbox shifts the focus, in that a subsequent shift-tab moves out of the checkboxes, but the braille line and the speech output do not reflect the change. That is, nothing is brailled or spoken when the user types shift-tab to return to the "lettuce" checkbox. Steps to reproduce: 1. Visit http://test.cita.uiuc.edu/aria/checkbox/checkbox1.php 2. Navigate to the first checkbox. 3. Move to the next checkbox with tab, and type shift-tab to reverse this. 4. To demonstrate the other problem, use the up and down arrow keys in an attempt to shift focus among the checkboxes. Actual results: Nothing is brailled or spoken when the arrow keys are used; nothing is brailled or spoken when shift-tab is used to return to the "lettuce" checkbox - but see reproducability below. Expected results: The arrow keys should act as usual for navigation purposes, as should the shift-tab key to move back to the previous checkbox. Does this happen every time? The arrow key problem happens every time, but the shift-tab problem does not. Specifically, the latter problem occurs the first time this is attempted after the page has loaded, but on subsequent attempts, the "lettuce" checkbox not only gains focus after shift-tab has been typed, but this is reflected in both the speech and the braille. However, the problem can be reliably reproduced in a new Firefox session. Other information: Firefox 3rc2 (Debian Iceweasel package), Orca 2.23.4.
Created attachment 113023 [details] Orca debug log. This is a debug log of an interaction with the page in question, showing the effects of navigating among the checkboxes with the tab and shift-tab commands, and the effects of using the cursor keys. Also, upon returning from Firefox to the desktop, a Python traceback was recorded in the log. This may be a separate bug that needs to be opened. I am including that part of the session in this debug log in case it is a new issue on which a separate bug should be submitted.
Jason, would you mind trying your test case with the latest patch attached to bug #541094? For me, that solves the bulk of the issues you are reporting. Thanks! Marking this bug as a depends on bug #541094.
Version 3 of the patch attached to bug #541094 made no difference when tested with Jon Gunderson's Aria checkbox example (cited in the present bug report). However, I applied the patch to Orca 2.23.4, installed from the Debian package, rather than to the current svn release. The patch was applied cleanly to both default.py and the Gecko script. I can try again with the svn version of Orca once I have sorted out the build dependencies.
I cant reproduce the non-updating for the lettuce, tried to do this several times with a shutdown/startup of firefox. But key-up/down moves the page, but does not seem to move the orca focus. The above statements are true both with and without patch #114367. Thank you
Jon, thanks for trying this. I'm puzzled that the patch isn't changing things for you. So to be sure we're on the same page, please try this before and after test: 1. Tab to the Lettuce checkbox. 2. Right arrow a couple of times. 3. Down arrow a couple of times. Without the patch, we don't speak and braille the letters being moved to in lettuce and in the subsequent checkboxes. With the patch we do. At least on the two machines I've tried it on so far (one with the official FF3 and one with a nightly source build of 3.1). If you are seeing those changes as well, phew! :-) That means at least we're on the right track as to solving this bug and just need to work out what I'm not yet addressing. On the other hand, if you're not, then I would ask you to add some debugging lines to the Gecko.script.py's onCaretMoved() (like a print "hello world" at the very top of the method) just to be sure that the code is being called. Thanks!
Oh, Jon, one more thing. Please be sure that the caret is enabled for Firefox. Press F7 to toggle this. If you press it once and nothing happens, you've like just disabled it. If so, press it once more to get a dialog that asks if you want to enable it.
Thanks Joanie, this is what happens for me: Without caret navigation turned on, we do not read out the letters. With it turned on (thanks for the tip): 1. i can successfully navigate to the end of the label for each checkbox, but when continuing to press right arrow, the last letter of the label is repeted one extra time, then we are taken to the top of the page. 2. standing on lettuce, pressing down arrow we do arrive at tomato, but speech also says: "aria example" (bla bla) "html content" and the braille display is totally blank. Pressing down again, i land on "link to campous homepage link image iCITA link" 3. intrestingly enough, if we tabbed across to lettuce, then pressed down to get to tomato, (braille is blank and it said the stuff as above, if i dont press down key, but instead press tab, focus moves to mustard, (which is fully displayed on brailledisplay). Do you get this too?
> With it turned on (thanks for the tip): You're welcome. It would be nice if we could find a way to not make that an issue (one more thing the user has to remember to do), but that's another bug/RFE entirely and I don't know if there's something I can do about it or not. Anyhoo.... > 1. i can successfully navigate to the end of the label for each checkbox, but > when continuing to press right arrow, the last letter of the label is repeted > one extra time, then we are taken to the top of the page. Yeah, that's what I meant when I said the patch to the other bug fixed "the bulk of the problems". It seems that when exiting the checkbox focus goes back to the document frame (probably because we're grabbing focus on it; not yet sure). Because of that, the cursor goes to the top of the page. My hope is that the patch to the other bug (which addresses many other issues) is sound in general (please feel free to test the heck out of it *smile*). If so, I can check that in to trunk before tackling what's left in this bug. If I reverse the order, I'll just have to completely re-fix this bug because the other bug includes a complete re-do of onCaretMoved(). > 2. standing on lettuce, pressing down arrow we do arrive at tomato, but speech > also says: "aria example" (bla bla) "html content" and the braille display is > totally blank. That's because of the above issue I think. In comment #5 I suggested right arrowing a couple of times in Lettuce (i.e. don't arrow to the end and trigger this issue). If you do those steps, do we speak and display the items as expected with my patch? > Pressing down again, i land on "link to campous homepage link image iCITA link" Yup, because having triggered the presumed focus grab you're at the top of the document frame and the first line is empty. So down arrow takes you to what follows that empty line. > 3. intrestingly enough, if we tabbed across to lettuce, then pressed down to > get to tomato, (braille is blank and it said the stuff as above, if i dont > press down key, but instead press tab, focus moves to mustard, (which is fully > displayed on brailledisplay). I'm getting confused on this one. Is this with or without the patch? If I tab to lettuce and then press down, braille is not blank for me with my patch. Without it, it is blank. With or without the patch, if you press down arrow, the caret moved to tomato (even if we didn't speak and braille it). If from there you press Tab, you go to the next focusable item *after* tomato.
(In reply to comment #8) > > With it turned on (thanks for the tip): > You're welcome. It would be nice if we could find a way to not make that an > issue (one more thing the user has to remember to do), but that's another > bug/RFE entirely and I don't know if there's something I can do about it or > not. Anyhoo.... Maybe adding it as another tutor/recommendation string to bug 540123? but not ideal unless we can check for it in code, so we dont have to speak the message unnecessarily > > 1. i can successfully navigate to the end of the label for each checkbox, but > > when continuing to press right arrow, the last letter of the label is repeted > > one extra time, then we are taken to the top of the page. > Yeah, that's what I meant when I said the patch to the other bug fixed "the > bulk of the problems". It seems that when exiting the checkbox focus goes back > to the document frame (probably because we're grabbing focus on it; not yet > sure). Because of that, the cursor goes to the top of the page. > My hope is that the patch to the other bug (which addresses many other issues) > is sound in general (please feel free to test the heck out of it *smile*). If > so, I can check that in to trunk before tackling what's left in this bug. Ok, will have a go :) > If I reverse the order, I'll just have to completely re-fix this bug because the > other bug includes a complete re-do of onCaretMoved(). > > 2. standing on lettuce, pressing down arrow we do arrive at tomato, but speech > > also says: "aria example" (bla bla) "html content" and the braille display is > > totally blank. > That's because of the above issue I think. In comment #5 I suggested right > arrowing a couple of times in Lettuce (i.e. don't arrow to the end and trigger > this issue). If you do those steps, do we speak and display the items as > expected with my patch? with patch ... moving across to the first t in lettuce (onCaretMoved fires), then pressing down (onCaretMoved fires again), the <x> tomato blinks past very quickly, and we end up with a blank line. (left and up keys at this point dont seem to do anything, and onCaretMoved has not fired to show that the frame has got the focus after the tomato). > > Pressing down again, i land on "link to campous homepage link image iCITA link" > Yup, because having triggered the presumed focus grab you're at the top of the > document frame and the first line is empty. So down arrow takes you to what > follows that empty line. > > 3. intrestingly enough, if we tabbed across to lettuce, then pressed down to > > get to tomato, (braille is blank and it said the stuff as above, if i dont > > press down key, but instead press tab, focus moves to mustard, (which is fully > > displayed on brailledisplay). > I'm getting confused on this one. Is this with or without the patch? it is with the patch. > If I tab > to lettuce and then press down, braille is not blank for me with my patch. we are seeing diffrent here, as above, tomato blinks very quickly and then line is empty. > Without it, it is blank. without the patch, braille display still says lettuce, although as you explain below that i will actually be on tomato. > With or without the patch, if you press down arrow, > the caret moved to tomato (even if we didn't speak and braille it). If from > there you press Tab, you go to the next focusable item *after* tomato. will leave this one on the back burner for now, will go and see if i can find something for 114367.
Okay, I am now seeing some of the same issues Jon indicated. Still investigating. Removing the testing required for now.
Created attachment 114641 [details] [review] revision 1 This patch (combined with the onCaretMoved patch which was checked into trunk), solves all of the issues for me with one exception: We are not indicating the current character in braille when arrowing through the checkbox labels; we just display the indicator and label. The way we currently handle the speaking and brailling of ARIA widgets is to treat them like "default" widgets. Well, default checkbox widgets don't let you arrow through their labels. ;-) As an experiment, I bypassed the code that treats them like default widgets and we started updating the text correctly (yea!), but we stopped displaying the checkbox indicator. :-( Put another way, we might need to reconsider what we do for displaying ARIA widgets whose labels you can arrow around in. That's a bigger task, and I'll be looking at redoing the Gecko braille code soon anyway. So my suggestion is we handle everything but the indication of the current character to address this bug and open a new bug for the braille issue. Mike, please test.
Created attachment 114697 [details] Session debug log. In the session logged here, I noticed the following, after enabling caret browsing, which turned out to have been part of my problem. This is with the latest svn code and the revision 1 patch applied. 1. Up/down arrow key navigation through the checkboxes works. 2. Tab navigation through the checkboxes works, but shift-tab does not. Specifically, the braille display is updated but there is no speech output. 3. At some point during this session, I lost both braille and speech access to firefox. The only way to recover was to use alt-tab to move to another window, then a second alt-tab to move the focus back to the Firefox window. This issue has been reported on the mailing list in connection with recent svn code, so I am including the entire session debug log here in case it assists in dealing with this possibly separate bug.
Created attachment 114698 [details] Session debug log. In the session logged here, I noticed the following, after enabling caret browsing, which turned out to have been part of my problem. This is with the latest svn code and the revision 1 patch applied. 1. Up/down arrow key navigation through the checkboxes works. 2. Tab navigation through the checkboxes works, but shift-tab does not. Specifically, the braille display is updated but there is no speech output. 3. At some point during this session, I lost both braille and speech access to firefox. The only way to recover was to use alt-tab to move to another window, then a second alt-tab to move the focus back to the Firefox window. This issue has been reported on the mailing list in connection with recent svn code, so I am including the entire session debug log here in case it assists in dealing with this possibly separate bug.
Thanks Jason. Are you using the latest at-spi? In the past when I've seen tracebacks like the ones in your debug.out, updating at-spi (including pyatspi) made the problem go away. I'm afraid Shift+Tabbing amongst those checkboxes is working for me both in Hardy (with latest at-spi) and Intrepid, both with Firefox 3.0 and the latest dev 3.1. Mike could you please see if Shift+Tab in the checkboxes works for you?
I have AT-SPI 1.23.3-1 installed from the Debian package, and pyatspi 1.23.3-1. This is a recent development release. I can, of course, upgrade if there have been significant changes since then, by installing it straight from svn.
Well, the only other thing I can think suggesting you try atm is this: You indicate that it is a recent issue in Orca. Try checking out earlier revisions from trunk. If you could pinpoint the Orca revision in which things broke, that might help us get to the bottom of it. Thanks again for all your help!
I installed AT-SPI from svn, as well as Gail (I couldn't remove the Debian package of one without the other), with the svn versions under /usr/local. Unfortunately, Orca wouldn't start with these libraries in place, and nothing was written to the debug log, so I have no means of finding out why. For the moment, I've reverted to the pre-packaged versions of AT-SPI and Gail.
The reason why Gnome, and hence Orca, wouldn't start with AT-SPI from svn, was that the registry wasn't loaded, even if I created a symbolic link to at-spi-registryd in /usr/lib. For reference in relation to this bug, Gnome 2.22.2 is installed from the Debian Sid repository. I suspect version mismatches are responsible for some or all of the different results we are seeing with the test case for this bug.
(In reply to comment #18) > The reason why Gnome, and hence Orca, wouldn't start with AT-SPI from svn, was > that the registry wasn't loaded, even if I created a symbolic link to > at-spi-registryd in /usr/lib. When building at-spi, you need to specify --libexecdir when doing the autogen.sh or configure. The value you give to --libexecdir depends upon your distribution, but it should be the directory containing the at-spi-registryd that came with your distribution. Hope this helps!
This seems to work.
Thanks Mike. Jason: I realize that you're having issues/seeing a bug that we definitely need to address. Closing this bug out as FIXED doesn't mean we're not going to address them; merely that those issues are different/broader than this bug.