Closed Bug 333714 Opened 15 years ago Closed 9 months ago

browser.urlbar.clickSelectsAll should default to true on all platforms

Categories

(Firefox :: Address Bar, enhancement, P3)

All
Linux
enhancement
Points:
3

Tracking

()

VERIFIED FIXED
Firefox 75
Iteration:
75.2 - Feb 24 - Mar 8
Tracking Status
relnote-firefox --- 75+
firefox75 --- verified
firefox76 --- verified

People

(Reporter: sexyeuroboy, Assigned: mak)

References

(Regressed 1 open bug)

Details

(Keywords: parity-chrome)

Attachments

(2 files)

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).
Component: General → Location Bar and Autocomplete
On all platforms ? No ! (see bug 134649)
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: general → location.bar
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.)
OS: All → Linux
Whiteboard: [good first bug]
Attached patch PatchSplinter Review
Attachment #788862 - Flags: review?(scrapmachines)
Attachment #788862 - Flags: review?(scrapmachines) → review?(paolo.mozmail)
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.
Attachment #788862 - Flags: ui-review?(ux-review)
Attachment #788862 - Flags: review?(paolo.mozmail)
Attachment #788862 - Flags: review+
Assignee: nobody → syshagarwal
Status: NEW → ASSIGNED
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.
Attachment #788862 - Flags: review-
So, probably, should we close this bug without making any change?
Flags: needinfo?(paolo.mozmail)
Flags: needinfo?(dao)
(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.
Flags: needinfo?(paolo.mozmail)
(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.
Flags: needinfo?(dao)
Does this need any change? or can we get this in? :)
Flags: needinfo?(paolo.mozmail)
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?
Flags: needinfo?(paolo.mozmail) → needinfo?(dao)
(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.
Flags: needinfo?(dao)
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.
Depends on: 1062417
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).
Duplicate of this bug: 961595
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.
Flags: needinfo?(acelists)
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?
Flags: needinfo?(acelists) → needinfo?(dolske)
As a data point, what's Chrome do?
(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.
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.
Flags: needinfo?(dolske)
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.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → INACTIVE
Status: RESOLVED → REOPENED
Priority: -- → P3
Resolution: INACTIVE → ---
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.
Attachment #788862 - Flags: ui-review?(ux-review)
Assignee: syshagarwal → nobody
Status: REOPENED → NEW
Keywords: parity-chrome

Hello, I'm a new developer looking to get started on my first task. Any chance I could be assigned to this bug?

Hi Alan, thanks for asking, and sorry for the late reply! Given all the previous discussion in this bug, I'm not convinced this is a good first bug to work on anymore. Sorry if this was tagged incorrectly.

You can search for other bugs tagged "good-first-bug" on https://codetribute.mozilla.org/ if you're interested in contributing, and just like you did here, ask for confirmation.

Whiteboard: [good first bug]
Duplicate of this bug: 1584798

FYI I tried to enable this pref and found rather dissatisfied.

One reason is that the PRIMARY selection is overwritten in current nightly.

(In reply to mjh563 from comment #13)

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.

This only applies if the user wants to select the URL. But what if the user wants to edit the URL and append some text from the PRIMARY selection?

One common operation I use frequently is to change the article title of MediaWiki sites to lookup a new article, either from typing / the completion list or from the PRIMARY selection. Or change the bug / comment id for bugzilla. Or change the line hash / issue number / file path for GitHub pages.

My other common edits are adding one s to http:// and removing unnecessary query strings (so that it's easier to read next time I need it from the completion list).

I do not replace the URL often. I use Ctrl-T (or the plus button if I'm using the mouse) instead. I feel uncomfortable that the new site could know how many URLs I visited before, and there might be other information leaked.

Editing a URL is unaffected as a single-click-and-drag operation still works when the URL is not selected.

Nope. If the user wants to paste the PRIMARY selection (so they can't start to drag), or to add characters, the user will be frustrated.

Blocks: 1610397

This is a proposal we came up by discussing the various use-cases and trying to not leave anyone behind on their needs.

It's clear that all browsers across all OS currently default to clickSelectsAll = true, doubleClickSelectsAll = false.
It's also clear that the other non-default states are causing bugs and edge cases we can't handle easily (also due to limited resources).
The primary selection matter is very specific to Linux, we had a look at what other browsers do, and it looks like an improvement over our current state, where we always set the primary selection.
The will to put the cursor in a specific point is something very specific to a subset of Linux users, while it's a real use-case, this concern never came out on other OSes or browsers, and the common answer I found regarding that concern on Linux was "click to select all, then click again". Yes, it's a workaround, but at least the behavior is consistent with everything else.

Proposal:

  • Stop setting the primary selection on code-activated select all operations. For example when the shortcut is used or the urlbar clicked.
  • Remove the 2 prefs and default to what every browser and OS does.
  • Provide a relnote suggesting a triple click to put the url in the primary selection on Linux. Triple click is a commonly defined operation in input fields. The intent to put the url in the primary selection should be known before the click operation, thus one can just execute the appropriate triple click operation for it.
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Iteration: --- → 75.2 - Feb 24 - Mar 8
Points: --- → 3
Duplicate of this bug: 1559664
Assignee: dao+bmo → mak
Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/9d574c79405d
Unify clickSelectsAll behavior across all platforms. r=dao
Status: ASSIGNED → RESOLVED
Closed: 3 years ago9 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 75

Release Note Request (optional, but appreciated)
[Why is this notable]: This is changing the default behavior for urlbar clicks on Linux
[Affects Firefox for Android]: no
[Suggested wording]: The behavior when clicking on the Address Bar and the Search Bar has been unified across all the desktop platforms. In particular on Linux a single click selects all without primary selection, a double click selects a word, and a triple click selects all with primary selection.
[Links (documentation, blog post, etc)]:

relnote-firefox: --- → ?
Regressions: 1621570
Regressions: 1621600

(In reply to Adolfo Jayme from comment #33)

I use Linux because of text-related features like middle-click paste, which allows me to quickly use two clipboards at a time.

And that didn't change, clickSelectsAll doesn't set the primary selection clipboard.

Regressions: 1621747

But the the behavior affordance is lost, obscuring that feature and making the field inconsistent to the rest of the platform. The inconsistency in turn is annoying for users, because what Firefox does to the middle-click paste is completely unpredictable, due to the automatic hightlight. And the fact remains that you can no longer position with a single click the cursor in a certain portion of the URL to edit, say, a slug. And that is a regression.

Flags: qe-verify+
QA Contact: aflorinescu

I managed to reproduce the issue on Ubuntu 16.04 x64 using an older version of Nightly 2020-01-05.
I verified the fix using the same OS on latest Nightly 76.0a1 and beta 75.0b3 by using the steps from comment 1. The issue is not reproducing anymore.
However, I looked in about:config and the pref "browser.urlbar.clickSelectsAll" is not displayed. Is that expected?

Flags: needinfo?(mak)

(In reply to Oana Botisan, Desktop Release QA from comment #36)

However, I looked in about:config and the pref "browser.urlbar.clickSelectsAll" is not displayed. Is that expected?

Yes, the prefs have been removed.

Flags: needinfo?(mak)

According to comment 36 and comment 37 I will mark this bug as verified fixed.
Thank you for your answer, Marco.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

(In reply to Adolfo Jayme from comment #35)

what Firefox does to the middle-click paste is completely unpredictable, due to the automatic hightlight.

We think it is not unpredictable, the primary selection is supposed to be set when the user selects something, it's a consequence of an explicit user selection. Because the automatic selection is not done by the user, it doesn't set primary selection. Triple click is a common way to select all and it's user activated so it continues working.
I understand the change may require some re-training, sorry about that, on the other side it may solve some annoyances for people moving across OSes or browsers for their everyday tasks.

Regressions: 657855

The will to put the cursor in a specific point [in URL bar text field with single click on that point] is something very specific to a subset of Linux users, while it's a real use-case, this concern never came out on other OSes or browsers [...]

I'm Windows user and for one report my longstanding preference to put simple cursor (empty selection range) in text field - in this case in the URL Bar (in past days branded as "Awesome Bar") - using mouse pointer and single click action. (For selecting "words" double- and for "paragraphs" triple-click.)

For years I've been using browser.urlbar.clickSelectsAll=false to express this preference and enjoyed feeling of "not being left behind on my needs", and even a vain feeling of superiority over other browsers that to this days lacks this precious feature. So I'm a bit sad that issue that was specified as "browser.urlbar.clickSelectsAll should default to true on all platforms" ended up as "toss this pref away and act like every other average browser" effectively leaving few Linux users and me left behind in our needs.

I'll probably get used to it after all - actually even more than selection currently bothers me the unavoidable drop-down opening with URL bar focus - and absolutely understand motivation to simplify code base even at this cost, but I feel loss. If there is a chance to reintroduce this old pref, I'd rejoice.

(In reply to Michal Čaplygin [:myf] from comment #42)

I'm Windows user and for one report my longstanding preference to put simple cursor (empty selection range) in text field

Even if we'd reintroduce a pref (and that's not a given), imo it should be Linux only. We wouldn't want to pay the QA and testing costs for it on a platform where it would not be consistent with any other app.

Duplicate of this bug: 1628081
Duplicate of this bug: 1628355

I'm restricting comments here, let's keep the discussion in bug 1621570.

Restrict Comments: true
Duplicate of this bug: 1630515
Regressions: 1633203
You need to log in before you can comment on or make changes to this bug.