195874 - click in location bar does not select the URL

Status: VERIFIED DUPLICATE of bug 116441

(SeaMonkey :: Location Bar, defect)

Description

[Christian Schweer]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030224
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030224

I don't know when this feature was lost and whether it was on purpose or not (so
perhaps this bug is invalid!).

At least until Mozilla 1.2 a single click in the location bar selected the whole
URL. After this single click you could instantly start typeing a new URL.

Since at least build 20039212 you have to click exactly on the URL to select it.
Clicking in the location bar behind the URL does not select the old URL, but
sets the caret behind the URL.

Reproducible: Always

Steps to Reproduce:
1. Goto any webpage
2. Single click in the location after the URL of the currently displayed page


Actual Results:  
The caret is set behind the URL.

Expected Results:  
The URL is selected (highlighted).

With a single click ON the URL (instead of behind), the URL is still selected
completely.

Comment 1

[Soeren Unruh]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030303

Confirmed

I'd say it's a feature though. The functionality is more intuitive.

Comment 2

[Patrick]

i think this is added functionality ;)

Single click sets cursor in addres bar, double click selects last term and
triple click selects whole URL.

Bug if you press CTRL+L you'll move to the address bar and select the whole URL.

Adding myself to CC to find out what was it that changed this behavior.

Comment 3

[Christian Schweer]

I'm not sure whether it is more intuitive, that a single click in one case sets
the caret/cursor and in the other case selects the whole URL.

IMHO a single click should have the same effect independent from the position in
the location bar:
- single click on the URL sets the cursor at that position, click behind the URL
sets the cursor at the end of the URL
- single click anywhere in the location bar selects the whole URL (as it was before)

I would prefer the second choice, as I often just click into the location bar
and then start typing the URL of the page I want to see next. But I don't want
to start an evangelism here...

Comment 4

[Patrick]

Suppose you write http://www.mozillla.org/ in the address bar. You want to
position the cursor before the "a" to remove the 3rd "l". Single click sets your
cursor there. Selecting the whole URL would be annoying.

compare it to your favorite word process:
1 click only moves the mouse
2 clicks selects the line
3 clicks the whole paragraph. 

I think this Moz behavior is introduced for consistency.

Unless i'm wrong, this one is invalid. If i'm wrong, please reopen.

Comment 5

[Christian Schweer]

That would be the first solution in comment 4 and I can live with it.

BUT that is not the actual behaviour! (see comment 1!!!)

Suppose you write http://www.mozilla.org/ in the address bar and wait until the
page is completely loaded.
A single click at the a selects the whole URL 
    (at least in build 20030224 on WinNT 4 SP6).

A single click BEHIND the '/' positions the cursor there (at least until Mozilla
1.3 a at end of january, a click behind the '/' did the same as a click before
the '/').

see comment 3: independent action is triggered by the click, IMHO a single click
should trigger the same action whether a character is hit or not.

Comment 6

[Ian Nartowicz]

The bug described by Christian is a regression caused by bug 116441. 
Specifically read bug 116441 comment 20 and the following discussion.  That bug
is now reopened and this should probably be closed as a duplicate.

Patrick's description of URL behaviour is only applicable when the
clickSelectsAll pref is not set, and so is not relevant to this bug or bug
116441.  I would refer him to bug 62491, bug 188567, and bug 194710 (amongst
others) for much discussion on the desired behaviour when clicking in the URL bar.

Comment 7

[Christian Schweer]

I agree to Ian: resolved duplicate.

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

Comment 8

[Paul Wyskoczka]

v