You can't use the keyboard to tab between links on a page, or follow a link on the page by pressing Enter. This is preventing us from testing things such as the TABORDER attribute. Sample HTML to see this: <a href="http://www.mozilla.org" tabindex="1">mozilla.org<a> <a href="http://www.netscape.com" tabindex="2">Netscape<a> <a href="http://www.websitegarage.com" tabindex="3">Web Site Garage<a> <a href="http://www.aol.com" tabindex="4">America Online<a>

Agreed. I am not sure though who is implementing this (raptor side or XPFE side) or when this will be implemented, so I am forwarding to Don coz he'll know :-)

Set target milestone to M7.

We won't get to this until M11 ...

Adding Bug 16271 (Tab order of Form Controls in FORM) to dependency list; it can't be properly tested until this is fixed for certain.

It looks like TABINDEX support has received some attention lately but isn't finished yet: the testcase in bug 2642 allows TABINDEX navigation, but messes up the ordering the second and subsequent times through the sequence. Also, testing that bug was impossible without first giving focus to the page explicitly by clicking anywhere on the canvas. For those who actually *need* to be able to tab between page elements to use the browser without a mouse, this isn't good enough. This looks to be another symptom of a bug that is more general than first noted: in bug 12280, keyboard scrolling does not work until focus is given with a click. This should get fixed before bug 3593 is called fixed.

Navigator 4.7 seems to deal with the problem of getting focus onto the page without using the mouse by including the Location Bar in the tabbing sequence, before anything else. This could also work in Mozilla - but it would still be better to give the page itself focus for keyboard events once it starts loading, for the reasons given in bug 12280.

This is one part of keyboard navigation that won't make it into beta 1.

Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.

Move to M16 for now ...

Putting on [nsbeta2+][5/16] radar. This is a feature MUST complete work by 05/16 or we may pull this feature for PR2.

Move to M19 target milestone.

Putting on [nsbeta2-] radar. Removing [5/16] and [FEATURE]. would take for nsbeta3.

Nav triage team: [nsbeta3+]

It's also impossible to navigate using the keyboard in linux, and one would assume, everything else. Shouldn't the bug specify more than just NT?

Chris, we've decided to give keyboard navigation bugs lower priority. Please adjust to P2 (or lower) at your discretion.

Don't do it, Chris! I'm begging you! This makes Mozilla completely unusable for a fair number of users, myself included.

law was too nice. We demoted this during nav triage to P2, marking P2 now. Agreed that this sucks royally, but it sucks even more that in the last week our total P1 count for Don's team has grown (we are supposed to be down to 33, but are actually up to 53). At that rate, we will not ship - for anyone. Also adding keyword helpwanted because keyboard shortcuts is the #1 helpwanted request the Nav team has for mozilla.org. If we want to get this fix in, we need mozilla help or need to finish higher priority bugs first. Signed, The evil voice of reality

This is working on linux, renders rectangles around links and return visits the link. Win32 & Mac, no rectangle renders and return does nothing.

adding joki.

PDT thinks this is a P3, but it worksforme using today's Win32 build

Ah, urlbar is stealing focus. Looks like this is WFM. Click in the main body of the content to get focus, then this is working.

reassigning QA w/o even looking...

Verified

well, i cannot tab btwn links when the page has tables...eg, http://www.mozilla.org. will file a seperate bug for that (not sure if tables per se are the cause, tho'...)