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)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
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.