STEPS TO REPRODUCE 1. Open http://www.w3.org/TR/REC-CSS1 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 "" link under "child element". ACTUAL RESULTS After you hit the tab in step 4, you are moved all the way back up to the contents list. This is very disturbing. EXPECTED RESULTS I propose that the current tabbing position be moved to the target anchor whenever the page is scrolled by following an internal link.
Keywords: access, testcase
OS: other → Windows NT
This bug was filed based on a comment in firstname.lastname@example.org, 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. See: http://lists.w3.org/Archives/Public/www-talk/2001SepOct/0023.html
keybd bav. bryner's?
Assignee: blakeross → aaronl
Component: XP Apps: GUI Features → Keyboard Navigation
OS: Windows NT → All
Hardware: PC → All
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
Assignee: aaronl → bryner
Summary: Tab position not moved when following relative links → Tab position not moved when following relative links (to named anchors)
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.
Depends on: 66597
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla1.0
Whiteboard: [Hixie-P0][Hixie-1.0] → [Hixie-P0]
I have a fix for this now in bug 66597
Assignee: bryner → aaronl
Status: ASSIGNED → NEW
nsbeta1+ per ADT triage team
Keywords: nsbeta1 → nsbeta1+
How can this be plused when the bug it depends on was minused?
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.]
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 "" under "child element", i'm brought to the "1 Basic concepts" link instead. :( so, this still doesn't look fixed...
using an even newer test build [thx aaronl], this looks fixed.
...and still looks good w/a test build from 2/20.
works with the 2/23 test build [exciting comment, no?].
fix checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Shweeet! Thanks guys. VERIFIED.
Status: RESOLVED → VERIFIED
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!
You need to log in before you can comment on or make changes to this bug.