62491 - [clickSelectsAll] Double-click in location bar should focus without selecting

Status: RESOLVED EXPIRED

(SeaMonkey :: Location Bar, defect)

Comment 1

[Jesse Ruderman]

Triple-clicking in the location bar should put the insertion point where you 
clicked instead of selecting the entire url, because otherwise clearing the 
selection can be frustrating.  (Bug 53485 also helps make it frustrating.)

I can think of two ways to do this that would be somewhat more general, but 
neither is perfect.

- Mark the location bar as a "single-word" textbox, which would make 
triple-clicks clear the selection, make pastes including \n's strip the \n's 
instead of converting them to spaces, etc.  (Are there other "single-word" 
textboxes?)

- Make the triple-click code check whether there are multiple words.  If there 
are multiple words, select all of them; if there aren't, clear the selection 
and put the insertion point in the right place.  (This could be confusing if 
you're not sure ahead of time whether a large block of text contains spaces.)

Comment 2

[Akkana Peck]

On Unix, triple click means select line, and changing that would cause
frustration for many users.  But I agree that the current setup is probably
frustrating for Windows users who are used to clickSelectsAll.  I suggest that
triple-click should be changed to set the caret, but not select the line, only
when clickSelectsAll is set (which may soon become the default setting on Windows).

I think Anthony has the clickSelectsAll bug -- cc'ing.

Comment 3

[kinmoz]

Reassigning to [e-mail]

Comment 4

[rubydoo123]

moving to moz0.9.1

Comment 5

[Kathleen :Brade]

It seems to me (maybe I'm wrong?) that the urlbar should be able to fix this if 
so desired (check the clickCount and handle the event if appropriate)

Reassign to XPApps.

If we decide that the correct fix is in selection, reassign the bug back to 
anthonyd.

Comment 6

[Blake Ross]

Umm....I don't want to special case the urlbar more than is necessary.  I'd 
prefer that this be a basic behavior of all textfields if we're going to do 
this.  Also, it seems like we're going to do click-selects-all in the urlbar, 
at least for some platforms.  -> UI Design to sort all this out

Comment 7

[Matthew T (active 1999-2002)]

For ordinary text fields:
*   a single click should place the caret;
*   a double click should select the `word' surrounding the click position
    (e.g. double-clicking on the `w' of
    http://bugzilla.mozilla.org/show_bug.cgi?id=62491' would select `show');
*   a triple click should select the entire field contents;
*   a quadruple click or beyond should continue this cycle.

For the address field, if it is set to click-to-select:
*   a single click should select the entire field contents;
*   a double click should place the caret;
*   a triple click should select the `word' surrounding the click position;
*   a quadruple click or beyond should continue this cycle.

For the address field, if it is set to click-to-place-caret, like ordinary text 
fields, then it should behave like ordinary text fields as described above.

Comment 8

[Blake Ross]

--> URL Bar

Comment 9

[Jesse Ruderman]

Changing summary from "triple-click in location bar should act like single click
[focus without selecting]" to "double-click in location bar should focus without
selecting" to match mpt's comments in this bug.

mpt, by "a quadruple click or beyond should continue this cycle", did you mean
cycle from step 1, so that quadruple-clicking in any text field would be the
same as single-clicking?  Wordpad and Mozilla currently treat quadruple-clicking
like double-clicking for ordinary text fields.  Are you saying that should change?

Comment 10

[Matthew T (active 1999-2002)]

Actually, Mozilla currently (build 2001071309) ignores quadruple or further
clicks completely.

Here's my 2001-04-23 suggestion presented in possibly a clearer manner:

   Number of rapid
consecutive clicks   Normal text fields   Address field with clickSelectsAll
----------------------------------------------------------------------------   
             1   Place caret          Select paragraph
                 2   Select `word'        Place caret
                 3   Select paragraph     Select `word'
                 4   Place caret          Select paragraph
                 5   Select `word'        Place caret
                 6   Select paragraph     Select `word'
                 7   ...                  ...

Comment 11

[Aaron Leventhal]

alecf is on sabbatical.

-> blake

Comment 12

[Ilgaz Öcal]

as I see nothing has been done to reflect end user feedbacks for this bug, I 
remove my vote since it is nothing more than a e-mail subscription for me.

Comment 13

[Blake Ross]

Joe was dying to have these bugs. Who am I to say no?

Comment 14

[Mikel Ward]

Filed bug 125172 for consistent behavior in all text fields (according to
comment 10), *even the URL bar*.

Comment 15

[José Mª Pérez]

When the location is unfocoused partial selection of the contents requieres 3
clicks before it begins to select the proper text.

Comment 16

[Ian Nartowicz]

This bug has been completely superceded by later changes.  I suggest that it is
closed.

In particular, see bug 125172, bug 116441, and bug 188567.

Comment 17

[Jesse Ruderman]

[e-mail]: bug 125172 is about when clickSelectsAll is off, and
bug 116441 and bug 188567 are both about what happens when you click in the
empty space to the right of the URL in the address bar.  I don't see how this
bug could be "superceded" by them.

Comment 18

[Ian Nartowicz]

The fix for bug 125172 quite deliberately set the behaviour for double-clicks in
the location bar to select one word, and triple-cliks to select the whole line,
whether clickSelectsAll is on or off.  This was done after a great deal of
discussion and I cannot imagine it changing again to reflect the behaviour
requested in this bug.  At the very least, the people who made the decisions in
bug 125172 would need to be aware that this bug was going to override them. 
Click through to bug 98546 to see some more discussion and the actual patch for
this fix.

Bug 116441 is actually about Mac-specific behaviour, but contains interesting
information about how this clicking should work on Macs, and some ongoing work
to control platform differences when clicking beyond the end of the URL with
clickSelectAll on.  This would have to be taken into account before changing
triple-click behaviour.

Bug 188567 is basically requesting a workaround for people who don't like having
to triple-click to select the whole URL (following the fix for bug 125172).  I
mention it because those people are really wanting the same behaviour you
request here: double-click selects the whole URL and triple-click goes back to
inserting the caret.

Anyway, my point is: this bug can no longer be fixed without breaking other bugs
that were raised after this one.  That is why I used the word superceded.  I'm
just trying to bring things up to date here so that this doesn't sit around for
another two years assigned but not going anywhere.

Comment 19

[Jesse Ruderman]

>The fix for bug 125172 quite deliberately set the behaviour for double-clicks in
>the location bar to select one word, and triple-cliks to select the whole line,
>whether clickSelectsAll is on or off.

Bug 125172 is only about the case when clickSelectsAll is off.  There was no
"fix for 125172"; it was fixed as a side-effect of the fix for bug 98546.  Nor
was there any real discussion or decision-making in bug 125172.

>Click through to bug 98546 to see some more discussion and the actual patch for
>this fix.

I can't find the discussion about how double-clicking in an unfocused address
bar should work in bug 98546.  I tried searching for "address" and "url".  (When
you refer to comments in other bugs rather than other bugs as a whole, as you
did with bug 98546 and bug 116441, please include comment numbers.  Bugzilla
will create a link to a specific comment if you say "bug x comment y".)

Comment 20

[Lorenzo Colitti]

Excuse me for butting in at this late stage, but when I saw this I couldn't
believe my eyes. I just moved from 1.3a to 1.3b on Windows and realized that to
place the caret in the location bar (which is possibly the most frequent
operation that involves the location bar) now requires two separate single clicks.

This is because if clickSelectAll is on (e.g. by default on Windows), a single
click selects the whole URL, a double click selects a "word", a triple click
selects the URL again, etc. So if you merely want to place the caret in the
location bar you have to click (URL is selected), WAIT, and click again. For me,
this is horrible. I don't want to have to wait to be able to edit the current
URL! If I want to select a word, I can always click and drag...

I think that most people will agree with me in saying that simply placing the
caret in the URL bar is much more frequent than wanting to select a word in the
URL, and so should be easier and quicker.

So, could we make it so that double-clicks should only select words if
clickSelectAll is off? Then with clickSelectAll on, we could have:

 - single click selects
 - double click places caret
 - triple click selects word (if you like)
 - successive clicks toggle between word and URL (if you like)

As reported in bug 188567 comment #20, setting
layout.word_select.stop_at_punctuation to false doesn't solve the problem. A
double click still selects the word.

Comment 21

[Vaclav Dvorak]

I don't think this is an enhancement - it's a genuine bug, though perhaps of
minor severity according to the definition ("easy workaround is present" -
click, wait, click). Comment 10 is nearly right, except that you should probably
substitute "line" for "paragraph", because that's what triple-click currently
selects in text, and except that quadruple and further clicks are not ignored
anymore (but who cares).

Changing severity and also resetting milestone, because this bug has recently
been made more visible (see bug 188567 comment 30). Nominating for nsbeta1.

Comment 22

[Julien Bidault]

I do agree with all Lorenzo said.

Under windows (all version), the standart behaviour is the one he explained :
- first clic : select the whole line
- second clic : place the caret
- third clic : select the word you're on

Current behaviour is very weird, and very time consuming : sometimes, you have
to clic a lot to be able to place the caret...which is such a common operation.

The two things you do the more with an adress bar in a browser are : 
- changing the whole url to type a new one
- modifying an existing one up to a reasonnable extend that include inserting
the caret and deleting a large part of the url to rewrite it

I would even say that with the tab function, you modify more than you change
completely (it's easier to make a CTRL+T to have a fresh adress bar, plus, you
don't loose the previous windows)

So I do think the current order is irrelevant

(PS : this behaviour is anoying at least since the 1.3a, and is still the same
in 1.3b and 1.4a)

PPS : change OS to all, because it concernes at least all windows version, and
acording to comments, this is implement the same way regardless the OS

Comment 23

[Anca Buit]

Build 20030228 (1.4a)
There are several issues in this build

Current behavior as I notice:
- singleclick on the actual address selects all (set in pref) -> this is ok
- singleclick next to address in an empty part sets caret on the end 
- doubleclick selects 'word' 
- [problem] tripleclick does nothing 

[problem] After this, there is no way to get the entire url selected except for
moving focus out of the URL bar and back .

[problem] Single click on a completely selected url or a selected word does nothing.
Under Windows, common is to deselect and set the insertion point.

[problem] When moving focus to a different app, than setting focus back by
clicking in the address bar sets focus to the address bar, but doesn't repaint
the window, so the other app is still on top.

'Singleclick on selection' seems to be a problem in all text fields - is that a
seperate bug or does it belong here?

Comment 24

[Vaclav Dvorak]

Anca:
"singleclick next to address in an empty part sets caret on the end" is bug
116441, and "tripleclick does nothing" is bug 194710.

When describing behaviour of URL bar, please do always explicitly say whether
the URL bar was already focused when you clicked, because the behaviour partly
depends on that.

Comment 25

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 26

[Steevithak]

I just installed 1.3 and noticed an incredibly annoying problem with the address
bar that may be related to this bug. In all prior version of Mozilla I could
double click the address bar (when it was not previously focused) and the entire
URL would then be highlighted, allowing me to easily type in a new URL. On 1.3,
the first time I double click on the address bar does nothing but focus it, a
second double click highlights only some random part of the URL, usually just
the trailing slash, and, even if I directly double click over the portion of the
address bar containing the URL, only a small piece of it is highlighted such as
the tld or hostname. The only way I can find to highlight the whole thing is to
manually drag the mouse across it. 

Comment 27

[Vaclav Dvorak]

srainwater: What operating system are you using, and did you make any changes to
the default prefs? The defaults are:

On Windows, single click selects all text. In current builds, this is true
whether or not you click after the text; in 1.3, you must click _on_ the text
(bug 116441 - didn't land in time for 1.3). Double-click selects a word,
triple-click selects all text. This bug is essentially about making an exception
from double-click in the case when the URL bar was not focused at the time of
the first click.

On Unix, single click places caret, double click selects all. This bug doesn't
apply.

On Mac, single click selects all, except when the click was after the text's
end. Double click selects word, triple click selects all. This bug does apply.

There is also a bug to let you click on the bookmark/page icon (left of URL bar
text) to select all text. And another, to let you select all by double-clicking
in the empty space after the end of the text in the URL bar.

Comment 28

[William Wilson]

Basically what I would like to see is consistency across the platforms.  I use
the Windows and the Solaris versions consistently and its a pain having the
double-clicks in the location bar do behave differently.  I personally don't
care which way it works as long as it works the same way on all the platforms.

Comment 29

[Vaclav Dvorak]

William: There are two orthogonal points of view on consistency:
1) Consistency across all applications on one platform.
2) Consistency of an application across all platforms.
Obviously, most applications, including Mozilla, are developed with the first
concern in mind, because most users only use one platform (rather than one
application on multiple platforms) and want to have consistent behaviour.

However, with Mozilla, you _can_ achieve virtually identical behaviour on all
platforms, simply by adjusting the preferences. Just copy unix.js from you UNIX
Mozilla installation directory over win.js in your Windows Mozilla installation
directory, and you have UNIX-Mozilla behaviour in Windows-Mozilla. Of course,
you can also tune the individual settings in prefs.js in your profile. (But be
aware of bug 193025.)

Comment 30

[William Wilson]

Turns out the setting can be altered in the all.js file not in the win.js or
winprefs.js file.  It is easier to make the Unix side look more like the Windows
side BTW.

Comment 31

[Kevin Ar18]

With all this varying discussion, I'm confused as to what direction this bug is
going.  The URL/Location should work differently than a regular text field
because it is used differently than a regular text field.

My personal preference is IE's behavior, which can be described as follows:
1. When window receives focus, the location bar is highlighted.
   Or, when the location bar receives focus, it get's highlighted.

2. Subsequent behaviour is as follows:
   A. Single click places the cursor wherever you clicked (whether inside text
or to the right).
   B. Double click highlights entire URL (whether inside text or to the left).
   C. When the user drags, the cursor is placed and dragging allows you to
highligh characters.  In Mozilla dragging does nothing - it shows an
error/Unavailable cursor, which is a waste of time to the user.

Since we are going with OS specific routes, why not use this method?  I can file
this as a separate bug, but I'm not sure if I should.

Comment 32

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 33

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 34

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 35

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 36

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 37

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 38

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420