116441 - [clickSelectsAll] should not trigger if click is after end of URL

Status: RESOLVED FIXED

(SeaMonkey :: Location Bar, defect)

Description

[Simon Fraser [no longer active]]

Our click-select behaviour in the URL bar is wrong, for a number of reasons. 
First, I'll describe the usability problems that I see. There are 2 gestures that 
I do frequently that we currently respond to in a bad way:

1. Click in or after the url, and try to drag around to select alast part of it
   (e.g. the filename, or a bug number from a bugzilla URL).
   On my first mouse down, we select the entire URL, so I have to release and
   click again to do a selection. Bad.

2. Click after the url, and hit backspace to remove the last part of the url.
   Again, on my first mouse down, we select the entire URL, so I have to click
   a second time to get it to do what I want.

I think we should do two things:

1. Only ever select the entire URL on a mouse *up*, and then only do it if the
   mouse was not moved (much) between the mouse down and mouse up.

2. (Optionally?) never select the entire URL if the mouse was clicked after
   the end of the URL.

Comment 1

[Akkana Peck]

Maybe fixing this would also see the infurating "single click in the middle of
the url selects from the beginning of the url to the mouse position", which I
see many times a day (on mac OS X as well as linux).

Comment 2

[Peter Trudelle]

I agree with suggestion (1), which is what IE and 4.x do on Mac, but I think (2)
might seem inconsistent.  I wish we could do (1) on Windows too, but it is a
behavior shared by all the popular browsers there, hence most people expect it,
right or wrong.  Nominating for nsbeta1, cc marlon.

Comment 3

[Peter Trudelle]

nsbeta1+ per Nav triage team

Comment 4

[Samir Gehani]

nsbeta1- per ADT

Comment 5

[Peter Trudelle]

Big sigh.  Will we never get the details right?  ->1.1

Comment 6

[Matthew T (active 1999-2002)]

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

Comment 7

[Simon Fraser [no longer active]]

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

Comment 8

[:deanis74]

verify dupe

Comment 9

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Reopening because the bug it was marked as a dup of was fixed, but only
addressed half of the reporter's request (part 1).   Updating the summary to
reflect part 2.  

Editorial: This is an elegant compromise that still violates HIG (bug 134639),
but does it in a way to make most people happy.  It makes good sense from an HCI
perspective too - clicking on the URL gets you a URL-specific behavior, and
clicking on the text field (but not the URL) gets you text-field behavior. 
Together with bug 62495, this should make just about everybody upset about
clickSelectsAll on the Mac happy.

old field values:
Summary: Click-select behaviour is wrong
Status Whiteboard: DUPEME
Keywords: nsbeta1-

Comment 10

[Glenn Baxter]

I am using 1.1, and this bug appears to have reared its head again.

The correct Macintosh behavior, based upon HIG is to only select the whole
of the element if the element is double clicked.  Single click is always
insertion.  The 1.1 browser selects the whole URL upon a single click, and 
therefore this confuses people.  Please, please, please fix this.  I run
into it 100s of times a day, and still can not get used to it.  It just doesn't
work like any other Mac program.

Comment 11

[Bill McGonigle (not currently reading bugmail; please contact directly)]

FWIW, my current thinking is that HIG violations should be non-default
preferences.  If it's really worth violating HIG, it's worth the effort to make
a pref UI.  If it's not worth the pref UI effort, don't violate HIG.  

Everybody violating HIG when they think it's a really really good idea isn't a
scalable behavior.

p.s. Glenn: Navigator (Chimera) works properly.

Comment 12

[Simon Fraser [no longer active]]

Selecting the contents of the urlbar on first click is not this bug. There's
another bug for it.

Comment 13

[Scott H.]

Glen, while Mozilla does do this poorly, your suggestion of Mac HIG text-field
adherence isn't great either (try Opera to see why). That's single-click to
insert, double-click to select word, and triple-click to select line. (Though
Opera adds the select-line short-cut with F8, which works erratically
unfortunately). I agree with the initial poster that a single-click that selects
the whole line only on MOUSE UP (which is IE's behavior) works best most of the
time. But as Bill suggests, that could be a user pref for those who prefer
strict Mac UI adherence. At any rate, no matter how you look at it, Mozilla's
approach of selecting the whole line on MOUSE DOWN is just plain bad. It's one
of those inelegant little things that gets in your way, the kind of thing that
has always made Windows feel clumsy compared to a Mac.

Comment 14

[:deanis74]

This should be something simple as this addition in navigator.js (pseudo-code):

function URLBarMouseDownHandler(aEvent)
{
  if (gURLBar.hasAttribute("focused")) {
    gIgnoreClick = true;
  } else {
    gIgnoreFocus = true;
    gIgnoreClick = false;
+   if <current cursor position <= length of url bar text>
      gURLBar.setSelectionRange(0, 0);
  }
}

cc: Neil, who wrote this code a while back.

Comment 15

[Paul Wyskoczka]

nsbeta1+/adt3 per the nav triage team.

Comment 16

[[e-mail]]

Attachment: Proposed patch

Comment 17

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 105572 [details] [diff] [review]
Proposed patch

sr=bzbarsky on condition that one of the UI module owners (eg jag, blake, ben,
hyatt) reviews this (note that does not include Dean).

Comment 18

[:deanis74]

For what it's worth, the code looks good to me.

Comment 19

[[e-mail]]

Fix was checked in by timeless.

Comment 20

[Ian Nartowicz]

Was this fix intended to affect all platforms?  I am seeing a change in build
2002120208 under Windoze that looks like part 2 of your request, and I thought
it was working correctly before.

Comment 21

[John Morrison]

Ian has a point. Clicking past the end of the text, in a click-selects-all
textfield, should select the text when on win32 platforms. That is the 
"standard" and user-expected behaviour on win32. (Actually, I'd forgotten
about this since I put a platform check in the code on my build as soon
as I noticed this change in behaviour).

Comment 22

[[e-mail]]

So are we looking at a new pref browser.urlbar.clickSelection
0 = never select (unix)
1 = select when text clicked (mac)
2 = always select (win)
Or just an extra pref browser.urlbar.clickSelectsAtEnd (false on mac)?

Comment 23

[John Morrison]

I'd say just hard code a platform check for Mac, and if it's not a Mac, then
don't apply the additional condition. i.e., this was my quick (untested on Mac)
hack:

Index: xpfe/browser/resources/content/navigator.js
===================================================================
RCS file: /cvsroot/mozilla/xpfe/browser/resources/content/navigator.js,v
retrieving revision 1.484
diff -u -r1.484 navigator.js
--- xpfe/browser/resources/content/navigator.js	24 Nov 2002 22:00:54 -0000	
1.484
+++ xpfe/browser/resources/content/navigator.js	5 Dec 2002 23:20:15 -0000
@@ -1733,8 +1737,14 @@
 
 function URLBarClickHandler(aEvent)
 {
-  if (!gIgnoreClick && gClickSelectsAll && gURLBar.selectionStart == 
gURLBar.selectionEnd && gURLBar.selectionStart < gURLBar.value.length)
-    gURLBar.select();
+  if (!gIgnoreClick && gClickSelectsAll && 
+      gURLBar.selectionStart == gURLBar.selectionEnd) {
+    if (navigator.platform != "MacPPC") { //XXX what is the right test
+      gURLBar.select();
+    } else if (gURLBar.selectionStart < gURLBar.value.length) {
+      gURLBar.select();
+    }
+  }
 }
 
 // This function gets the "windows hooks" service and has it check its setting

Comment 24

[Akkana Peck]

We've gone to all this trouble to make the UI configurable, and then start
adding platform checks in the code?  Why?  Are we sure that ends up being right
for, say, Unix users who set clickSelectsAll?  

We're already using prefs/lookAndFeel to control all the other related issues;
please, let's stay consistent with that and not start hardcoding stuff.

Comment 25

[Sander]

It's a very disconcerting change to have a click after url no longer select the
url on windows. I've been running into it again and again the last few days;
this is unfortunately not behaviour you can easily change, as selecting a url is
such a basic action that it bypasses thought...

Comment 26

[[e-mail]]

Attachment: Patch to add Mac-specific pref

Comment 27

[[e-mail]]

Comment on attachment 109543 [details] [diff] [review]
Patch to add Mac-specific pref

>+pref("browser.urlbar.clickSelectAtEnd", true);
Doh! Forgot the s before the A :-/ Imagine it's there, can you?

Comment 28

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 29

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 109543 [details] [diff] [review]
Patch to add Mac-specific pref

clickAtEndSelects may be a better name for the pref....

Please add a comment to all.js explaining what this pref does.

Comment 30

[Simon Fraser [no longer active]]

> Please add a comment to all.js explaining what this pref does.

I prefer that all.js does not contain comments. Comments here just increase
startup time unnecessarily (JS has to load and parse the entire file on startup).

Comment 31

[Vaclav Dvorak]

Is there another place for the comments then? I appreciate the startup time
concern, but I'd rather have a slower startup than yet another undocumented pref.

Comment 32

[Ian Nartowicz]

I'd prefer that this was fixed, with or without comments :)  I appreciate that
the current behaviour is OK for Mac folks, but it is really confusing the issues
being discussed in bug 188567, bug 194710, and bug 62491 (and more?).

Comment 33

[Vaclav Dvorak]

Attachment: revised and updated patch

This addresses Boris' comments, and is updated to yesterday's tree. It also
does include a comment in all.js - after all, there are already plenty of
comments there.

Warning: this is one of my first patches, and it's made in a slightly
nonstandard way as I don't have a complete CVS tree (downloading 40MB is nearly
impossible for me). I suppose it should be OK, though. Someone, please try it.

Comment 34

[Vaclav Dvorak]

Comment on attachment 116059 [details] [diff] [review]
revised and updated patch

Carrying over bzbarsky's sr, requesting review from jag.

Comment 35

[Christian Schweer]

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

Comment 36

[Torben]

Requesting blocking for 1.3.
Releasing 1.3 with this broken will probably lead to lot of dupes being reported.

Comment 37

[Christian Schweer]

As I just produced a dupe, I'm supporting Torben's opinion:
Requesting blocking 1.3

Comment 38

[jag (Peter Annema)]

Comment on attachment 116059 [details] [diff] [review]
revised and updated patch

+  if (!gIgnoreClick && gClickSelectsAll && gURLBar.selectionStart ==
gURLBar.selectionEnd)
+    if (gClickAtEndSelects || gURLBar.selectionStart < gURLBar.value.length)

Why not && instead of the second if?

r=jag regardless

Comment 39

[[e-mail]]

Fix checked into the trunk.

Comment 40

[Vaclav Dvorak]

Comment on attachment 116059 [details] [diff] [review]
revised and updated patch

Thanks for the checkin, Neil. Requesting approval for 1.3.

Comment 41

[Andreas Kunz]

Comment on attachment 109543 [details] [diff] [review]
Patch to add Mac-specific pref

Remove review request from obsolete patch (revised patch already checked in).

Vaclav, the "revised and updated patch" is checked in, no?
So you can also remove the approval request...

Comment 42

[Andreas Kunz]

Ummm... if this approval1.3? flag was still intentionally active for the 1.3.1
release, I'm very sorry, but the 'Edit' form will not let me set it again (and
that makes me think that this flag is not really to be used for that release).
Sorry for the SPAM.

Comment 43

[Asa Dotzler [:asa]]

Comment on attachment 116059 [details] [diff] [review]
revised and updated patch

1.3.1 is done. this didn't make it.

Comment 44

[Benjamin Streeck]

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