Closed Bug 62495 Opened 20 years ago Closed 18 years ago

clickSelectsAll should not trigger if you're selecting text

Categories

(SeaMonkey :: Location Bar, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.1alpha

People

(Reporter: jruderman, Assigned: dean_tessman)

References

(Blocks 2 open bugs)

Details

(Keywords: helpwanted, platform-parity, Whiteboard: [selection][correctness])

Attachments

(1 file, 1 obsolete file)

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.)
Blocks: 62496
Reassigning to anthonyd@netscape.com
Assignee: beppe → anthonyd
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.
Keywords: nsbeta1
Status: NEW → ASSIGNED
Keywords: nsbeta1correctness
Target Milestone: --- → mozilla0.9
moving to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
move to mozilla0.9.2
Keywords: helpwanted, pp
Target Milestone: mozilla0.9.1 → mozilla0.9.2
moving to 1.0
Whiteboard: [select]
Target Milestone: mozilla0.9.2 → mozilla1.0
Whiteboard: [select] → [selection][correctness]
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.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
verified.
Status: RESOLVED → VERIFIED
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).
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
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.
--> mjudge
Assignee: anthonyd → mjudge
Status: REOPENED → NEW
*** Bug 103099 has been marked as a duplicate of this bug. ***
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.
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 
--> URL Bar, where this belongs
Assignee: mjudge → blakeross
Component: Editor: Core → URL Bar
QA Contact: sujay → claudius
--> 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?
Assignee: blakeross → hewitt
QA Contact: claudius → sujay
>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.
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla1.1
*** Bug 107835 has been marked as a duplicate of this bug. ***
cc'ing myself
Hewitt, any comments on my work in progress?
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.
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/
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.
*** Bug 130207 has been marked as a duplicate of this bug. ***
OS: Windows 98 → All
Hardware: PC → All
*** Bug 116441 has been marked as a duplicate of this bug. ***
*** Bug 139938 has been marked as a duplicate of this bug. ***
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.
Attachment #54448 - Attachment is obsolete: true
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.
Keywords: patch, review
Can anyone try my patch out and give some feedback?  It's JS/XUL-only, no C++
changes at all.
*** Bug 114445 has been marked as a duplicate of this bug. ***
Comment on attachment 81456 [details] [diff] [review]
cvs diff -u mozilla\xpfe\browser\resources\content

r=walk84
Attachment #81456 - Flags: review+
Blocks: 73812
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.
No, those comments are completely irrelevant to this bug. (They were irrelevant
to bug 114445, too.)

I've mailed Blake asking for sr=.
Assignee: hewitt → dean_tessman
Status: ASSIGNED → NEW
*** Bug 125695 has been marked as a duplicate of this bug. ***
*** Bug 153613 has been marked as a duplicate of this bug. ***
Comment on attachment 81456 [details] [diff] [review]
cvs diff -u mozilla\xpfe\browser\resources\content

woohoo. sr=blake
Attachment #81456 - Flags: superreview+
checked in to trunk
Status: NEW → RESOLVED
Closed: 19 years ago18 years ago
Resolution: --- → FIXED
I've filed bug 155871 on the context menu focus event issue.
*** Bug 189576 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.