Chris Cunningham Reporter
	Description • 18 years ago

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8) Gecko/20051130 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8) Gecko/20051130 Firefox/1.5

Firefox's implementation of clickSelectsAll in the URL bar is clever enough not to override the contents of the X copy buffer. It reduces the amount of clicks required for the most common usage of the URL bar (selecting the URL to either copy it or overwrite it with an entirely different URL) by one click while increasing the amount of clicks required for a less common use (appending something to an existing URL) by one click. Editing a URL is unaffected as a single-click-and-drag operation still works when the URL is not selected.

The historic reason this isn't enabled on Unix is because of the copy buffer issue. This is invalid, as the initial selection doesn't overwrite the X copy buffer in Firefox. This must be made explicit by reselecting the URL.

On modern Unix desktops this historic problem is simply a nuisance to people who neither use nor know about the X copy buffer. All they see is Firefox acting differently to how it does on Windows. And as stated above, because the initial select doesn't overwrite the contents of the X buffer, people who *do* use it (which includes me, all day long) are unaffected.

Changing this would make Firefox 2 nicer to use on Unix.

Reproducible: Always

Steps to Reproduce:
1. Decide to select the current URL, either to do something with it or to overwrite it.
2. Click in the URL bar, once.

Actual Results:  
The caret moves to the point where the URL was clicked. Nothing is selected. For the most common use of the URL bar, the user must first pause to figure out what happened, then double-click to get the desired action.

Expected Results:  
The whole URL is copied. It may be dragged about or deleted and overwritten. Unix nerds are overjoyed to find that their X copy buffers still contain whatever they did before.

Almost all open bugs containing the term "clickselectsall" are counter-bugs to this of one form or another. Should this be adopted, expect the usual wailing and gnashing of teeth. it should be made abundantly clear in the release notes that the initial click doesn't copy in X so as to reduce said teeth-grinding (although as noted above this is merely confusion; the change is non-destructive).

	Jo Hermans
	Comment 1 • 18 years ago

On all platforms ? No ! (see bug 134649)

	Chris Cunningham Reporter
	Comment 2 • 18 years ago

As a long-time mpt fanboi, I'm in total agreement with his assessment of the HIG deficiencies in this area, as qualified by my statements above. Third-party software doesn't have an awesome track record of HIG compliance on MacOS and for that matter neither does first-party software. I'd rather Firefox did what all other good platform software does and completely ignore the HIG when it's obviously both non-sacrosanct and wrong in the first place.

 - Chris

	Matthew T (active 1999-2002)
	Comment 3 • 15 years ago

This bug was previously reported and wontfixed for Linux as bug 282634.

An unsolicited comment from one test subject during user testing of Ubuntu two weeks ago: "You know when you click on the address, bar, normally you can click once and it will cover [select] the whole thing, but on this one you have to drag over. I don't know if that's just Firefox, or..." (Disclaimer: That was just one test subject.)

	:Paolo Amadini
	Comment 5 • 11 years ago

Comment on attachment 788862 [details] [diff] [review]
Patch

The patch looks good to me, thank you! For this type of change we need review
from the User Experience team before proceeding.

Here is my summary of the change for UI-review:

This patch makes the behavior of clicking the URL bar more in line with what we
think is the most common use case: the entire text is selected and you can
immediately start typing a new URL. This is the usual behavior on Windows.
Bug 406706 introduced this for Mac OS X, this does the same for Linux. See
comment 0 for more details.

	Dão Gottwald [:dao]
	Comment 6 • 11 years ago

Comment on attachment 788862 [details] [diff] [review]
Patch

(In reply to Chris Cunningham from comment #0)
> The historic reason this isn't enabled on Unix is because of the copy buffer
> issue. This is invalid, as the initial selection doesn't overwrite the X
> copy buffer in Firefox. This must be made explicit by reselecting the URL.

This was a bug, bug 393828 to be precise, and it's fixed.

I don't really see what changed here that would cause us to change course. This bug looks like a straight duplicate of bug 282634.

	Suyash Agarwal (:sshagarwal)
	Comment 7 • 11 years ago

So, probably, should we close this bug without making any change?

	:Paolo Amadini
	Comment 8 • 11 years ago

(In reply to Dão Gottwald [:dao] from comment #6)
> I don't really see what changed here that would cause us to change course.
> This bug looks like a straight duplicate of bug 282634.

The fact that this change wasn't made in 2005 doesn't imply that the decision is
set it in stone forever. I wasn't around, but I think the UI-review process at
that time wasn't well structured like it is now. In any case, I see no UI review
flags on the referenced bug.

I think we should give a UX person the chance to review this change now. We have
a precedent for doing this on Mac OS X for the sake of user experience despite
the alleged platform conventions being different.

	Dão Gottwald [:dao]
	Comment 9 • 11 years ago

(In reply to Paolo Amadini [:paolo] from comment #8)
> The fact that this change wasn't made in 2005 doesn't imply that the
> decision is
> set it in stone forever. I wasn't around, but I think the UI-review process
> at
> that time wasn't well structured like it is now. In any case, I see no UI
> review
> flags on the referenced bug.

Sure, but we shouldn't randomly change course because someone feels like it. If there's no new data invalidating the previous decision, at least there needs to be a better articulated argument.

> I think we should give a UX person the chance to review this change now. We
> have
> a precedent for doing this on Mac OS X for the sake of user experience
> despite
> the alleged platform conventions being different.

As far as I know, OS X doesn't have the PRIMARY selection, so it's closer to Windows than to Linux in this regard and the reason for not doing it on Linux doesn't apply there.

	Suyash Agarwal (:sshagarwal)
	Comment 10 • 11 years ago

Does this need any change? or can we get this in? :)

	:Paolo Amadini
	Comment 11 • 11 years ago

This is awaiting review from the UX team, you may try pinging them on the #ux IRC channel, though this is definitely a low priority change.

However, it's still not clear to me if there are technical reasons that might make this patch not applicable, even if the UX team thinks the change is beneficial to user experience on Linux.

Dão, are you aware of any bugs or unexpected behaviors that could arise on Linux when the preference to select all text on click is switched?

	Dão Gottwald [:dao]
	Comment 12 • 11 years ago

(In reply to :Paolo Amadini from comment #11)
> Dão, are you aware of any bugs or unexpected behaviors that could arise on
> Linux when the preference to select all text on click is switched?

Only that it would write to the PRIMARY selection. The assumptions made about this in comment 0 are wrong, as pointed out in comment 6.

	mjh563
	Comment 13 • 11 years ago

I've been running Firefox on Linux for years with this pref set to true.

Setting the PRIMARY selection is a non-issue in my view, because that's what I would expect to happen when I select the URL, whether I do it by single-clicking, double-clicking or dragging the mouse over the text.

	Greg
	Comment 14 • 9 years ago

clikcSelectsAll should NOT be default.

> The historic reason this isn't enabled on Unix is because of the copy buffer issue.

Well a modern-day reason not to enable clickSelectsAll is that people want to click on text in the URL-bar and have the cursor appear where they clicked. People SHOULD be tapping CTRL+L if they intend to type into the URL-bar. It is a PITA to deal with single clicks resulting in full-line highlights and this behavior should not be encouraged by default.

doubleclickSelectsAll is the middle-ground and should be default. 

One of the biggest reasons I choose Firefox over competing browsers are these about:config settings:
-browser.urlbar.doubleClickSelectsAll = false
-browser.urlbar.clickSelectsAll = false

It makes little sense to use the mouse to click in the URL-bar and then start typing. If you intend to start typing do this: CTRL+L and then start typing. (or CTRL+L and then CTRL+C if you intend to copy). Firefox should not reinforce the inefficient habit of clicking in the URL-bar before beginning to type something out. This is what other browsers do (e.g., Chrome, IE) and it is not wise. People introduced to a better way often adopt the better way. Learning CTRL+L is the key to the better way. Not making clickSelectsAll the default.


(In reply to Chris Cunningham from comment #0)
> User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8)
> Gecko/20051130 Firefox/1.5
> Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8)
> Gecko/20051130 Firefox/1.5
> 
> Firefox's implementation of clickSelectsAll in the URL bar is clever enough
> not to override the contents of the X copy buffer. It reduces the amount of
> clicks required for the most common usage of the URL bar (selecting the URL
> to either copy it or overwrite it with an entirely different URL) by one
> click while increasing the amount of clicks required for a less common use
> (appending something to an existing URL) by one click. Editing a URL is
> unaffected as a single-click-and-drag operation still works when the URL is
> not selected.
> 
> The historic reason this isn't enabled on Unix is because of the copy buffer
> issue. This is invalid, as the initial selection doesn't overwrite the X
> copy buffer in Firefox. This must be made explicit by reselecting the URL.
> 
> On modern Unix desktops this historic problem is simply a nuisance to people
> who neither use nor know about the X copy buffer. All they see is Firefox
> acting differently to how it does on Windows. And as stated above, because
> the initial select doesn't overwrite the contents of the X buffer, people
> who *do* use it (which includes me, all day long) are unaffected.
> 
> Changing this would make Firefox 2 nicer to use on Unix.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Decide to select the current URL, either to do something with it or to
> overwrite it.
> 2. Click in the URL bar, once.
> 
> Actual Results:  
> The caret moves to the point where the URL was clicked. Nothing is selected.
> For the most common use of the URL bar, the user must first pause to figure
> out what happened, then double-click to get the desired action.
> 
> Expected Results:  
> The whole URL is copied. It may be dragged about or deleted and overwritten.
> Unix nerds are overjoyed to find that their X copy buffers still contain
> whatever they did before.
> 
> Almost all open bugs containing the term "clickselectsall" are counter-bugs
> to this of one form or another. Should this be adopted, expect the usual
> wailing and gnashing of teeth. it should be made abundantly clear in the
> release notes that the initial click doesn't copy in X so as to reduce said
> teeth-grinding (although as noted above this is merely confusion; the change
> is non-destructive).

	Suyash Agarwal (:sshagarwal)
	Comment 16 • 8 years ago

This bug's objective never got a unanimous green flag and has since been pending on the reviewer, so, should I mark it as wont_fix?

Thanks.

	:Paolo Amadini
	Comment 17 • 8 years ago

Thanks for the ping. We have recently formed a Quality of Experience engineering team that can help in triaging this bug and make a decision, with the help of our User Experience team.

My stance is that this user experience change should eventually be done (barring any platform bugs blocking it). A single click should allow the user to start typing in the URL bar, because nowadays the URL bar can be used not only for URLs but for a variety of queries, and I suspect that typing a new search or domain is more common than editing an existing URL. But I don't feel strongly about it and it's not my decision.

Dolske, can you help with ensuring this bug is triaged?

	Justin Dolske [:Dolske]
	Comment 18 • 8 years ago

As a data point, what's Chrome do?

	:Paolo Amadini
	Comment 19 • 8 years ago

(In reply to Justin Dolske [:Dolske] from comment #18)
> As a data point, what's Chrome do?

Selects the whole text and you can start typing.

	Justin Dolske [:Dolske]
	Comment 20 • 8 years ago

I think we should change this. Firefox does this (on every platform but Linux), Chrome does it on every platform, Safari does this on OS X, and IE and Edge both do this on Windows. Consistency with how every other major browser on every platform works is worthwhile. (And +1 to comment 17's point.)

That said, I think this is likely to end up being one of those holy wars about the "right" behavior. So to mitigate that, let's add a step to _migrateUI() to keep the current default for existing Linux users. This balances omgchange for existing users with giving new users the normal default.

Basically add this to the end of _migrateUI() in nsBrowserGlue.js, and increment UI_VERSION at the top of that function.

  if (currentUIVersion < 41) {
    // Bug 333714, keep the old value of this pref for existing Linux users.
    if (AppConstants.platform == "linux") {
      Services.prefs.setBoolPref("browser.urlbar.clickSelectsAll", false);
    }
  }

Please also double-check that our behavior w.r.t. the PRIMARY and CLIPBOARD selections is consistent with Chrome. If we need further changes to be consistent, we should probably do so.

	BMO Automation
	Comment 21 • 6 years ago

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

	:Paolo Amadini
	Comment 22 • 6 years ago

Comment on attachment 788862 [details] [diff] [review]
Patch

Clearing ui-review because we have a path forward in comment 20, we just need to write the patch that includes migration.

	Pulsebot
	Comment 30 • 4 years ago

Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/9d574c79405d
Unify clickSelectsAll behavior across all platforms. r=dao