62495 - clickSelectsAll should not trigger if you're selecting text

Status: RESOLVED FIXED

(SeaMonkey :: Location Bar, defect, P3)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Enable the browser.urlbar.clickSelectsAll pref 
(close mozilla, add user_pref("browser.urlbar.clickSelectsAll", true); to 
prefs.js, open mozilla again).
2. Drag to select some text in the location bar.

Result: after you finish selecting the text, selection is expanded to include 
the entire url.

Expected result: click-selects-all behavior shouldn't trigger in this case.


This could be tricky, because it's possible to select a single character by 
moving the mouse one pixel.  Maybe the time the mouse button is held down 
should be factored in as well.  (Or we could go with IE's behavior of selecting 
the text onmousedown instead of onmouseup, which makes it hard to select part 
of the url but isn't extremely annoying.)

Comment 1

[kinmoz]

Reassigning to [e-mail]

Comment 2

[Jesse Ruderman]

Nominating for nsbeta1: selecting location bar contents on click is a 
frequently requested feature, and fixing this bug would help make the feature 
more useful and less annoying.

Comment 3

[rubydoo123]

moving to mozilla0.9.1

Comment 4

[Kathleen :Brade]

move to mozilla0.9.2

Comment 5

[rubydoo123]

moving to 1.0

Comment 6

[Blake Ross]

This is really invalid now, because clickSelectsAll is about to focus 
onmousedown.  We differ from other browsers in that if you move the mouse to the 
left or right after mousing down, you will shorten/lengthen the selection, but 
that doesn't seem like a big deal to me.

Comment 7

[sujay]

verified.

Comment 8

[Jesse Ruderman]

I talked to Blake and it looks like this is still a problem, even with his patch
in bug 37587 (attachment 39699 [details] [diff] [review]).

Steps to reproduce:
1. Go to a bug in bugzilla.
2. Focus the content area.
3. Try to select the bug number.

Result: On mouse down, the entire URL is selceted.  As the mouse moves.

Expected result: the entire URL should not be selected at any point.  On mouse
down, the cursor should become a normal text cursor (see bug 78082), and
dragging should select from that point.  At the end, the bug number should be
selected.

For consistency, the URL should also not be selected if I select part of the URL
but move my mouse back before mouseup (so that the selection ends up being empty).

Comment 9

[Jesse Ruderman]

Fixing this bug or bug 16352 (futured) would take care of the problem where if
you move the cursor slightly (even 1 pixel) while clicking the location bar,
only half of the URL is selected.

Comment 10

[rubydoo123]

--> mjudge

Comment 11

[Jesse Ruderman]

*** Bug 103099 has been marked as a duplicate of this bug. ***

Comment 12

[Daggi Elehu]

Double-click should select the entire URL. This would be accomplished if the
cursor becomes a normal text cursor and none of the allowed URL-characters are
considered white-space characters.

Comment 13

[:deanis74]

Attachment: cvs diff -u /xpfe/browser/resources/content

Comment 14

[:deanis74]

Here's an initial attempt.  It moves the selecting of text out of onfocus and
into onmouseup and onkeyup (for the tabbing to the url bar).  This also
addresses bug 97822.  It's not perfect (see below), but it makes selection in
the url bar a heck of a lot easier.  I can now click-and-drag on an unfocused
url bar and select the text that I expected to.

It also doesn't break bug 78083.

There's a limitation to this, being that I check the length of the selection on
mouseup, and if it's 0 then I select everything.  So if you click on the url bar
the first time nothing is selected, but if you click again in the same spot then
everything is selected.

I ran into one problem with this, when I was trying to fix bug 100001 in the
process.  I thought that the popupShowing event would come earlier on in the
process.  When you right-click on the url bar, the evetns go focus -> blur ->
blur -> focus -> popupShowing -> popupShown.  I was hoping that the popupShowing
would come before the first blur, because in that blur the selection is cleared.
 I left all of my debugging statements in there so that you can see for yourself.

cc:ing hyatt 

Comment 15

[:deanis74]

--> URL Bar, where this belongs

Comment 16

[:deanis74]

--> joe, since blake just finished moving all other url bar bugs over to him.

Can someone pound away on this?  I think it's a lot better than what's currently
there.  Maybe we should get this behavior in and then try to resolve the
outstanding issues based on it?

Comment 17

[Jesse Ruderman]

>There's a limitation to this, being that I check the length of the selection on
>mouseup, and if it's 0 then I select everything.  So if you click on the url 
>bar the first time nothing is selected, but if you click again in the same 
>spot then everything is selected.

Part of bug 36848 is that textboxes remember selections even when they're not 
focused.

Comment 18

[Alfonso Martinez]

*** Bug 107835 has been marked as a duplicate of this bug. ***

Comment 19

[Nick Kocharhook]

cc'ing myself

Comment 20

[:deanis74]

Hewitt, any comments on my work in progress?

Comment 21

[Peter Lairo]

The proposed solution in bug 125695 solves this problem quite nicely. Basically,
it would be to implement this pref: 

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

Result (in windows):
1. mousedown & drag = Select part of URL
2. doubleclick      = Select entire URL

This is what a user expects when selecting *any* text in any app. It's simple.
It's consistent.

Comment 22

[Tim Powell]

Peter Lairo, the problem with the proposed solution is that it eliminates the 
single click selection. This bug says that single click should select the 
entire URL, but click and drag should only select what was clicked and dragged 
over. (Setting the pref is a fine workaround until this bug is fixed, however.)

> This is what a user expects when selecting *any* text in any app. It's simple.
> It's consistent.

Except that previous browsers (Netscape 4, Netscape 6, IE 3-6) select the URL 
bar on single click, because the vast majority of users do not edit the URL--
they just type a new one. See navigation by hacking URLs in "Seven tricks that 
Web users don't know"
http://www-106.ibm.com/developerworks/library/us-tricks/

Comment 23

[Peter Lairo]

If the user single-clicks, starts typing and realizes that he is "editing" the
URL, then maybe that user will discover that he can navigate via URL-editing. 

Even if he doesn't learn this, he will quickly try a double-click (because users
know to doubleclick stuff - even "buttons") and he will immediately be
successful. The user will learn that the needs to doubleclick a URL (like he
does when selecting text), and us techies will be able to easily edit URL's. We
all win, IMHO. Unfortunately, I'm probably wrong.

Comment 24

[Jesse Ruderman]

*** Bug 130207 has been marked as a duplicate of this bug. ***

Comment 25

[Matthew T (active 1999-2002)]

*** Bug 116441 has been marked as a duplicate of this bug. ***

Comment 26

[Jesse Ruderman]

*** Bug 139938 has been marked as a duplicate of this bug. ***

Comment 27

[:deanis74]

Attachment: cvs diff -u mozilla\xpfe\browser\resources\content

This fixes it for me.  I select all the text in two places, both in the focus
event if it wasn't caused by clicking on the url bar (gIgnoreFocus == false)
and in the mouseup event if the mouse has moved two pixels or less since the
mouse went down.

I also addressed bug 96446 in this patch.  I wouldn't call my resolution for
that bug "hacky", necessarily, but I had to add gIgnoreFocusCount due to the
multiple blur and focus events I mentioned in comment 14.

Comment 28

[:deanis74]

I should also mention that the patch doesn't break bug 78083 either.  There is, 
however, some visible jumping around of the cursor as the blur-focus-blur-focus 
events happen.

Comment 29

[:deanis74]

Can anyone try my patch out and give some feedback?  It's JS/XUL-only, no C++
changes at all.

Comment 30

[Matthew T (active 1999-2002)]

*** Bug 114445 has been marked as a duplicate of this bug. ***

Comment 31

[Stephen Walker]

Comment on attachment 81456 [details] [diff] [review]
cvs diff -u mozilla\xpfe\browser\resources\content

r=walk84

Comment 32

[Greg K.]

The following comments are relevant due to the resolution of bug 114445 as a
duplicate of this one.

Mac users don't expect double-clicking to select the entire URL. A double click
would be expected to select text between boundaries. In regular text, those
boundaries are white space, resulting in a word select. In a URL, the boundaries
are slashes. Try the OS X Finder's Go/Connect To Server command, put a URL in
that text field, and double click various areas to observe this behavior.

We expect a single click to focus the field and place the cursor.

A triple click would be expected to select the entire URL.

Comment 33

[Matthew T (active 1999-2002)]

No, those comments are completely irrelevant to this bug. (They were irrelevant
to bug 114445, too.)

I've mailed Blake asking for sr=.

Comment 34

[Jesse Ruderman]

*** Bug 125695 has been marked as a duplicate of this bug. ***

Comment 35

[Niels Aufbau]

*** Bug 153613 has been marked as a duplicate of this bug. ***

Comment 36

[Blake Ross]

Comment on attachment 81456 [details] [diff] [review]
cvs diff -u mozilla\xpfe\browser\resources\content

woohoo. sr=blake

Comment 37

[:deanis74]

checked in to trunk

Comment 38

[[e-mail]]

I've filed bug 155871 on the context menu focus event issue.

Comment 39

[Vaclav Dvorak]

*** Bug 189576 has been marked as a duplicate of this bug. ***