19217 - Text of URL should auto-select when clicked

Status: VERIFIED DUPLICATE of bug 37587

(Core :: DOM: Selection, defect, P3)

Description

[Bruce Fitzsimons]

As per Nativagor and Explorer, it would be "normal" if the text of the URL in
the URL box thing (I don't know the proper name - the current location text box
at the top) selected when it was clicked.


I realise the focus is moved, but the auto-selection is mostly useful (for
copying the URL or replacing it totally) and only occasionally annoying (for
editing the current URL).


Cheers,
Bruce

Comment 1

[buster]

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

Comment 2

[don]

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

Comment 3

[Eli Goldberg]

QA Assigning to correct party, moved to correct component.

Comment 4

[Dan Erikson]

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

Comment 5

[Sean Richardson]

Actually, the auto-selection on focus change to the URL bar should happen
no matter where the click lands in the URL bar:

1. Make sure that the text in the URL bar is shorter than the bar itself
   so there is some white space to the right.
2. Click on the page.
3. Click on the URL bar to the right of the URL itself.
4. Repeat step 3.
5. Repeat steps 2 and 3.

Actual result:
No highlighting of the URL, expected in steps 3 and 5. (early-M14 build)

Expected result:
Highlighting of the URL in steps 3 and 5, regardless of where the click lands,
so long as it is in the white area of the URL bar. Clearing of the selection
in step 4. This is the NN 4.7 behavior.

Comment 6

[leger]

Setting the keyword all open [4.xp] bugs to 4xp.

Comment 7

[Kathleen :Brade]

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

Comment 8

[Kevin Puetz]

I'm going to try this after a long discussion on #mozilla. The current

comprimise behavior between those who love this and those who hate it is the

following.



focus sets full highlight *unless* the focus came from a mousedown (ie, tabbing

selects all)



if the focus came from a mousedown, the focus handler sets some sort of a flag

for a mouseup routine with the following logic (pseudocode).



if(select_on_click_pref == "on" && just_focused_flag && selection == empty)

    selection ==all;

just_focused_flag == false;



that way if the user has drag-selected a region on that click, his/her selection

stays unchanged, otherwise a single-click selects all. Those who still dislike

this (me :-) have a pref and can turn off completely (probably should default to

off on UNIX at least).

Comment 9

[Matthew T (active 1999-2002)]

A much better compromise than a pref (`hey, why is this behaving differently from 
what it does on my other computer?' ... `what, you mean there's a *pref* for 
it???' `well, of all the #@%!ing obscure things to have a pref for ...') would be 
to select the whole URL when the proxy icon is clicked, but otherwise to leave 
the location bar behaving the same way as any other text widget.


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

Comment 10

[Bruce Fitzsimons]

I understand your dislike of extra prefs, but the current behaviour of Mozilla 
is different to all other major browsers. It might be nice to think that this 
behaviour can be changed now, but you are effectively deeming that n million 
people have to relearn how the interface works.

I'm not sure who I should cite here (but rest assured this has been covered), 
but basically the Usability theory goes "keep it the same or make it noticably 
different". Currently this bug violates the evolved standard for browsers. 

While Mozilla is going to be better in lots of ways it is going to **** people 
off by making them relearn basic browser behaviour. 

The discussion was also had on IRC and a different conclusion was made. And all 
these bugs reporting the same thing keep on being raised. 

Having an exception in the code for this case is annoying for the short term 
and long term, but better a few hundred hours spent by the developers and 
testers than a few million lost by the users.

Comment 11

[Eli Goldberg]

Rubber-stamping as verified/duplicate.

Bruce, if the current resolution is dissatisactory, it may be worth talking with 
Brendan in bug #35787.

Thanks!