Last Comment Bug 103284 - Tab position not moved when following relative links (to named anchors)
: Tab position not moved when following relative links (to named anchors)
: access, testcase
Product: Core
Classification: Components
Component: Keyboard: Navigation (show other bugs)
: Trunk
: All All
P2 normal (vote)
: mozilla1.0
Assigned To: Aaron Leventhal
: sairuh (rarely reading bugmail)
: Andrew Overholt [:overholt]
Depends on: 66597
Blocks: focusnav
  Show dependency treegraph
Reported: 2001-10-05 05:01 PDT by Hixie (not reading bugmail)
Modified: 2002-03-12 13:39 PST (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Hixie (not reading bugmail) 2001-10-05 05:01:24 PDT
   1. Open
   2. Hit tab until you have focussed the "Terminology" link.
   3. Hit enter (to follow the internal link to the "Terminology" section).
   4. Hit tab to highlight the "[5]" link under "child element".

   After you hit the tab in step 4, you are moved all the way back up to the
   contents list. This is very disturbing.

   I propose that the current tabbing position be moved to the target anchor
   whenever the page is scrolled by following an internal link.
Comment 1 User image Hixie (not reading bugmail) 2001-10-05 05:27:28 PDT
This bug was filed based on a comment in, part of which is 
quoted below:

On Fri, 5 Oct 2001, Charles McCathieNevile wrote:
> The user scenario is as follows:
> Open a page which contains some internal links.
> Use the keyboard (tab key for these browsers) to get to an internal link.
> Use the keyboard to follow the link to another art of the document.
> The "tab order" remains where it was, so the user tabs next to whatever was
>   the link after the one followed, not the link after the anchor that they
>   (think that they) moved to.
> The HTML 4.01 specification appears to support this behaviour or the more
> natural one (as demonstrated for example by Lynx) of placing the user in the
> tabbing order starting at the point to which they have navigated.

Comment 2 User image sairuh (rarely reading bugmail) 2001-10-05 09:24:57 PDT
keybd bav. bryner's?
Comment 3 User image Aaron Leventhal 2001-10-26 10:21:33 PDT
Hmm... I couldn't get a link bar from the test case page, even on a recent build.

Anyway, this is a tab navigation bug. -> bryner
Comment 4 User image Jesse Ruderman 2001-11-04 16:59:11 PST
Should this apply whenever I follow a link with a named anchor component, or 
only when the link and target are part of the same document?

What if javascript uses document.location.href = "#bottom" to scroll the 
document to the bottom after adding text to the bottom of the page?  Should 
that move focus to the bottom of the page, or leave it where it is?  (My code 
on immediately focuses a textbox after 
scrolling to the bottom, so it wouldn't really matter for my page.)

Will Mozilla make the focus on the named anchor visible?  This could be tricky, 
because many named anchors are empty, and some are never closed and "enclose" 
paragraphs as a result.
Comment 5 User image Aaron Leventhal 2001-11-05 09:29:51 PST
There is similar to bug 66597
(Tab should start from insertion point or beginning of select).
For example, after a find, make tab navigation relative to the last found text.

It would make sense to fix that bug first, then fix this bug by setting the
caret to the beginning of named anchor.

Comment 6 User image Brian Ryner (not reading) 2002-01-18 11:39:40 PST
-> 1.0
Comment 7 User image Aaron Leventhal 2002-02-05 15:09:10 PST
I have a fix for this now in bug 66597
Comment 8 User image Peter Trudelle 2002-02-11 13:39:09 PST
nsbeta1+ per ADT triage team
Comment 9 User image Aaron Leventhal 2002-02-11 13:52:31 PST
How can this be plused when the bug it depends on was minused?
Comment 10 User image sairuh (rarely reading bugmail) 2002-02-11 14:49:34 PST
testing this using a build from aaronl [2/8] on win2k, i crash when going thru
the original recipe at step 3 --right after hitting the Enter key when the
"Terminology" link is in focus. [side note: have got caret browsing off.]
Comment 11 User image sairuh (rarely reading bugmail) 2002-02-18 17:44:04 PST
testing using a 2/18 test build from aaronl [win2k, mozilla].

* i no longer crash at step (3), yay!
* however, at step (4) when i hit tab to go to "[5]" under "child element", i'm
brought to the "1 Basic concepts" link instead. :(

so, this still doesn't look fixed...
Comment 12 User image sairuh (rarely reading bugmail) 2002-02-18 19:28:21 PST
using an even newer test build [thx aaronl], this looks fixed.
Comment 13 User image sairuh (rarely reading bugmail) 2002-02-21 16:50:52 PST
...and still looks good w/a test build from 2/20.
Comment 14 User image sairuh (rarely reading bugmail) 2002-02-25 13:46:57 PST
works with the 2/23 test build [exciting comment, no?].
Comment 15 User image Aaron Leventhal 2002-03-09 23:27:04 PST
fix checked in
Comment 16 User image Hixie (not reading bugmail) 2002-03-10 11:29:51 PST
Shweeet! Thanks guys.

Comment 17 User image sairuh (rarely reading bugmail) 2002-03-12 13:39:09 PST
hey hixie, i cannot remember which platforms you have access to presently. but
for grins i vrfy'd this on linux rh7.2, mac 10.1.3 and win2k. yeah!

Note You need to log in before you can comment on or make changes to this bug.