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)

x86
Windows 2000
defect
Not set
normal

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