Kbd Focus should shift to main window after CR/NL




19 years ago
18 years ago


(Reporter: Rick Niles, Assigned: David Hyatt)



Firefox Tracking Flags

(Not tracked)


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



19 years ago
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.

Comment 1

19 years ago
I completely agree.  IE4/5 does this.  Netscape 4.x does not, and it has always 
annoyed me.

Accepting for M15.
Target Milestone: M15

Comment 2

19 years ago
*** Bug 29411 has been marked as a duplicate of this bug. ***

Comment 3

19 years ago
Nominating for beta2
Keywords: beta2

Comment 4

18 years ago
Ben, it would rock if you could throw this in. 
Assignee: hyatt → ben

Comment 5

18 years ago
It would be better than sex...well not quite...;-)

Comment 6

18 years ago
Move to M16 for now ...
Target Milestone: M15 → M16

Comment 7

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


18 years ago
QA Contact: paulmac → jrgm

Comment 8

18 years ago
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. 


18 years ago
Keywords: nsbeta2

Comment 9

18 years ago
Putting on nsbeta2+ radar for 5/16.
Whiteboard: [nsbeta2+][5/16]


18 years ago
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 11

18 years ago
Move to M19 target milestone.
Target Milestone: M17 → M19

Comment 12

18 years ago
Putting on [nsbeta2-] radar.   Out for Netscape 6 RTM.
Whiteboard: [nsbeta2+][5/16] → [nsbeta2-]

Comment 13

18 years ago
This seems to work in Linux build 2000062914. Yay !!!!


18 years ago
Whiteboard: [nsbeta2-] → [nsbeta2-] [nsbeta3-]
Target Milestone: M19 → Future

Comment 14

18 years ago
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.

Comment 15

18 years ago
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 

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? :-)

Comment 16

18 years ago
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.

Comment 17

18 years ago
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

Comment 19

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

Comment 20

18 years ago
Assignee: ben → hyatt
Target Milestone: Future → ---

Comment 21

18 years ago
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.

Comment 22

18 years ago
cc joki & saari, same as bug 50509

Comment 23

18 years ago
Code in the presshell was restoring focus properly... darnit...

Comment 24

18 years ago
clearing nsbeta3- for triage by current owners. 
Whiteboard: [nsbeta2-] [nsbeta3-] → [nsbeta2-]
Platform says Linux, this appears on Windows too. 

Comment 26

18 years ago
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.

Comment 27

18 years ago
nsbeta3+, P4, will probably be fixed by fix for 50509
Priority: P3 → P4
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
Target Milestone: --- → M18


18 years ago

Comment 28

18 years ago
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 29

18 years ago
verified fixed win2k/mac/linux 2000091212
You need to log in before you can comment on or make changes to this bug.