169995 - Location field does not have the input focus when a new window is created

Status: VERIFIED DUPLICATE of bug 159814

(Camino Graveyard :: Location Bar & Autocomplete, defect)

Description

[Marc Pawliger]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20020919
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20020919

Location field does not have the input focus when a new window is created.  You
need to press Cmd-L to move the focus there.

Reproducible: Always

Steps to Reproduce:
1.Open a new browser window
2.Note the keyboard focus is on the Bookmarks Toolbar and not the address


Actual Results:  
Keyboard focus was on the Bookmarks Toolbar

Expected Results:  
Keyboard focus should have been in the address field so I could immediately type
a URI

Comment 1

[Greg K.]

Location field has focus when the new window or tab is blank; content area has
focus when not blank. This is by design.

Comment 2

[Marc Pawliger]

Then this bug should be retitled to be: location field does not have input focus
by default for a new, blank, window.

A new, blank, window (created via File> New Window) has the focus on the first
Bookmarks Toolbar item.  So if I were to select File> New Window and start
typing I would hear beeps since the first Bookmarks Toolbar does not accept any
keyboard input except arrows, Tab, Shift/Tab and Enter.

This is all for 2002092104

Comment 3

[Greg K.]

WorksForMe using Chimera/2002092104 on 10.1.5.

Comment 4

[Marc Pawliger]

This was seen under OS X 10.2.1

Comment 5

[Henri Sivonen (:hsivonen)]

Confirmed in 0.6 on 10.2.1. Not only should the location bar get focused, but
the contents should be selected, too.

Comment 6

[Mike Pinkerton (not reading bugmail)]

problem is, when the homepage finishes loading, it takes focus. in fact, a lot
of people like that it has focus so they can use keys to scroll it w/out having
to do anything.

not quite sure how to get around this.

Comment 7

[Marc Pawliger]

Correct, for a new page with content giving focus to the homepage is arguably
the correct behavior.  However my Home Page preference is empty.  When I create
a new window or click on the app icon in the dock to get a new window if one is
not open, there is no content for keys to affect.  The only logical place for
the keyboard focus to go is the location field.

Comment 8

[Mike Pinkerton (not reading bugmail)]

we already move focus to the url bar if your homepage is "about:blank", we
should also do it if your homepage is "". that's a bug, but probably outside the
scope of what this bug is requesting. maybe you should file a new one.

Comment 9

[Mike Pinkerton (not reading bugmail)]

i just tested it, if the url field is blank (no text) and you tell it to load
the homepage when opening new windows, we put the focus in the url bar.

i have seen cases where focus is on the bookmarks toolbar if you have the system
pref set to focus all items instead of just text fields, but turning that on
still gives me the focus in the url bar in new windows. I have to open a window
with cmd-click to get the focus to appear on the bookmarks toolbar.

so we definately like to focus the first item of the bookmarks toolbar, but only
in certain cases with certain system prefs set.

Comment 10

[Marc Pawliger]

I never knew about the about:blank hack.  My homepage was set to empty/none
because that's what gets put in the Internet Config preference when you click
Use None for the IE Home Page preference.  Fortunately IE also knows about
about:blank so I can use it for both browsers (yes, sometimes I need to use IE).
 I think this bug can be re-cast to mean "treat empty/none equivalent to
about:blank for new pages" without deviating from the original report of the
reported behavior.  I defer to your judgement, however, whether a new bug is needed.

Comment 11

[Chris Casciano]

this looks to me like a dupe of bug 159814

Comment 12

[sairuh (rarely reading bugmail)]

dupping.

*** This bug has been marked as a duplicate of 159814 ***

Comment 13

[sairuh (rarely reading bugmail)]

v dup.