Closed Bug 44257 Opened 24 years ago Closed 23 years ago

TAB in location field moves focus to nowhere

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: lorien420, Assigned: bryner)

References

(Blocks 1 open bug)

Details

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

Attachments

(1 file)

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
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.
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
I see this on Linux build 2000062914 also. Same symptoms.
is this covered in bug 30936 ?
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
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
->saari
Assignee: joki → saari
Looks to be fixed by the batch of joki checkins
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updating QA Contact.
QA Contact: ckritzer → lorca
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 → ---
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
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.
*** Bug 55663 has been marked as a duplicate of this bug. ***
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
OK then I suggest, as somebody I think mentioned before, that the focus be sent
to the Search button. That would be quite useful.
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.
OK, on Mac 10-11-08 the TAB now does absolutely nothing.  This is terribly 
annoying-marking regression.
Keywords: regression
mozilla 1.0
Target Milestone: --- → mozilla1.0
*** Bug 54497 has been marked as a duplicate of this bug. ***
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
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...
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]
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.
target mozilla 0.9
Target Milestone: mozilla1.0 → mozilla0.9
This has been marked as an accessibility bug.
MPT has perfectly described what the correct behavior should be in his comment.
Keywords: access
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
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
Summary: TAB in location field moves focus to nowhere → [access]TAB in location field moves focus to nowhere
[already has access keyword]
Summary: [access]TAB in location field moves focus to nowhere → TAB in location field moves focus to nowhere
->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
Status: NEW → ASSIGNED
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.
Priority: P2 → P1
That's good. So you could tab out of the location bar and start scrolling.
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
Attached patch patchSplinter Review
saari, can you review this?
Looks good, tested a bunch of tabbing cases and it only looks better. r=saari
checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
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...
QA contact updated
QA Contact: gerardok → madhur
Blake, your last comment may have been fixed by the checkin to bug 77913.
verified on build 2000-06-13 and build 2001-07-09
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.

Attachment

General

Created:
Updated:
Size: