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 535149 - Orca should override Home and End in Firefox 3
Orca should override Home and End in Firefox 3
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
unspecified
Other All
: Normal normal
: 2.24.0
Assigned To: Joanmarie Diggs (IRC: joanie)
Orca Maintainers
Depends on:
Blocks: 404403
 
 
Reported: 2008-05-27 20:10 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2008-06-03 20:09 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
revision 1 (3.87 KB, patch)
2008-05-28 00:18 UTC, Joanmarie Diggs (IRC: joanie)
committed Details | Review

Description Joanmarie Diggs (IRC: joanie) 2008-05-27 20:10:09 UTC
This is a spin-off bug from bug 480883.  We should override Home and End similar to the overriding we do for other caret navigation.
Comment 1 Joanmarie Diggs (IRC: joanie) 2008-05-28 00:18:44 UTC
Created attachment 111642 [details] [review]
revision 1

This hopefully will override Home and End and make things a bit more consistent.

Note:  Right now (i.e. pre-patch), when we move to the end of the line, we're not updating the braille line correctly to show the end.  And post patch, this has not changed.  After playing around with it some, I reached the following conclusion:  This issue may change for the better as a result of the fix to bug 531806.  And regardless, as discussed in the team meeting today, we really should get the text of the line one time instead of three.  See bug 535178, which I just filed.  So.... I am proposing that this patch be considered for its ability to override Home and End and that we tackle the braille issue separately.

Thoughts?

Mike please test. Thanks!
Comment 2 David Price 2008-05-28 02:07:12 UTC
Should the nonfunctionality of page up and page down be added to this bug? Or, should I file another bug for that?
Comment 3 Joanmarie Diggs (IRC: joanie) 2008-05-28 02:28:00 UTC
Another bug please.   What the patch here does is merely moves to the beginning/end of the line which we've constructed.  Page Up and Page Down will likely be an entirely different matter.  Thanks much for filing these!
Comment 4 Joanmarie Diggs (IRC: joanie) 2008-05-28 05:04:56 UTC
In running the regression tests, I noticed a change.  In thinking about it, the change might be a bug fix rather than a regression. :-)  But I'll leave that up to our UI guy to decide.  Here is the situation:  We are inside of an entry that is on a page and press Control+Home.

* If Orca is not running: Control+Home does not move to the top of the page because we are in an entry.

* If Orca is running but before the patch for this bug:  Control+Home takes you out of the entry and moves you to the top of the page (i.e. currently we stomp on default behavior.  Tentatively, I offer "oops." :-) )

* If Orca is running and the patch for this bug is applied: Control+Home does not move you to the top of the page because you're in an entry and this patch checks for that before allowing Home to move you out of the entry and to the beginning of the line.

So, Mike, which is the desired user experience:  Don't stomp on default FF behavior, or ensure that Control+Home moves you to the top of the page no matter what?  Let me know and I'll either update the tests or update the patch. :-)  Thanks!
Comment 5 Mike Pedersen 2008-05-28 15:54:12 UTC
This is an improvement if you could please update the tests that'd be great.  
Comment 6 Joanmarie Diggs (IRC: joanie) 2008-05-28 16:54:48 UTC
Thanks Mike.  I updated the test in question and checked the patch into trunk.  As discussed in IRC, we'll tackle the braille issue (i.e. what we display when End is pressed) separately.  It will either be fixed as a side effect of bug 531806 or as a consequence of bug 535178.  Or both. :-)  Therefore, moving this one to pending.
Comment 7 David Price 2008-05-29 23:38:18 UTC
I think that I have found a problem with this fix. I am using Orca svn trunk, rev 3935 (checked out into a new folder). In the Thunderbird application specific preferences, I have unchecked "position cursor at start of line when navigating vertically" under the Thunderbird tab.

I opened a message written in Thunderbird and responding to a message of my own  written from within Thunderbird (I don't know if this implies html or not). I move down to a line within the message body. I hit the end key. I press the down arrow key and focus is at the start of the line--in fact, where I believe pressing the end key actually placed focus, since the first letter of the first word on the next line down is spoken after pressing the end key. If I hit the end key again, the carat remains at the start of the line and nothing is vocalized.

I have verified that moving vertically in the text does not place the cursor at the start of the line.
Comment 8 Joanmarie Diggs (IRC: joanie) 2008-05-30 00:04:25 UTC
David, looking at this and your other bugs, it seems that we're going to have to do some (and possibly quite a bit) of addition special casing line navigation just for Thunderbird.  :-(  Up until now, our focus w.r.t. Gecko has been on Firefox and not on Thunderbird: because Evolution is the official email client of the GNOME desktop and because the a11y fixes done on the Mozilla side of things have been FF focused.

So my question is this:  Does this patch make things worse in Thunderbird, or just not help in Thunderbird?

In that spirit, I'm retitling this bug to just reflect Firefox.  I promise that we'll start looking at implementing compelling access to Thunderbird soon!

Thanks!
Comment 9 David Price 2008-05-30 01:01:28 UTC
Joanie, 

The patch helps things in Thunderbird. I just found a situation where things didn't work quite as well as they should. Prior to this patch, the only way to get home and end to work was to go into carat navigation mode (pressing F7).  Could much of this be avoided in Thunderbird by pushing the user into carat navigation mode automatically? (Forgive my ignorance, but I don't know if there is a way for Orca to do that automatically.)