Closed
Bug 139862
Opened 22 years ago
Closed 18 years ago
Bringing up a new browser window should put focus in the urlbar
Categories
(SeaMonkey :: UI Design, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: mscott, Assigned: marlon.bishop)
References
(Blocks 1 open bug)
Details
Build ID: 2002042403 (trunk) Whenever I try to bring up a new browser window (usually by Ctrl-N), it's not clear what part of that new window is getting focus. Shouldn't we always start focus off in the urlbar so the user can just start typing in the url they want to go to without having to click into the url bar or hitting Ctrl -> L? Seems like a nice cheap, convience feature. Hewitt and I were at a baseball game last night and we were talking to someone who was dowloading mozilla milestone builds and mentioned this behavior to us. I just noticed it myself now so I thought I'd track it in a bug.
Reporter | ||
Comment 1•22 years ago
|
||
correcting a typo in the subject
Summary: Brining up a new browser window should put focus in the urlbar → Bringing up a new browser window should put focus in the urlbar
Comment 2•22 years ago
|
||
I think our current behavior is to set focus in the URLbar if the default page to be loaded in the new window is about:blank and to set focus to the page otherwise.
Comment 3•22 years ago
|
||
What Boris said. CC'ing bryner (focus). My vote is that we give focus to the content area when a new window was initiated from a context menu (``Open Link in New Window/Tab'') or from the ``Open Web Location'' dialog. But we should give the URL bar focus when a user just presses Ctrl-N, Ctrl-T or selects their menu equivalents. I guess usability needs to play into this decision. Over to Marlon for UE decision.
Assignee: sgehani → marlon
Comment 5•22 years ago
|
||
cc'ing jag and trudelle for input (jag implemented the current behavior). I'm fairly certain, though, that this was a conscious decision.
Assignee | ||
Comment 6•22 years ago
|
||
if there is content coming, the focus should go there on new window - once it has loaded.. if it hasn't yet loaded we should keep the focus in URL until it has.
Reporter | ||
Comment 7•22 years ago
|
||
Marlon, how do you define "content coming"? If I hit Ctrl-N so I can type in a url, does that count as content coming since we always load new windows with the default start page? In that case, I don't think that counts as pending content. If I click on a url that causes another window to come up then that seems like a "pending content" case where focus should be in the content area. Is that what you meant or did I misunderstand?
Comment 8•22 years ago
|
||
I think the issue is that there are two types of open-window users: 1) Open a new window, type a url, hit enter 2) Open a new window, click a link on the homepage (these are the users who have a page of all the links they normally visit as their homepage) Type 1 want focus in the urlbar. Type 2 want focus in the content area (so they can scroll it). The assumption we make now is that type 1 users are likely to have about:blank as the homepage...
*** Bug 142833 has been marked as a duplicate of this bug. ***
Comment 10•22 years ago
|
||
*** Bug 149937 has been marked as a duplicate of this bug. ***
Comment 11•22 years ago
|
||
Re Comment #8, I think there's a third type of user (or at least a third use case): those who really only create new windows with "Open link in new window" or when clicking a link creates a new window. In those cases, it's exceedingly annoying to have the focus be in the URL bar because it means you can't navigate with the arrows and pg up/pg down. Logically, it's the same problem as the case where a user has their home page loading. But I can't think of any real reason that a user would want the focus in the URL bar in a window which they've specifically opened with "open link in new window." I'm sure we've been through all this in bug 37638. This could turn into an infinite loop of reversing the behavior...
Comment 12•22 years ago
|
||
Yeah, the case comment #11 outlines is not really an issue since we all agree focus should be in the content area in that case.
Comment 13•22 years ago
|
||
This is a dead snake. When users cause content to be loaded, we focus the content so that they are able to scroll it. This is the behavior expected by nearly all users nearly all the time. It is fundamental behavior in all applications that load documents in windows. If you want focus in the URL bar, set your Navigator 'startup page' pref to 'Blank', or hit Ctrl-L. This bug should be resolved WONTFIX.
Comment 14•22 years ago
|
||
EXCEPT when the uesr is presented with an error message, URL not found, etc., etc., (often happens with hand-typed URLs), in which case the user should not be forced back to the mouse. The user should simply be allowed to cancel/esc the box and the focus returned to the URL bor for entry of a corrected URL.
Comment 15•22 years ago
|
||
That sounds plausible, if the focus was in the URL field, and the user was using the keyboard to manually enter the URL, and such error messages are not displayed as content (we may be switching to that, in response to other bug reports).
Comment 16•22 years ago
|
||
see also bug 141295, where focus in the content area is now erratic.
Comment 17•22 years ago
|
||
Since the previous comments seem to have summarized the issues, I'll just make a suggestion: Why not make this bug a Request for Enhancement (RFE) for an option to give URLbar focus? It should be in the Settings UI, eventually, but for now a PREFS.JS function would suffice for us power-users. Personally, I like the URL bar to have focus too (I'm user-type #2 from comment 8) and I instinctively TAB forward if I see focus up top. But I also see the other case where I open a link in a new window and expect to scroll with the keyboard. P.S. Shouldn't the OS=All ?
Comment 18•22 years ago
|
||
>> When users cause content to be loaded, we focus the >> content so that they are able to scroll it. > EXCEPT when the uesr is presented with an error message... > in which case the user should not be forced back to the mouse That's bug 90919, "URL bar should not lose focus until (non-error) page starts to load".
Comment 19•22 years ago
|
||
Isn't this a dup of bug 54110
Comment 20•22 years ago
|
||
*** Bug 54110 has been marked as a duplicate of this bug. ***
Comment 21•22 years ago
|
||
I am a bit puzzeled about this bug. I bug 90919 handles the focus on error things, and bug 141295 handls the special cases of opening a new window via Ctrl+N or File->New Window, and the focus was taken from the URL bar for good reasons in bug 37638 then what problem does this bug cover :-?
Comment 22•22 years ago
|
||
*** Bug 147103 has been marked as a duplicate of this bug. ***
Comment 23•22 years ago
|
||
*** Bug 151548 has been marked as a duplicate of this bug. ***
Comment 24•22 years ago
|
||
I agree to #13, since I use keyboard to scroll up/down the page and currently(as of 2002101704) on loading a page from Bookmark Manager by clicking an item in it no area gets focus(I mean neither URL bar and content area acquires focus) but mouse wheel can scroll the content up/down, immediately after loading. It nearly forces mouse operation that requires pain that costs some 10 times rolling of the wheel, while it's one push of pagedown key.
Comment 25•22 years ago
|
||
So lets make it a user option. Is that reasonably doable? Me, I'm tired of continually having to shift tab - or mouse - back to the URL bar for every page.
Comment 26•22 years ago
|
||
As a side note, this bug had been fixed in Phoenix to give focus to the content area, in bug 173333. Mozilla should follow it asap, which is better than nothing, for Mozilla accepts no keyboard input at the same situation as bug 173333 in Mozilla build 2002110108.
Comment 27•22 years ago
|
||
Possible regression in 1.2.1: In prior versions, starting a new window by executing mozilla.exe with no options (i.e. from a desktop shortcut) would behave like opening a new window with Ctrl-N and place focus in the URLbar. In 1.2.1, Ctrl-N continues to put the focus in the correct place, but starting from mozilla.exe doesn't put the focus anywhere. It's not in the URLbar and the URLbar can't be reached by tabbing. It's almost as if there is NO keyboard focus at all until the mouse is clicked in the URLbar.
Comment 28•21 years ago
|
||
I filed bug 192915 for the Jim's observation.
Comment 29•21 years ago
|
||
*** Bug 199334 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 30•18 years ago
|
||
WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060918 SeaMonkey/1.5a
Comment 31•18 years ago
|
||
resolving WFM... everything is working here as intended (comment 8)
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•