Closed Bug 139862 Opened 23 years ago Closed 18 years ago

Bringing up a new browser window should put focus in the urlbar

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
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.
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
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.
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
Also see bug 37638.
cc'ing jag and trudelle for input (jag implemented the current behavior). I'm fairly certain, though, that this was a conscious decision.
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.
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?
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. ***
*** Bug 149937 has been marked as a duplicate of this bug. ***
Blocks: 55416
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...
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.
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.
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.
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).
see also bug 141295, where focus in the content area is now erratic.
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 ?
>> 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".
Isn't this a dup of bug 54110
*** Bug 54110 has been marked as a duplicate of this bug. ***
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 :-?
*** Bug 147103 has been marked as a duplicate of this bug. ***
*** Bug 151548 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
I filed bug 192915 for the Jim's observation.
*** Bug 199334 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060918 SeaMonkey/1.5a
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.