Closed Bug 28580 Opened 25 years ago Closed 24 years ago

Kbd Focus should shift to main window after CR/NL

Categories

(Core :: XUL, defect, P4)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: niles, Assigned: hyatt)

References

Details

(Whiteboard: [nsbeta2-][nsbeta3+])

After manually typing in a URL and hitting the "Enter" key the keyboard focus should automatically jump to the main window. (Currently it just stays in the URL box) This is important so the PAGEUP and PAGEDOWN keys as well as the arrow keys will work without having to "click" in the main window with the mouse first.
I completely agree. IE4/5 does this. Netscape 4.x does not, and it has always annoyed me. Accepting for M15.
Status: NEW → ASSIGNED
Target Milestone: M15
*** Bug 29411 has been marked as a duplicate of this bug. ***
Nominating for beta2
Keywords: beta2
Ben, it would rock if you could throw this in.
Assignee: hyatt → ben
Status: ASSIGNED → NEW
It would be better than sex...well not quite...;-)
Move to M16 for now ...
Target Milestone: M15 → M16
*** Bug 26855 has been marked as a duplicate of this bug. ***
QA Contact: paulmac → jrgm
Yup focus should go to the page after entering a url and using enter it should do the same if they use the Search button waswell. I'm adding to spec.
Keywords: nsbeta2
Putting on nsbeta2+ radar for 5/16.
Whiteboard: [nsbeta2+][5/16]
Target Milestone: M16 → M17
I have code that should do this, but the urlbar refuses to lose focus and focus the content area. I can check in this code easily enough, but the problem with the textfield/content area focus not working is not mine. cc'ing Don for comment.
Status: NEW → ASSIGNED
Move to M19 target milestone.
Target Milestone: M17 → M19
Putting on [nsbeta2-] radar. Out for Netscape 6 RTM.
Whiteboard: [nsbeta2+][5/16] → [nsbeta2-]
This seems to work in Linux build 2000062914. Yay !!!!
Whiteboard: [nsbeta2-] → [nsbeta2-] [nsbeta3-]
Target Milestone: M19 → Future
Well, at least it works if you type in a URL in the location bar and hit return. I think it still fails if you click on a bookmark link though.
I just checked this out and there are a few things that you might want to check again. The focus should be on the first operable item, be it link or form item. And the Focus should be visable for links and form items. So if it is not visable how do you know it worked? More importiantly how does a user know it worked. This should also work for more than Linux. In linux and windows there is no visual indication of focus for links and form fields other than the cursor flashing. Focus was only visable when a form item and for windows focus to a form item could only be done by mousing there first. ( But that's another bug ) Additionally on the Yahoo site as well as others it actually still behaves like 4.x selecting the URL but doesn't show the URL selected like it does in 4.x. So when you hit the return key it takes you to the same page. There are times where that would be the first item selected in a page but not so with the example. Could we mark this getting close but not quite fixed? :-)
I'm not sure I agree that the focus should change to an operable item. If you look at the original description, what was requested was that e.g. you enter a URL and hit return, the page is rendered and you can then scroll up and down. If the first operable item was say a text box with scroll bars, wouldn't up and down just move you up and down the text box ? If so, that is not what was requested, and probably would confuse most users.
I think I understand what you are saying. Just to clarify, when a text field has focus it is not necessarily selected. If it were automatically selected it would have the problem you described but as it should only have focus (indicated in 4.X by the dotted outline and is handled with XUL now so is defined by skin)this would not occure untill the user selected it. So if the text field were the first operable item up and down arrows would work for the page as described untill the item is selected and the cursor is active. Then the nav buttons would work for the selected field. Sites or Pages can override this but we really have no direct controle over this. We just hope the designer knows what they are doing. Does this clarity?
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.
Keywords: nsbeta3
*** Bug 48379 has been marked as a duplicate of this bug. ***
blah
Assignee: ben → hyatt
Status: ASSIGNED → NEW
Target Milestone: Future → ---
This seems to have regressed badly recently. Even clicking on a link now, you have to click in the main window again before you can scroll.
cc joki & saari, same as bug 50509
Code in the presshell was restoring focus properly... darnit...
clearing nsbeta3- for triage by current owners.
Whiteboard: [nsbeta2-] [nsbeta3-] → [nsbeta2-]
Platform says Linux, this appears on Windows too.
Just to clarify, pressing return *works* on Linux (don't know about other pf's). Maybe this can be closed out in favour of bug 50509.
nsbeta3+, P4, will probably be fixed by fix for 50509
Priority: P3 → P4
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
Target Milestone: --- → M18
Status: NEW → ASSIGNED
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified fixed win2k/mac/linux 2000091212
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.