TAB in location field moves focus to nowhere

VERIFIED FIXED in mozilla0.9

Status

()

Core
Event Handling
P1
major
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: Andrew Sayman, Assigned: Brian Ryner (not reading))

Tracking

(Blocks: 1 bug, {access, regression, relnote})

Trunk
mozilla0.9
access, regression, relnote
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [relnote-user])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
If tab is pressed at anytime while the url bar is selected the cursor moves to
the end of the url and disappears. You can still type normally, the cursor just
doesn't appear. Cursor reappears if you click on the url bar. This was found
using Mozilla M16

Comment 1

18 years ago
With 2000062808 win32 running on win95 pressing tab causes the cursor to
disappear from the url bar, as it would in a normal window that allows tab to be
used to switch between boxes and buttons. I can't type text into the url bar
when it has gone however.

Comment 2

18 years ago
It's normal that the cursor leaves the textfield, however, the next control 
should then gain the focus (in this case, it appears to be the search button).  
The tabbing order is really messed up everywhere, though.  Beth, do we have a 
bug on that?
Assignee: asa → beppe
Component: Browser-General → Editor
QA Contact: doronr → sujay

Comment 3

18 years ago
I see this on Linux build 2000062914 also. Same symptoms.

Comment 4

18 years ago
is this covered in bug 30936 ?

Comment 5

18 years ago
confirming and moving to event handling. this is possibly related to 30936,
either a depend on or a dupe. Letting event handling decide this.

I guess what should happen is that the tab in url bar causes to set focus on the
first element of the actual html page, which is 4.x behaviour
Assignee: beppe → joki
Status: UNCONFIRMED → NEW
Component: Editor → Event Handling
Ever confirmed: true
QA Contact: sujay → janc

Comment 6

18 years ago
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer

Comment 7

18 years ago
->saari
Assignee: joki → saari

Comment 8

18 years ago
Looks to be fixed by the batch of joki checkins
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 9

18 years ago
Updating QA Contact.
QA Contact: ckritzer → lorca

Comment 10

18 years ago
Does *NOT* work for me
Platform: PC
OS: Windows 98
Mozilla Version: 2000100508

Pressing tab in the URL bar makes the cursor disappear, and now you can't type
either. I don't know if thats what its supposed to be but I thought I would
reopen it so someone will look at it and decided if it is or not.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 11

18 years ago
Wait a minute-I'm not sure I understand this correctly so bear with me:
1) select text in URL field
2) <TAB> once
3) Type something (nothing happens)
4) <TAB> again
5) type something (typed text appears in URL Field along with blinking 
placeholder (blinking line/cursor)

Is this the behavior you folks are seeing?  I saw in in Linux 10/3, Win NT 10/5, 
and MacOS 10/5 builds.  If this is not the behavior you are seeing, we have a 
problem.  If it is, I don't see a problem.  If I have no clue what I'm talking 
about, could you illuminate me?  -d

Comment 12

18 years ago
That's what I see too. However, some people might argue that pressing tab in the
location bar should insert a <TAB>. I don't think the bug is fixed, since
pressing tab still causes the cursor to disappear.

Comment 13

18 years ago
*** Bug 55663 has been marked as a duplicate of this bug. ***

Comment 14

18 years ago
No, I can't agree with that.  <TAB> should send the focus trodding along to the 
next stop-there is absolutely no reason to have a <TAB> insterted into the URL 
field.

Additionally, I think that the description in (duplicate) bug #55663 (see above) 
and will change the description of this bug since that description more 
accurately reflects the problem.  The concern here is not that the cursor is 
"disappearing".  That's the focus being shifted elsewhere, and items with no 
focus have no cursor-no problem there.  The focus not properly being handed off 
to the page is the problem here.

Previous title for this bug:
"Pressing tab in url bar causes cursor to dissapear"
Fresh new title for this bug (from bug# 55663):
"TAB in location field moves focus to nowhere"
Which *really* seems to describe the problem here, rather than the cursor 
disappearing.

Additionally, cc:ing Hixie cause I don't think he gets enough e-mail.
Summary: Pressing tab in url bar causes cursor to dissapear → TAB in location field moves focus to nowhere

Comment 15

18 years ago
OK then I suggest, as somebody I think mentioned before, that the focus be sent
to the Search button. That would be quite useful.

Comment 16

18 years ago
From SimCity 2k-
"Naysayers say 'Nay'"

Sorry, but I can't agree with this one either.  It would be going against what 
everyone is used to in a browser, and while I'm all for change, doing it at the 
expense of usability is not my thing.

Also, on a more selfish note, I generally don't "Search."  I'd hate the focus 
going there-it doesn't go to the "Back" or "Forward" buttons, and I wouldn't see 
"Search" as any different.

Comment 17

18 years ago
OK, on Mac 10-11-08 the TAB now does absolutely nothing.  This is terribly 
annoying-marking regression.
Keywords: regression

Comment 18

18 years ago
mozilla 1.0
Target Milestone: --- → mozilla1.0

Comment 19

18 years ago
*** Bug 54497 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
In any toolbar, Tab should not cycle between widgets (toolbars were designed for 
mouse input, after all), but between panes. So Tab in the location field should 
give focus to the most-recently-focused item in the current page -- or, if focus 
has not been given to any element in this page during the session history, to the 
first focusable item in the (first frame of the) current page.

See also bug 31809, which is for tabbing *into* the location field.
OS: Windows 98 → All
Hardware: PC → All

Comment 21

18 years ago
fwiw, and I'm not saying I agree with this, you can navigate win32 MSWord 
toolbar's with the keyboard.  It *would* be nice if there was a way to search 
from the URL bar using just the keyboard, but I don't think being able to tab 
to the Search button is the best way to do that.  Maybe modifier+enter, hmm...

Comment 22

18 years ago
Insanely long release note item:

Pressing tab twice from the location bar returns focus to the location bar, 
making it difficult to scroll the page.  Most users can work around this by 
simply clicking on a blank area of the page.  Another possible workaround is 
hitting enter, which will reload the page and then move focus to the page.  If 
you often encounter this while opening new browser windows (and you don't want 
to have to hit enter and reload the page, you may want to add a bookmark to the 
url "javascript:document.focus();", which sets focus to the current page, and 
use this bookmark when you are stuck or lose focus.  If you don't like having 
to hit enter each time you start your browser, you may want to set your 
homepage to an alternative "blank" page, 
"data:text/html,<script>document.focus();</script>", or to a website that 
focuses a textbox wen loaded, such as http://www.google.com/.

If there is a "keyboard access" or "keyboard navigation" section of the release 
notes, then this item should go there and the part about clicking the page 
should be removed.  Alternatively, it may be appropriate to say 'for 
information on workarounds <a href="..." accesskey="z">click here</a> or press 
alt-Z' to reduce relnote clutter.
Keywords: relnote, relnoteRTM
Whiteboard: [relnote-user]

Comment 23

18 years ago
Btw, the alt-Z thing will only work if the relnotes page already has focus.  I 
can't tell if it does because PR3 crashes when I visit the page.

Comment 24

18 years ago
target mozilla 0.9
Target Milestone: mozilla1.0 → mozilla0.9

Comment 25

18 years ago
This has been marked as an accessibility bug.
MPT has perfectly described what the correct behavior should be in his comment.
Keywords: access

Comment 26

18 years ago
Blocks bug 30936, "can't tab from last to first page element".
Blocks: 30936
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

Comment 28

18 years ago
Adding this bug to the metabug for location bar focus problems.

>So Tab in the location field should give focus to the most-recently-focused 
>item in the current page -- or, if focus has not been given to any element in 
>this page during the session history, to the first focusable item in the 
>(first frame of the) current page.

It might be better to first focus the page itself to allow scrolling (and give 
an indication that the page is focused), and then on the next tab to the first 
*visible* control on the page.  See also bug 23914, "Start tabbing navigation 
from first visible element, not top".

(I don't think that a fix for this bug should be held for adding complex 
behavior like that, though.)
Blocks: 55416

Updated

18 years ago
Summary: TAB in location field moves focus to nowhere → [access]TAB in location field moves focus to nowhere

Comment 29

18 years ago
[already has access keyword]
Summary: [access]TAB in location field moves focus to nowhere → TAB in location field moves focus to nowhere

Comment 30

18 years ago
->bryner p2, not sure I understand exactly what MPT would like to happen here -
or agree with it.  Note that the only really accessible browser works as Doron
described.
->bryner, cc saari, self.
Assignee: saari → bryner
Status: REOPENED → NEW
Priority: P3 → P2
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 31

18 years ago
Don't worry about disagreeing with what I said, I disagree with it too (Aaron 
agreeing with me notwithstanding). But I don't agree with Doron either ...

With focus in the address field, pressing Tab should focus the whole of the 
(first frame of the) page. See bug 34357 for why (another accessibility issue). 
Then, pressing Tab a *second* time should focus the first link/control in that
frame/page, and so on through the links/controls.
(Assignee)

Updated

17 years ago
Priority: P2 → P1

Comment 32

17 years ago
That's good. So you could tab out of the location bar and start scrolling.

Comment 33

17 years ago
We've been working hard on a new keyboard spec, so we can get a solid grasp on
what needs to be done. Since this is a high priority bug, I ask people to review
the wording at:

http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html#initfocus

Please let me know what you think - and especially if you wish to be more
involved in accessibility and keyboard UI.
Severity: minor → major
(Assignee)

Comment 35

17 years ago
saari, can you review this?

Comment 36

17 years ago
Looks good, tested a bunch of tabbing cases and it only looks better. r=saari
(Assignee)

Comment 38

17 years ago
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → FIXED

Comment 39

17 years ago
Seems like you can't get to the urlbar anymore by tabbing from the last 
focusable content in the page with this fix.  Maybe I'm just crazy.  But that's 
another bug, anyways...

Comment 40

17 years ago
QA contact updated
QA Contact: gerardok → madhur

Comment 41

17 years ago
Blake, your last comment may have been fixed by the checkin to bug 77913.

Comment 42

17 years ago
verified on build 2000-06-13 and build 2001-07-09
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.