Closed Bug 30936 Opened 25 years ago Closed 22 years ago

[FOCUS/ACT] can't tab from last to first page element

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: jruderman, Assigned: joki)

References

Details

(Keywords: access, Whiteboard: [rtm-] relnote-user) 

In older versions of mozilla, pressing tab on the last tabbable page element
would bring the focus to the first element on the page.  In build 2000 030516,
the focus gets "lost" when I do this (can't tell what has focus, and shift-tab
doesn't bring me back).

Very similar problem with shift-tab from the first element on a page.
to me it looks like it dosen't redraw it right, but it is a bug... 
which component would this go to?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OK, I tested this and can reproduce.  Steps to test:

1. On this bug report page give focus to the COmments box.  
2. Tab through all the on page elements down to the Log Out link in the nav bar 
at the bottom of the bug report page.  
3.  Tab one more time and focus disappears.

Expected behavior 

3.  Tab one more time and focus moves to the URL bar.  
4.  Tab one more time and focus moves back into the page at teh big Moz banner 
and so on and so forth.

This bug belongs to Event Handling.  Reassigning.
Assignee: cbegle → joki
Component: Browser-General → Event Handling
QA Contact: asadotzler → janc
Sorry, forgot to include that I tested on WinNT with 3/7 build (3/8 is crashing 
at startup for me)
*** Bug 31617 has been marked as a duplicate of this bug. ***
*** Bug 25261 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Keywords: nsbeta3
Nominating for beta3
There are at least three problems causing this.

1. We broke the ability to begin tabbing when first entering a document.
2. We broke FocusAvailable in nsDocShell
3. Focus() is doing odd things and always going to the URL bar even when 
supposedly set correctly.

I have fixes for 1 and 2 in my tree with my other nsbeta3 fixes.  Still not sure 
what's causing 3 but it will probably get left to saari.
Summary: can't tab from last to first page element → [FOCUS/ACT] can't tab from last to first page element
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Correctness of support for tabbing through form fields. Please accept joki's two
fixes; hope saari can nail the third. Note that if we don't support tabbing
correctly, it harms the accessibility of the application to the disabled.
Keywords: correctness
I am the virtual joki.
Assignee: joki → heikki
Status: ASSIGNED → NEW
Per discusion with Nisheeth, marking nsbeta3+. Will email ekrock to verify.
Whiteboard: [nsbeta3+]
Bug triage with nisheeth & ekrock: nsbeta3-. Adding relnote3 keyword.
Keywords: relnote3
Whiteboard: [nsbeta3+] → [nsbeta3-]
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
*** Bug 49391 has been marked as a duplicate of this bug. ***
Updating QA Contact.
QA Contact: ckritzer → lorca
This, along with Shift-Tab not yet working, seem like a big deal to me.  Heikki, 
I know you'll want to shoot me, but nominating for RTM.  As I always say, "Ei 
mopoeille."
Keywords: rtm
Sorry, Dan.  Marking rtm-.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]
Marking with "access" keyword.
Keywords: access
Bummer.  Changing platform and OS to "All."

Think you have an idea as to when this will work? (1 month, 1 yr, don't bother 
asking anymore, etc.?)
OS: Windows 98 → All
Hardware: PC → All
Current behaviour is that if you go off the end, you end up in the URL bar, but 
you can never tab out of the URL bar (in any circumstance).

Is this really worth relnoting? So:

It seems unclear to me whether this bug requires either of a "developer" or 
"user" release note for Netscape 6 RTM. If anyone feels it does, can they please 
draft one and then nominate with the relnote-user or relnote-devel strings in 
the Status Whiteboard.

Thanks :-)

Gerv

Pressing [tab] from the last element of the page or [shift-tab] from the 
location bar makes the focus go to a strange location where pressing [tab] 
moves to the location bar and [shift-tab] makes focus get lost completely.  
Tabbing from the location bar is now covered by bug 44257.

The losing-focus bug only happens with shift-tab, which is less common than 
tab.  I don't think this bug needs a release note, but bug 44257 should get one.
Actually, I use Shift-Tab a lot-basically, you could look at it as a "what goes 
up must come down" sort of thing.  Oh, here's some funnier behavior:
1) Have focus in URL
2) <tab>
3) <shift>+<tab>
4) <shift>+<tab>
5) <tab>

and focus is back in URL bar, as expected-so the <shift>+<tab> is going of into 
limbo in one direction, but it *knows* where it should be going...Hmmmm....

Proposal for relnote:
"The <TAB> key may be used for navigating to different items on your web page, 
and <SHIFT> + <TAB> may be used to go backwards, except back into the URL 
Location Field."

The optional part "but we don't know why, really...":)

workaround that works "sometimes" for release notes:
http://www.cs.hmc.edu/~jruderma/mozilla/override-tab.html
Adding relnote-user to get this bug included in the release notes.
Keywords: relnoteRTM
Whiteboard: [nsbeta3-][rtm-] → [nsbeta3-][rtm-] relnote-user
Sending most of my events bugs to joki.
Assignee: heikki → joki
Status: ASSIGNED → NEW
Depends on: 44257
REMOVING nsbeta2/3 and replacing with nsbeta1 KW.  Also clearing 
Status Whiteboard of nsbeta2/3 result.  Could we do better than "Future" 
on this one?  Would be nice....:)
Keywords: nsbeta3 → nsbeta1
Whiteboard: [nsbeta3-][rtm-] relnote-user → [rtm-] relnote-user
Adding 4xp keyword.
Keywords: 4xp
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Dan, are you doing tabbing/focus now, can you take this?

nsbeta1-, but nominating for nsCatFood.
Keywords: nsbeta1 → nsbeta1-, nsCatFood
QA contact updated
QA Contact: gerardok → madhur
This appears to be fixed in the forward direction.

Can someone else verify this?
It's fixed in the forward direction, except that the document itself is between
the last element on the page and the location bar, which makes it look like
you've lost focus when you tab from the last element of the page.  The document
should be between the location bar (or some other frame) and the first element
on the page, if for no other reason than to make it easier to tab to the
document object on framed pages.
QA Contact: madhur → rakeshmishra
On MOZILLA_1_0_RELEASE cvs tag build, this bug is still present. 

We use a remote controler to send Tab and Shift-Tab to a full screen browser
with custom focus ring.

It is disappointing for the user to see the focus ring disappear at the end of
the page.

If someone can give me some technical infos, I can try to fix it. 
This bug certainly wouldn't be present in the form described here.  What I see
when tabbing past the last link is that focus goes to the URL bar.  Is there a
specific page where you're seing this problem?
This is a fairly old report. I am not seeing this behavior with Mozilla 1.0 
Release Candidate 1 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) 
Gecko/20020417. Tabbing from the last link indeed cycles around to the address 
bar.
marking worksforme, today's trunk build, win2k.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
QA Contact: rakeshmishra → trix
verifying wfm as per comments
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.