Open Bug 188567 Opened 22 years ago Updated 3 years ago

Double-click to right of text should highlight everything.

Categories

(Core :: DOM: Selection, enhancement, P5)

Product:
Core
Component:
DOM: Selection
Type:
enhancement

Tracking

()

People

(Reporter: jasonb, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

Screenshot of WordPerfect's Click outside Selection Behavior
16.64 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030110
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030110

Now that you have to *triple* click to highlight the URL bar, with the fix for
bug 125172, it's incredibly annoying.  Double-clicking was far easier.

Rather than fight a bug which has just been fixed, I propose that it function
just as it does with the exception that double-clicking at the END of the URL
(in blank space) function as it did prior to bug 125172.

If you want to highlight just the "word" at the end you can double-click
directly on it, but clicking to the right of the text, on empty space, should
highlight everything.

A triple click is something that hardly anybody does and which should be
reserved for functions that are very seldom used.  I, for one, used to
double-click on the URL bar all the time to highlight it all and do not believe
it's so rare a browsing habit as to warrant relegating it to such an
uncomfortable mouse maneouver.  (I'd be happy with a double-click at the end.)

I would actually consider it to be a regression in the browser that there's now
no easy way of highlighting the entire URL text with the mouse.

Reproducible: Always

Steps to Reproduce:
1. Double-click the URL bar to the right of existing text.

Actual Results:  
Last "word" is highlighted.

Expected Results:  
Entire URL text should be highlighted.
Keywords: regression
Agreed.  It's very annoying to have to triple-click now.  And I know people who
have trouble with double-clicking, let alone triple-clicking.  Also, I just
tried out IE, and IE double-clicks to select words, triple-clicks to select all
the text, but only in normal text fields.  In IE's URL bar, double-click selects
all the contents.
> In IE's URL bar, double-click selects all the contents.

Really?  For me, using IE 6 (latest fixes <grin>) I only need to do a *single*
click to highlight everything.  That may be overkill (I think that double-click
is more appropriate), but it's still dramatically better than triple-click.
There is a preference to cause Mozilla to select the entire URL on a single
click.  I believe that it is on by default for windows.  This was partially
broken by a Mac fix for bug 116441 which is currently being corrected.  Any
changes should only be made with full knowledge of the existing (and
almost-existing) preferences and required multi-platform behaviour.

Given that there is an easy (one click) way of selecting the entire URL and this
should be the default behaviour for windows, I don't think any change is needed
other than the fix described in bug 116441 comment 21.
I said that a single click was better than a triple click - I didn't say that it
was acceptable.  I currently DO have the pref in place to not select the entire
text with a single click.  With a single click, I want to highlight only what I
select for copy /paste.

There still needs to be some way of getting what we had before without also
doing away with a simple select copy/paste procedure.
to aaronl
Assignee: hewitt → aaronl
I like the suggestion of Jason:
a double click in the empty space of a text box (URL or other) should select the
whole content.
Currently when you double-click in a text box (try the Summary line above), it
selects the 'nearest' word (the one at the end).
I believe it should select the content of the whole box, because that's what you
mean: you click on the content and double click, thus you want all the content...
Doesn't it sound logical?
At least it does to me :-)
BTW, I like the new behaviour for the URL, I very often change only 'one word'
in the URL line on my corporate website to get quicker access and previously it
was painful...
I think clicking _next_ to the url and clicking _on_ the url should behave
exactly the same. If I want to edit the url, I never click on it, because then
the mousecursor obscures part of the text I'll be typing. Yet sometimes you're
dealing with these incredibly long urls that prevent you from clicking next to
them. And I for one _don't_ want to have a mental model of the differences
between clicking on and clicking next to. If I have to think about what happens
when clicking on the url bar, that slows me down and I'd rather not click
anymore at all...

Then from there on there are three options for how to proceed that might make
sense depending on the single pref we have to influence behaviour.
1) - single click selects the entire line if "ClickSelectsAll" is set, or only
places focus if it isn't. 
   - double-click in both instances selects one word (current behaviour)
   - triple-click in both instances selects the entire line (current behaviour)

or probably more logical as it 'shifts' the entire cycle dependent only on the
one "ClickSelectsAll" pref:

2) - single click selects entire line if "ClickSelectsAll" is set, or only
placing focus if it isn't. 
   - double-click focuses if "ClickSelectsAll" is set, or selects one word if it
isn't set.
   - triple-click selects one word if "ClickSelectsAll" is set, or the entire
line if it isn't set.

or, seeing how no one seems to like selecting just one word:

3) - single click selects entire line if "ClickSelectsAll" is set, or only
placing focus if it isn't. 
   - double-click focuses if "ClickSelectsAll" is set, or selects the entire
line if it isn't set.
   - triple-click in both instances selects one word.

Options 2 and 3 are my favorites.

As far as I understand bug 116441, that the click after the url no longer doing
the same as clicking on the url is a regression on windows, caused by mac
behaviour, and will be patched when the proper fix for that bug is checked in.
In 1.2.1 at least clicking after the url and clickiong on the url did exactly
the same on windows.
> a double click in the empty space of a text box (URL or other) should
>  select the whole content.

Great idea!  I'd only been thinking about URLs, but I do, on a daily basis, have
to select entire lines of textboxes (to report daily bug fixes to MozillaZine
based on bug Summaries) and it would be VERY useful if I could also quickly
select the entire Summary line without having to triple-click it too.
> If I want to edit the url, I never click on it, because then
> the mousecursor obscures part of the text I'll be typing.

We're talking about a double-click here.  A single-click to the right of the
text, as you're used to, would still let you edit properly as you already do.

> Yet sometimes you're dealing with these incredibly long urls

We'd just have to live with that.  I don't find it all THAT common and I can do
a triple-click if I have to in those circumstances.  (Or, alternatively, we
could leave a few characters of white space between the end of the URL text and
the URL history down arrow, that never gets used, so that there is always
something to double-click on.)
I support item 2 in comment 7 (and item 3 might prove even better) - with click
selects all set the behaviour should be as for a normal text bok *but* with an
offset since the first click is anomolous. This is also the behaviour advocated
in bug 62491.

Current (or even position dependent) behaviour might be acceptable in the case
where click selects all is false. Howevr behaviour that depends on url length
seems unintuitive to me (user naturally always double clicks to right of url to
highlight everything - finds site that has a long url and tries to select
everything  - find they are selecting some irrelevant subset of the url).

Also note that, at present when click to select is set, a single click to the
right does not highlight everything, only focuses.
> Current (or even position dependent) behaviour might be acceptable
>  in the case where click selects all is false.

Perhaps I should have explicitly stated that this bug is relavent only in the
case where "selects all" is false via the preference.  I assumed that it would
be implicitly acknowledged given that if you DO already have it set to true then
you wouldn't be bother by the sudden lack of the old double-click behaviour.

> Howevr behaviour that depends on url length seems unintuitive to me

Read the 2nd half of comment 9 again.

> Also note that, at present when click to select is set, a single click
> to the right does not highlight everything, only focuses.

That should be discussed in a different bug.  (Although if this get implemented
it would be the perfect complement to the "reverse" behaviour of setting the
preference the other way.)
Is everyone in this bug someone who edited their user.js file and changed either
user_pref("layout.word_select.stop_at_punctuation", true/false);
or
user_pref("browser.urlbar.clickSelectsAll", true/false);

Unix is the only platform where clickSelectsAll is false by default. However, we
also have word_select.stop_at_punctuation set to false by default on Unix.

So, unless you are changing your default prefs, there is no problem.

**** Solutions ****
1. You can set
user_pref("layout.word_select.stop_at_punctuation", false);
to get your old behavior back.

or 
2. Since you're about to start typing in the URL bar anyway, why not use the
keyboard to select the URL. That avoids having to go to the mouse at all. To
select the URL, you can type either accel+L or Alt+D (as long as you're not in a
page that uses D as an accesskey, like this bugzilla page).

-> Nobody. If neither of those solutions are good enough, someone else can take
this bug. We're currently exhibiting the corret behavior on single/double/triple
click.
Assignee: aaronl → nobody
> You can set user_pref("layout.word_select.stop_at_punctuation", false);
> to get your old behavior back.

Confirmed.  This "negates" the effects of contributing bug 98546 and the entire
text is, once again, selected as before.

Removing "regression" keyword since it's possible to restore old behaviour by
setting this preference.

However, I still think that it would be useful to have the following situation:

Single-click = cursor insertion
Double-click = highlight word (stopping at punctuation)
Triple-click = highlight entire URL

Double-click to right of URL text = highlight entire URL

I don't see any way of doing that with the current prefs.
Severity: normal → enhancement
Keywords: regression
I agree with comment 13. I'll post about this feature to some russian forums and
we'll see what people think about it.
Oh, and this should also apply to regular textboxes as per comment 6 - something
which user_pref("layout.word_select.stop_at_punctuation", false); does not
modify, since spaces are not considered punctuation but "word breaks".  I agree
with that, but it means that there's no workaround for the textbox scenario.  (I
know that they've behaved that way for much longer.)
As of the 20030114+ builds, I can't get
user_pref("layout.word_select.stop_at_punctuation", false); to work. 
Double-click, once again, selects only a single word.

Is anyone aware of something that was checked in that broke this pref?
Nominating for nsbeta, since the feedback is very negative on the new tripple
clicking feature.
Keywords: nsbeta1
I don't get it... are you all gone mad here ?

The default behaviour is to select the entire address bar with a SINGLE click,
which is obviously easier than a double click. The triple-clicking feature is a
plus in case you double-click by mistake, but you will be used to it in a few
days  (hours?)
First of all, you cannot single click on the URL to the right of the text and
have it highlight everything.  Instead, the cursor is put at the end of the URL
text.  This behaviour is specified by bug 116441.  So being able to double-click
at the end of the URL and have it select everything is functionlity that does
not currently exist with ANY pref in use.

Secondly, see comment 13.
Confirming comment #16, user_pref("layout.word_select.stop_at_punctuation", 
false); does not work on Mozilla 1.3b for Win2K.  There is no way to restore 
the old behavior.
From a purely USER standpoint; the triple-click is an annoyance.  When I first
encountered it, I personally thought it was an annoying bug and didnt realize it
was by design.  I dont normally triple-click for anything, certainly not
something as common as the entire url highlight in the browser url box.   I
would like to just add a comment in support of the removal of this "feature",
and make double-click a simple highlight of the entire url.  I suppose a
single-click would just insert the cursor where you clicked.  
I whole-heartedly support dumping the rediculous tripple click to select the
whole URL bar.  This is NOT paragraph text!  After spending several days
"attempting" to tripple click the URL bar in Moz 1.3b, I'm dumping Mozilla. 
This is the most annoying behaviour I've ever run across!  I suspect due to lack
of man-power, they've just applied all text editing/selecting prefs to the whole
page, URL and all.  BIG mistake, folks.  You're going to lose users over this
one.  No one in their right mind would be tripple clicking a URL to select the
whole thing.  I've been using PC's since their inseption and can honestly say
I've never had to tripple click ANYthing for ANY reason, and I ain't going to
start now.

OK, how's this: Double click IN the URL selects a word.
Tripple click IN the URL selects the whole thing (If you've got to have it that
way).
Double click to the right of the URL selects the whole thing.

Believe me, tripple clicking is a joke and should be shunned for all eternity.
I'm another user who has been annoyed lately by the sudden increase in
difficulty in selecting the entire contents of the address bar, which I do
regularly both in order to type a new URL in place of the old one, and to copy
the current URL to paste into another document or Web form field.
The problem with this bug is that many URLs are very long. Thus the right end of
the URL is not going to be visible. Therefore, this bug will not solve the
problem for many users (low res) and/or situations (long URLs). Suggest WONTFIX,
and to back out the poor choice tripple clicking sillyess.
This is horrible! How often is selecting a "word" in the URL bar needed anyway?
I bet it's much more frequent to want to select the whole URL...

One thing that has not been mentioned is that more often than not, the last
"word" selected will just be the slash at the end of the site name. For example:

1. Enter "bugzilla.mozilla.org" in the URL bar and press enter. 
2. Bugzilla loads and the URL bar changes to "http://bugzilla.mozilla.org/".
3. Double-click to left of URL bar.
4. "/" is selected.

This is clearly useless.
> Thus the right end of the URL is not going to be visible.

Already addressed in the second paragraph of comment 9.  It would be quite easy
to leave a small margin of white space between the end of the URL text and the
history arrow.
The requested behaviour would be totally inconsistent with the rest of your
computer. When you double-click in the empty space after the end of the line
anywhere in Windows, the last word is selected, and that's what I expect.

Instead of debating here, I recommend that you focus your attention at bug
193025 (comment 16 in this bug), or learn to use the keyboard (Ctrl+L, Alt+D).

Also, bug 16203 might help you in your suffering. ;-)
> The requested behaviour would be totally inconsistent with the rest of
> your computer.

On the contrary.  The closest "comparison" we can make is to another Windows URL
bar (which is not the same as normal fields).  In such a case, we'd be talking
about IE.  In IE, any number of clicks (including double-click to the right of
the URL text) selects the whole thing.

> I recommend that you focus your attention at bug 193025

I'm the person who filed that bug. <grin>  I'll accept it as better than what we
have now, but fixing THIS bug is still what I'd prefer.  (Actually, I'd prefer
banishing the entire triple-click behaviour altogether and going back to what it
was prior to bug 125172 - but there's no point in arguing for that here in this
bug.)

> Also, bug 16203 might help you in your suffering. ;-)

How convoluted. <grin>  Bottom line here - I want to easily select the entire
URL with the mouse, not have to jump through hoops to get to that state.


> > The requested behaviour would be totally inconsistent with the rest of
> > your computer.
> On the contrary.  The closest "comparison" we can make is to another Windows
> URL bar (which is not the same as normal fields).  In such a case, we'd be
> talking about IE.  In IE, any number of clicks (including double-click to
> the right of the URL text) selects the whole thing.

Uh... yeah, you're actually right - IE is that much broken: although it does
handle individual parts of the URL as "words" WRT keyboard navigation
(Ctrl+left/right, Ctrl+Shift+left/right), it does not do so for the mouse. Also,
it makes you do a triple-click (or two clicks separated by a delay) just to
place the cursor in the line. You would want that? I hope not. IE's double-click
behaviour is redundant, because there you can use just a single-click to select
the whole URL. So, if you want to use IE-parity as an argument, then your
comment 13 is invalid. You contradict yourself. :-)

Note that I'm talking about IE 5.5, with default settings (if it has any
relevant settings, which I'm not aware of). I suppose 5.0 and 6.0 are the same
in this respect - am I wrong?

I want to be able to double-click after the end of http://www.whitehouse.gov/
and type "com" and Enter and get to the right place. ;-)
> Also, it makes you do a triple-click (or two clicks separated by
> a delay) just to place the cursor in the line. You would want that?

Hello? You do realize, don't you, that since 1.3b this is the default behaviour
of Mozilla under Windows? To place the cursor in the URL bar you have to click,
wait, and then click again. And it is horrible. :-(
> > Also, it makes you do a triple-click (or two clicks separated by
> > a delay) just to place the cursor in the line. You would want that?
> Hello? You do realize, don't you, that since 1.3b this is the default
> behaviour of Mozilla under Windows? To place the cursor in the URL bar
> you have to click, wait, and then click again. And it is horrible. :-(

Sure. But that's a completely different bug: bug 62491. You yourself have
commented there, and I agree with that comment. That bug should be fixed.
Lorenzo Colitti (comment 30)--that actually is not a regression from 1.2.  In my
experience I see that behavior long before mozilla 1.0 (see bug # in comment 31)
> So, if you want to use IE-parity as an argument

In no way. <shudder>  In point of fact, comparing what Mozilla should do with
the way something else does it is a poor argument.  The only good it serves is
to give an example.

> I want to be able to double-click after the end of
> http://www.whitehouse.gov/ and type "com" and Enter and get to the right
> place. ;-)

This bug wouldn't prevent what you want to do at all.  Just double-click on
"gov", type "com", and hit Enter.  Of course, you need to double-click on the
"word" you want to replace, not at the end of the text, but why do you need to
double-click at the end anyway?

> To place the cursor in the URL bar you have to click, wait, and then
> click again.

Just change the default behaviour with the following modification:

user_pref("browser.urlbar.clickSelectsAll", false);

Now a single click will put the cursor into the URL without selecting it.

The point here is that there should be an easy way of getting the kind of URL
selection you'd like without resorting to a series of circus contortions (triple
click).

Since we have only two different (non-triple click) methods of selecting text
(single-click and double-click) but have *3* different things we want to
accomplish (cursor insertion, "word" selection, and entire URL highlighting) the
only way of accomplishing it is if we modify the action of one of those two
types of clicks in certain circumstances.

So far the only real argument I've seen against a double-click at the end of the
URL text is at the end of comment 29 - but I'm not sure I see why a double-click
on the "word" being replaced wouldn't be sufficient.
> > So, if you want to use IE-parity as an argument
> In no way. <shudder>  In point of fact, comparing what Mozilla should do
> with the way something else does it is a poor argument.  The only good
> it serves is to give an example.

Actually, it's generally a pretty good argument. We don't want to invent new
behaviours for everything - rather, we want to behave so as to conform with what
the user is used to. Unless, of couse, such behaviour would be completely
broken, useless or even counter-productive, which would be the case with
emulating IE's URL-bar mouse-click reactions. :-)

> > I want to be able to double-click after the end of
> > http://www.whitehouse.gov/ and type "com" and Enter and get to the right
> > place. ;-)
> This bug wouldn't prevent what you want to do at all.  Just double-click
> on "gov", type "com", and hit Enter.  Of course, you need to double-click
> on the "word" you want to replace, not at the end of the text, but why do
> you need to double-click at the end anyway?

Well, when I'm selecting the last word, I'm used to having the possibility to
double-click anywhere in _or_after_ it, because it works that way everywhere else.

But OK, there's many of you. Let's do what you want, but make it a hidden pref,
off by default. All of you who want this must have tweaked your prefs already,
anyway, because otherwise you could just single-click (or double-click anywhere,
if you use Unix).
Would most of you be satisfied by bug 52784? That seems like a better solution
to me...
No - that also doesn't address the possibility of double-clicking to the right
of text box text to selected everything there too, as suggested in earlier
comments here.
I know it doesn't, but I thought that this bug was about having an easy way to
select the whole URL with clickSelectsAll=false and stop_at_punctuation=true...

If you want the requested behaviour to apply to all text and not just the URL
bar, then the Component should be changed to Selection. But, as I said before,
that behaviour would be inconsistent with the rest of the computer. And it would
be very irritating at least for me. (And if you want it to apply only to "text
box text" and not, for example, normal text on web pages, then Mozilla would be
inconsistent even with itself.)
Clickking once *outside* the text once in WordPerfect selects the whole
sentence nearest the click.

Of all the text selection fuctionalities, WordPerfect by FAR does it best of
ALL programs (incl Word and Mozilla):

Click *inside* text:
1x - places curser
2x - selects word
3x - selects sentence
4x - selects paragraph

PS. The URL should be treated as a single word (2x clicks selects entire URL)!
-> Should be Selection anyway, now that I think of it.

> And it would be very irritating at least for me.

Not with the addition of bug 194925.
Component: URL Bar → Selection
> Clickking once *outside* the text once in WordPerfect selects the whole
> sentence nearest the click.

FWIW: MSWord also behaves the same way.  Also, my "programmers" text editor,
Text Pad (http://www.textpad.com/) does an insert on a single click, highlight
word on double-click, highlight everything on triple-click - and hightlight
everything on double-click OUTSIDE of the text in the margin.
OS: Windows XP → All
Hardware: PC → All
Summary: Double-click to right of URL bar text should highlight everything. → Double-click to right of text should highlight everything.
*** Bug 196547 has been marked as a duplicate of this bug. ***
*** Bug 196566 has been marked as a duplicate of this bug. ***
*** Bug 196685 has been marked as a duplicate of this bug. ***
*** Bug 197560 has been marked as a duplicate of this bug. ***
I thought I'd mention that you can now click on the proxy icon to the left of
the URL text to highlight everything, thanks to the fix for bug 52784.  This
certainly makes life simpler, but I'd still like to see double-click to the
right implemented (it's a bit tricky to quickly "zero in" on the proxy icon).
*** Bug 200319 has been marked as a duplicate of this bug. ***
I was just told about:
user_pref("layout.word_select.stop_at_punctuation", false);
That preference is broken - you can't use it in prefs.js or user.js.  It only
works if you add it to all.js, but that will be overwritten everytime you
upgrade to a more recent build.  (Which I do at least once a day, so, for me,
it's not a usable workaround.)

While I'm here, I'll add a dependency to bug 193025 since, if it's fixed, we'll
again have a usable workaround while we wait for a real fix.
Depends on: 193025
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
As primarily a Windows user, I don't care whether a single-click or a
double-click selects the URL line, since IE will do it either way, but please
make the behavior consistent, whether the user clicks within the text or to the
right of the text. The 'long URL' and 'low resolution' problems make doing it
any other way a kludge, at best.

I understand that normally single-click should place the caret and double-click
should select the nearest word in a regular text box, but the location bar is
not a regular text box, and we're not writing an essay here. Generally speaking,
a URL is one 'word' and should be treated as such.

Either way is fine, but make the blank space behave the same. If a triple-click
was intended to be part of the UI design for Windows, there would be a
TripleClick() event on standard Windows text boxes. There isn't.

If you'd rather treat each part of the URL as a 'word', then make single-click
select all and double-click select 'words'. For those who just want to insert
something into a URL, double-click left arrow would be better than the current
behavior.

Use triple-click for the other platforms if you want, or make it a preference.
Defaulting it to OFF would be greatly appreciated on Windows, however. You will
lose users over this one. It's just too annoying as-is (in 1.3.1).

If it were up to me, I'd up the severity on this one. However, it's the only
real problem I'm currently having with Mozilla, which is good. :) I consider
this a regression, though.
As of the 2/26 build under XP I just noticed that double-clicking the URL
selects everything.  Something has changed at some point.  Either the
double-clicking behaviour has changed - or bug 193025 has been corrected.

Can anybody else confirm this and point to what's been fixed, how, and when?
I just double-checked, and this is not because bug 193025 has been resolved.  (I
changed "layout.word_select.stop_at_punctuation" to true - and double-clicking
still highlighted everything.)

I'll give everybody another couple of days to let me know if this is still not
working for you - then, if I don't hear anything to the contrary, I'm going to
remove the dependency and mark this bug as WORSKFORME.

(I have the feeling that I've subconsciously been noting this working for a
while now, but have just never actively twigged to it.)
I am using 1.6 under XP, and it does not work for me.  Double clicking only
selects whatever is after the last punctuation mark (so when looking at this
bug, double clicking to the right stops at the equals sign, highlighting
"188567" but not "http://bugzilla.mozilla.org/show_bug.cgi?id=")
Filter on "Nobody_NScomTLD_20080620"
QA Contact: claudius → selection

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: