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.)

Reassigning to anthonyd@netscape.com

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.

moving to mozilla0.9.1

move to mozilla0.9.2

moving to 1.0

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.

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).

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

*** 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

--> 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?

>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.

*** 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. ***

*** 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.

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.

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

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=.

*** 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

checked in to trunk

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

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