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 firstname.lastname@example.org
QA Contact: janc → ckritzer
Assignee: joki → saari
Looks to be fixed by the batch of joki checkins
Status: NEW → RESOLVED
Last Resolved: 18 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.
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...
Keywords: relnote, relnoteRTM
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.
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.)
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
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.
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
saari, can you review this?
Looks good, tested a bunch of tabbing cases and it only looks better. r=saari
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago → 17 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
You need to log in before you can comment on or make changes to this bug.