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)
Core
DOM: Selection
Tracking
()
M17
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
Updated•25 years ago
|
Assignee: leger → radha
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M15
Updated•25 years ago
|
Component: Browser-General → Selection
QA Contact: leger → elig
Comment 3•25 years ago
|
||
QA Assigning to correct party, moved to correct component.
Comment 5•25 years ago
|
||
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
Updated•25 years ago
|
Summary: [4.xP] Text of URL should auto-select when clicked → Text of URL should auto-select when clicked
Assignee | ||
Updated•25 years ago
|
Target Milestone: M15 → M17
Comment 8•25 years ago
|
||
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•25 years ago
|
||
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
Reporter | ||
Comment 10•25 years ago
|
||
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•24 years ago
|
||
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.
Description
•