Closed Bug 19217 Opened 25 years ago Closed 25 years ago

Text of URL should auto-select when clicked

Categories

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

defect

Tracking

()

VERIFIED DUPLICATE of bug 37587

People

(Reporter: Bruce, Assigned: radha)

References

Details

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
Assignee: leger → radha
Status: NEW → ASSIGNED
Target Milestone: M15
*** Bug 20192 has been marked as a duplicate of this bug. ***
*** Bug 22745 has been marked as a duplicate of this bug. ***
Component: Browser-General → Selection
QA Contact: leger → elig
QA Assigning to correct party, moved to correct component.
*** Bug 24834 has been marked as a duplicate of this bug. ***
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.
OS: Windows NT → All
Hardware: PC → All
Summary: Text of URL should auto-select when clicked → [4.xP] Text of URL should auto-select when clicked
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp
Summary: [4.xP] Text of URL should auto-select when clicked → Text of URL should auto-select when clicked
Target Milestone: M15 → M17
*** Bug 33981 has been marked as a duplicate of this bug. ***
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).
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 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
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.
Rubber-stamping as verified/duplicate. Bruce, if the current resolution is dissatisactory, it may be worth talking with Brendan in bug #35787. Thanks!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.