After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 599081 - Links aren't activated if browsed to via arrows.
Links aren't activated if browsed to via arrows.
Status: RESOLVED NOTGNOME
Product: orca
Classification: Applications
Component: general
2.28.x
Other All
: Normal normal
: ---
Assigned To: Orca Maintainers
Orca Maintainers
Depends on:
Blocks: 404403
 
 
Reported: 2009-10-20 17:19 UTC by Nolan Darilek
Modified: 2010-04-15 19:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nolan Darilek 2009-10-20 17:19:40 UTC
1. Launch the latest Orca trunk as of now.

2. Launch Firefox. (I'm using 3.5X here.)

3. Ensure that caret mode is activated.

4. Browse to a page, say www.google.com. Instead of tabbing to a link, use arrows to reach it--arrow right to "Maps," for instance.

5. Press enter.

Actual result: the link is not activated.

Expected result: the link should be activated.

Notes: This appears to be a regression. If I run Orca 2.26.1 as shipped with Ubuntu 9.04, everything works fine. If I switch to Orca head, things stop working. Nothing else other than Orca versions changes between runs.
Comment 1 Joanmarie Diggs (IRC: joanie) 2009-10-23 00:52:54 UTC
I can confirm the behavior as described. Here's what's going on:

1. Our explicitly grabbing focus on links was causing Orca to get stuck when arrowing around on certain pages with strange accessible hierarchies. As I recall, facebook had one of the bizarre pages.

2. We shouldn't have to grab focus on a link anyway. The natural, expected behavior of a link is for it to claim focus when (amongst other things), the caret moves inside of its text. This is what occurs if I attempt to reproduce your steps without Orca running, as well as with Orca running but Gecko controlling the caret.

So, given that bad things were happening due to grabbing focus on a link when the user arrows around, and given that we shouldn't have to grab focus on these things anyway, we stopped doing it. :-) This was not an issue at the time because when we did a setCaretPosition (how Orca moves the caret), Firefox did the right and expected thing and the link claimed focus. The apparent regression is that we're doing a setCaretPosition and Firefox is no longer doing the right and expected thing: The link doesn't claim focus, so pressing Enter does nothing. I can confirm this using Accerciser.

Tomorrow, I'll spend a little time attempting to see if I can pin down the regression date (as the Mozilla guys will ask me to anyway), and then I'll file a bug against Firefox.
Comment 2 Joanmarie Diggs (IRC: joanie) 2009-10-23 00:55:30 UTC
Sorry for the spam. For those playing at home, it's setCaretOffset.
Comment 3 Joanmarie Diggs (IRC: joanie) 2009-10-23 14:27:22 UTC
Opened https://bugzilla.mozilla.org/show_bug.cgi?id=524115
Blocking this one.
Comment 4 Joanmarie Diggs (IRC: joanie) 2010-04-02 21:24:07 UTC
Changing the status from 'blocked' to 'to verify' because the blocking bugs are
marked as fixed.

Note: Verification doesn't necessarily mean that Orca is doing the right thing
yet; merely that in theory we should be able to implement what we need to do
because we're getting the expected events and/or other information from Firefox/Gecko.
Comment 5 Nolan Darilek 2010-04-15 19:01:41 UTC
This has been working for a while now and can probably be closed. Not sure when it began working again, but I haven't experienced it in quite some time.

Thanks.
Comment 6 Joanmarie Diggs (IRC: joanie) 2010-04-15 19:03:40 UTC
Thanks Nolan!