browser.urlbar.clickSelectsAll should default to true on all platforms
Categories
(Firefox :: Address Bar, enhancement, P3)
Tracking
()
People
(Reporter: sexyeuroboy, Assigned: mak)
References
Details
(Keywords: parity-chrome)
Attachments
(2 files)
Reporter | ||
Updated•19 years ago
|
Comment 1•19 years ago
|
||
Reporter | ||
Comment 2•19 years ago
|
||
Updated•19 years ago
|
Updated•19 years ago
|
Comment 3•16 years ago
|
||
Updated•12 years ago
|
Comment 4•11 years ago
|
||
Updated•11 years ago
|
Comment 5•11 years ago
|
||
Updated•11 years ago
|
Comment 6•11 years ago
|
||
Comment 7•11 years ago
|
||
Comment 8•11 years ago
|
||
Updated•11 years ago
|
Comment 9•11 years ago
|
||
Comment 10•11 years ago
|
||
Updated•11 years ago
|
Comment 11•11 years ago
|
||
Comment 12•11 years ago
|
||
Comment 13•11 years ago
|
||
Comment 14•10 years ago
|
||
Comment 16•8 years ago
|
||
Comment 17•8 years ago
|
||
Comment 18•8 years ago
|
||
Comment 19•8 years ago
|
||
Comment 20•8 years ago
|
||
Comment 21•7 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Comment 22•6 years ago
|
||
Updated•6 years ago
|
Comment 23•6 years ago
|
||
Hello, I'm a new developer looking to get started on my first task. Any chance I could be assigned to this bug?
Comment 24•6 years ago
|
||
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.
Comment 26•5 years ago
|
||
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.
Assignee | ||
Comment 27•5 years ago
|
||
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.
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 29•5 years ago
|
||
Comment 30•5 years ago
|
||
Comment 31•5 years ago
|
||
bugherder |
Assignee | ||
Comment 32•5 years ago
|
||
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)]:
Comment hidden (advocacy) |
Assignee | ||
Comment 34•5 years ago
|
||
(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.
Comment 35•5 years ago
|
||
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.
Updated•5 years ago
|
Comment 36•5 years ago
|
||
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?
Assignee | ||
Comment 37•5 years ago
|
||
(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.
Comment 38•5 years ago
|
||
According to comment 36 and comment 37 I will mark this bug as verified fixed.
Thank you for your answer, Marco.
Assignee | ||
Comment 39•5 years ago
|
||
(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.
Comment hidden (advocacy) |
Updated•5 years ago
|
Comment hidden (me-too) |
Comment 42•5 years ago
|
||
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.
Comment hidden (me-too) |
Assignee | ||
Comment 44•5 years ago
|
||
(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.
Comment hidden (me-too) |
Comment hidden (me-too) |
Comment hidden (me-too) |
Comment hidden (me-too) |
Assignee | ||
Comment 51•5 years ago
|
||
I'm restricting comments here, let's keep the discussion in bug 1621570.
Description
•