Closed Bug 98896 Opened 23 years ago Closed 23 years ago

tabbing shouldn't change user-changed scrolling position

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
Linux
defect
Not set
minor

Tracking

()

VERIFIED DUPLICATE of bug 23914

People

(Reporter: cesarb, Assigned: aaronlev)

References

()

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010906
BuildID:    2001090608

When the user manually changes his scrolling position on the page (be it via
PgUp/PgDn or scrollbars), pressing the tab key should select the first visible
link in the page, not the first link on the page. Same for Shift-Tab (which
should select the last visible link). After that, tabbing should be allowed to
scroll the page (via the normal order), until the user manually changes his
position (ArrowUp, for instance).

Reproducible: Always
Steps to Reproduce:
1. Go to a page longer than the brower window (if you use more than 800x600,
www.mozilla.org probably won't do; try slashdot then)
2. Select the content area (by clicking on the background)
3. Use PgDn to scroll down
4. Use Tab a few times

Actual Results:  The first link in the page was selected

Expected Results:  If the last action in the current window was not tabbing
inside the content area,
And the current tabbing focus is outside the visible portion of the content area,
Then:
    Select the first/last link in the tabbing order which is inside the visible
portion of the content area (depending on shift state).
Else:
    Select the next link to tab to using the normal algorithm.


Jumping to the beginning to the document loses the visual tracking of where we
are in the document. This means that using Tab to select a link is next to
useless unless you are using it from the beginning, and thus force keyboard
people (Space/Space/PgDn/PgUp/Arrow/Arrow/etc) to lift hands and go to the mouse
to select a link.

On the other hand, if you are already using Tab, there is no problem in it
moving the screen, since that's probably what you want.

I believe the pseudo-algorithm I gave above follows the principle of least
surprise, and that if it were implemented, I would be using the mouse a lot less :P

The same algorithm can be used without problem for tabbing in forms (like this one).
This is a dupe of 23914, which was marked WONTFIX. Bug #66597 seams somewhat
related too and that one is still alive.

I'm marking this bug a dupe of 23914.

*** This bug has been marked as a duplicate of 23914 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
> Hmmm ... I think this isn't especially helpful, and would most certainly mess
> up users with no vision at all.

> Gracefully declining.

How would it happen? Users with no vision at all would use only TAB, right? Besides,
a) It can be a pref
b) As things are now, using Tab mess up users with vision to the point it's
useless and I have to use the mouse, all the time.
Also, did we ask any blind user about it, or are we just guessing?
This isn't the case, however arguing in a bug that is resolved as a duplicate 
is absolutely useless, i'd suggest using the newsgroup npm.accessibility iirc.

vrfy dupe. fwiw some third parties might implement this and are certainly free 
to implement this for their own use.
Status: RESOLVED → VERIFIED
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.