83588 - Tabbing to URL bar should highlight all contents.

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[Jeremy Loeb (gone)]

Right now, when you tab to the URL bar, it simply places a cursor at the end of 
the URL. Instead, it should highlight the entire URL so it can be typed over.

Comment 1

[Matthias Versen [:Matti]]

*** Bug 83587 has been marked as a duplicate of this bug. ***

Comment 2

[Aaron Leventhal]

-> John Gaunt

Comment 3

[sairuh (rarely reading bugmail)]

hm, i keep thinking a bug for this already exists. jesse? [but, ya never know].

Comment 4

[Chris Hiner]

dup of Bug 37587?

Comment 5

[Boris Zbarsky [:bzbarsky]]

No.  Bug 37587 has a lot of platform argument going on whereas this one is 
likely to see a lot less opposition from the Linux camp.

Comment 6

[John Gaunt (redfive)]

looks like a call to ShowAndSelectContentsOfURLBar() from fastnav.js should do
the trick, just looking for a place to put the call.

Comment 7

[John Gaunt (redfive)]

Attachment: patch to navigator.js navigator.xul

Comment 8

[Chad Austin]

I tested it out and it works fine for me.

Comment 9

[Matthew T (active 1999-2002)]

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

Comment 10

[John Gaunt (redfive)]

It looks like the discussion in bug 28583 is for a solution in c++, but I would
mantain that the url bar is such a high profile special case of this bug that it
justifies an immediate response/solution.

The fix here is in the xul/js layer and while that may not be a great long term
solution or something that is switchable/configurable through a pref, it works
now on this glaring case of bug 28583.

Comment 11

[Manoj]

One more suggestion. Could there be a key combination to select the text in the
address bar (for instance, IE uses Alt + D to select the address bar contents,
Opera allows u to open a new page using F2) so that a new page can be viewed
without using the mouse to select the address bar text.

Comment 12

[Chad Austin]

CTRL + L should do you.

Comment 13

[jag (Peter Annema)]

r=jag if you fix the patch so the change to navigator.xul becomes a -0/+1
instead of a -1/+2 patch.

Also, if we ever agree on clicking into the urlbar to also select its contents,
this code can be replaced with a simpler onfocus handler. But blake can tell you
more about that and why it's not going to happen anytime soon...

Comment 14

[Matthew T (active 1999-2002)]

This is getting silly. In the time taken to implement this hack in various 
places (the address field, the Find dialog, the Open Location dialog, etc), bug 
28583 could probably have been fixed several times over. And this hack, like 
all those ones, will need to be backed out when bug 28583 *is* fixed.

Comment 15

[Blake Ross]

This bug is fixed with the patch in 37587.

Comment 16

[John Gaunt (redfive)]

checked in friday 29th to the trunk. letting it bake before pushing for branch (
0.9.2 ) checkin.

Comment 17

[Blake Ross]

I thought we were just going to let 37587 fix this...?

Comment 18

[lchiang]

adding vtrunk keyword to indicate the bug has been fixed on the trunk.  Bug left
open for tracking checkin to branch (nsbranch) when appropriate.

Once bug has been fixed on the branch also, pls remove vtrunk keyword.

Comment 19

[sairuh (rarely reading bugmail)]

did some quickie trunk testing [used http://bugzilla.mozilla.org as a place to
test]:

mac comm 2001.07.03.10: tabbing to URL bar highlights the contents.

winnt comm 2001.07.03.11: tabbing to URL bar highlight the contents.

linux mozilla debug from 18:30 2 july: hmm, tabbing doesn't highlight the URL
bar contents...just places the cursor at the end of the URL bar content. maybe
my pull didn't get jgaunt's checkin? i'll check once i've installed the latest
packaged trunk bits [if they're available].

Comment 20

[sairuh (rarely reading bugmail)]

duh, what i'm seeing is expected, since there's a unix pref to not select the
contents of the URLbar. /me thwaps head. okay. i had thought that that pref
would only affect *clicking* in the URLbar, not tabbing... pls correct me,
however, if the linux behavior i'm seeing for this bug is not expected.

[linux mozilla 2001.07.03.18-trunk bits show the same behavior as my debug
build. i'm assuming the comm bit will as well, but they're not available yet.]

Comment 21

[John Gaunt (redfive)]

See bug 37587, that contains a superset of this bug -- clicking and tabbing.
Default linux behavior is that selects all is off. If you look at the diff in
the bug, you'll see a pref that contols this ( somehting.clickSelectsAll ). It
is used for clicking and tabbing acutally. 

So Linux not highlighting the urlbar is OK.

Comment 22

[sairuh (rarely reading bugmail)]

thx, jgaunt! that was the bug i was thinking about...ah, memory. :)

so, removing vtrunk, since i've verified using the following comm trunk builds:

linux 2001.07.05.08: tabbing to URLbar inserts cursor at the end of the field
contents; single-clicking places the cursor where the mouse pointer is located.
[both expected by default on unix.]

winnt 2001.07.05.09: tabbing to and single-clicking in the URLbar
selects/highlights its entire contents.

mac 2001.07.05.08: tabbing to and single-clicking in the URLbar
selects/highlights its entire contents.

Comment 23

[John Gaunt (redfive)]

This bug has been fixed with the patch to bug 37587, checked into the 0.9.2
branch on wed 4 july.

Comment 24

[sairuh (rarely reading bugmail)]

verified fixed on the branch using the following comm branch builds:

linux 2001.07.09.04: tabbing to URLbar inserts cursor at the end of the field
contents. [expected by default on unix.]

winnt 2001.07.09.05: tabbing to in the URLbar selects/highlights its entire
contents.

mac 2001.07.09.03: tabbing to in the URLbar selects/highlights its entire
contents.