GNOME Bugzilla – Bug 423534
[pending] structural navigation should not get stuck on slashdot.org
Last modified: 2008-07-22 19:27:00 UTC
1. go to slashdot.org in firefox. 2. turn on orca's caret navigation with orca+f12. 3. be sure you are at the top of the page. 4. Attempt to move by either object or heading by using "o" or "h" respectivly You will notice that focus does not move and only says no more chunks or headings.
Mike, while I've seen this sort of thing off and on here and there -- including on slashdot, I'm not currently seeing it. When the page loads, I press Tab once to move to the OSTG link. From there, O and H work as expected. I'm using the latest Orca, Feisty, and Firefox. Are you still having this problem? If so, is it intermittent or constant? Thanks!
Saddly if I simply tab once to get into the page I still see this problem when pressing "o" for large objects until I tab past all the navigation links at the top of the page.
Okay, I was finally able to reproduce it -- and as long as I do not reload the page, I can continue to reproduce it. Reloading the page makes the problem go away for me -- seemingly until I reboot and try again. In the current "getting stuck" state, from the get-go, the official (i.e. exposed) child count of the document frame is 0. It should be 3 in the case of slashdot's current page structure. When we get a valid child count we don't get stuck; otherwise we do. On a related note, every once in a while I can reproduce this on live.gnome.org/Orca. When I can, it's the same deal: bogus child count. In addition: When I am in this state of child count bogusity, AT-POKEing minefield confirms that no children are present as far as at-spi is concerned. What is interesting is that in both of these cases (i.e. slashdot and Orca wiki), the page is arranged in sections (i.e. the immediate children of the document frame are all sections). I'm wondering if the Firefox bug -- and this seems to be a Firefox bug -- is that sometimes pages organized into sections don't fully get rendered/exposed via at-spi. Unfortunately I can not reproduce this reliably; most of the time I don't have the problem, and when I do, a page reload solves it. But I'll keep at it so that I can file the most-reproducible bug against Firefox. Will, I cannot think of a clever work-around. I tried deleting the accessible associated with the document frame and getting a new one, but the reported child count is still zero. Other ideas?
I filed a bug against Firefox here: https://bugzilla.mozilla.org/show_bug.cgi?id=376887 Mike, since you can reproduce the issue far more reliably than I can, feel free to chime in the Firefox bug. :-) Updating the summary to reflect that we are blocked.
> Will, I cannot think of a clever work-around. I tried deleting the accessible > associated with the document frame and getting a new one, but the reported > child count is still zero. Other ideas? I've got no good ideas on this one, except to do what you already did (file a bug with Firefox). :-(
The blocking bug seems to have been fixed by Aaron and Ginn effective today. I have verified that the document frame is claiming all of it's children and that we're not getting stuck on slashdot.org. Therefore I'm changing the summary/status from blocked to pending. Mike, please verify -- BUT before you do, please continue to read this comment in its entirety. <smile> Something very, very bad is going on with pages that include javascript. Slashdot happens to use javascript. The executive summary is this: 1. The offending Firefox build is the May 1st build. Before that build, it was all good. 2. Orca and the enabling of assistive technologies in GNOME have *nothing* to do with it. I disabled assistive technologies, rebooted, and the problem persisted. I filed a bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=379843 3. When I filed the bug, I thought it was just AJAX pages. In the process of testing to see if our slashdot problem was indeed resolved, I concluded that it's a more generic javascript problem. As I commented at the aforementioned Firefox bug: > Another data point: > 1. Navigate to slashdot.org > 2. Use Tab to move from link to link on the top navbar. When you get to the > final link in the navbar ("x"), press Tab once and wait. Notice how long it > takes for the focus rectangle to move off of the "x" link. Shift Tab to move > focus back to the "x" link. Again, notice the delay. > Also, with slashdot loaded, I'm seeing significant overall system sluggishness. > I then reverted back to the April 30th build and the issues (delay when > tabbing, system sluggishness) went away. Here's where I'm going with this: When you press "O" from the navbar don't expect immediate results. It might seem like Orca is getting stuck; it's not. Firefox is just grinding your system to a halt due to the javascript included on slashdot. <smile> With this in mind, Mike has the issue of structural navigation getting stuck been resolved for you? Thanks!
I am no longer able to reproduce the origional bug listed here. I am also able to reproduce the problem Joanie talks about in her previus comment but that is a completely different bug. I think it is OK to close this bug.
Thanks Mike! A recent comment on the offending javascript bug points at a possible culprit, so my fingers are crossed. Closing as NOTGNOME.