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)
Tracking
()
VERIFIED
FIXED
M18
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.
Assignee | ||
Comment 1•25 years ago
|
||
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
Assignee | ||
Comment 4•25 years ago
|
||
Ben, it would rock if you could throw this in.
Assignee: hyatt → ben
Status: ASSIGNED → NEW
Updated•25 years ago
|
QA Contact: paulmac → jrgm
Comment 8•25 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.
Updated•25 years ago
|
Target Milestone: M16 → M17
Comment 10•24 years ago
|
||
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
Comment 12•24 years ago
|
||
Putting on [nsbeta2-] radar. Out for Netscape 6 RTM.
Whiteboard: [nsbeta2+][5/16] → [nsbeta2-]
Comment 13•24 years ago
|
||
This seems to work in Linux build 2000062914. Yay !!!!
Updated•24 years ago
|
Whiteboard: [nsbeta2-] → [nsbeta2-] [nsbeta3-]
Target Milestone: M19 → Future
Comment 14•24 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•24 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
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? :-)
Comment 16•24 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•24 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?
Comment 18•24 years ago
|
||
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so
the queries don't get all screwed up.
Keywords: nsbeta3
Comment 19•24 years ago
|
||
*** Bug 48379 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 20•24 years ago
|
||
blah
Assignee: ben → hyatt
Status: ASSIGNED → NEW
Target Milestone: Future → ---
Comment 21•24 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•24 years ago
|
||
cc joki & saari, same as bug 50509
Assignee | ||
Comment 23•24 years ago
|
||
Code in the presshell was restoring focus properly... darnit...
Comment 24•24 years ago
|
||
clearing nsbeta3- for triage by current owners.
Whiteboard: [nsbeta2-] [nsbeta3-] → [nsbeta2-]
Comment 25•24 years ago
|
||
Platform says Linux, this appears on Windows too.
Comment 26•24 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•24 years ago
|
||
nsbeta3+, P4, will probably be fixed by fix for 50509
Priority: P3 → P4
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
Target Milestone: --- → M18
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 28•24 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•