Closed Bug 1621570 Opened 4 years ago Closed 4 years ago

browser.urlbar.clickSelectsAll=false has no effect since 75b1

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Version:
75 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: virsacer, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

nomore_clickSelectsAll.patch
1.51 KB, patch
Details | Diff | Splinter Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

I use Firefox Developer and after the update to 75 the setting "browser.urlbar.clickSelectsAll" seems to have no effect anymore.

I have set "browser.urlbar.clickSelectsAll" to false (a long time ago) and now when I click in the urlbar where I want to edit something the whole url gets selected...

Actual results:

The whole url gets selected.

Expected results:

The cursor should have been placed where I clicked without selecting everything (like in Firefox 74 and older).

The preferences has been removed by Bug 333714.

Regressed by: 333714
Has Regression Range: --- → yes

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Address Bar

This is expected, to put text in the primary selection you can triple click, to put the cursor at a certain point just click twice, like on any other OS or common browser.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX

Well, that is unfortunate...

Tripple click selects the whole url again - I have to click twice but with enough delay in between (to not trigger a double click).

And it is not possible to keep this setting in Firefox?

Status: RESOLVED → VERIFIED

it was a special behavior only implemented for Linux, it was not consistent with Firefox on other OSes, and with other browsers on Linux itself. The prefs were causing broken edge cases complicate to handle, taking into account all the possible pref combinations (for example under certain combinations it was not possible to select a word), and having to execute more tests for them. Not removing the prefs would have not saved many resources, since we still need to maintain them.

In case I wasn’t clear: is it ever easier for a user to have to double-click instead of single-click for positioning a cursor? No (not everybody has the same fine-motion abilities). The rest of text boxes (and text areas in word processors) reverse what you do exclusively in the URL bar (because the rest of text fields in Firefox don’t do that): single-click = position, double-click = select slug, triple-click = select all.

(In reply to Adolfo Jayme from comment #10)

In case I wasn’t clear: is it ever easier for a user to have to double-click instead of single-click for positioning a cursor? No (not everybody has the same fine-motion abilities).

I don't see the fine-motion issue you're pointing at, if it was real we'd receive complains on other OSes, and I'd expect other major browsers to do something about it. Instead I've never seen such a complain, out of this bug report. It's more likely a user with that kind of motion problems can't triple click to select all, nor they can aim precisely at a character. The new behavior is easier to them, just click and type.

(In reply to Adolfo Jayme from comment #10)

The rest of text boxes (and text areas in word processors) reverse what you do exclusively in the URL bar

That's perfectly fine, the urlbar doesn't have to work like autocomplete fields in content, it has a different scope and the most common case in it is to start typing from scratch, it's a different widget and as such it can have a different behavior.

the most common case in it is to start typing from scratch

How often do you do that?
Do you really re-use existing tabs to navigate to a completly different site?

New site => new tab

I guess endusers dont care much if they have to click twice to edit, but developers and sysadmins edit the urls more often and should be able to chose the behaviour...

I mostly reuse tab as it's faster than closing and opening a new one
but once again: why take away the choice that already was there?

Would it be possible to add a single option to enable "standard style" text selection in the location bar, for those who prefer it?

Flags: needinfo?(mak)

Not for now, maintaining those prefs has a cost (we'd not have removed it in first stance otherwise), thus it must have very strong reasons. We'll continue monitoring the situation and update our decision accordingly.

Flags: needinfo?(mak)

We don't need special handling for doubleclicks (since we can use trippleclick or crtl+a to select all - like in all other input fields)

But a pref to prevent a singleclick to call "this.select()" can not be unmaintainable!?

And the situation is this: Obviously there are people (across multiple OS's) who prefer that behaviour and had set their prefs acordingly...

(In reply to virsacer from comment #22)

But a pref to prevent a singleclick to call "this.select()" can not be unmaintainable!?

Most of the tests should then be able to run with both setups, everytime we touch something around that we'll have to check not breaking it, and so on. Yes, even the simplest pref skipping a line has a cost, and that's why they must be weighted with a benefit.

I like the current behavior on Linux where the cursor is just placed in the address bar and I am sad it is going away, and also sad that Firefox will be now inconsistent with rest of the system (on Gnome at least).

If the pref is also gone, would be it be possible to write an extension to enable this behavior back?

If I explicitly do the effort of moving my mouse to the location bar, it is because I want to position my cursor somewhere specifically. If I want to use the entire location bar, I use a shortcut[1] or I can simply triple click[2]. I have an efficient way to do both.

In the new location bar, I have no efficient way to place the cursor, because I have to add an artificial delay in between clicks. And if it's not long enough, I accidentally select a word instead, adding uncertainty to what my action will actually do. Apart from the regression in usability for me, I believe a predictable interface is very important, and this feature breaks it.

[1] Which is probably what most people who have trouble with fine motions use too, because positioning the mouse on the URL is hard by itself, even without aiming for a particular position. That being said, I don't really want to make this argument, since I'm not such a user, so I can't speak for them.
[2] I also disabled browser.urlbar.doubleClickSelectsAll, I want it to behave just like a normal text field.

I like how it worked on Linux, and I hated how it worked on macOS and works on Linux now. (Unfortunately, I didn't know there used to be a config option to force Linux-like behavior on macOS.)

The old behavior is consistent with all other text fields in the system and in Firefox itself. The new behavior confuses me as a user, because the text field of the address bar behaves in a different way compared to any other text field or even the old version of the address bar.

I interact with the address bar by mouse only when I want to edit the address. I click at the necessary place and use my keyboard to make edits. When I need to open a completely different website, I use Ctrl+T or Ctrl+W, Ctrl+T. I also know about F6 that selects the address in the active tab, but use it extremely rarely.

Hence, for my use case I find the old behavior extremely convenient. The new behavior interferes with my needs and doesn't provide a good alternative. Now I need to click, wait and click instead of a single click. Forcing me to do more actions for the same task is a regression, and having to wait between the clicks irritates a lot, just like the long press gestures on mobile. Inserting a delay into the most common user flow feels like bad UX for me.

I expressed my position, because you said:

We'll continue monitoring the situation and update our decision accordingly.

This ticket looks like the only place where you can monitor the situation, so I hope my words and my opinion as a user will be heard. I don't care what would be the default behavior, but I want to have a choice to use the old one. The initial bugreport https://bugzilla.mozilla.org/show_bug.cgi?id=333714 asked to change the default, not to remove the config options.

And never forget about https://xkcd.com/1172/ :)

As a web developer and as a curious person I routinely edit and modify the current page url. Editing the query part, incrementing/decrementing numbers, etc. is absolutely bread-and-butter to me, and I wish other browsers had an option for making possible to click to the url and place the cursor where I clicked – just like when clicking at any other text field. If I want to select and copy the current url or type a new one, I just press Cmd-L.
Please consider adding it back to about:config – or even to the "normal" about:preferences – I wouldn't wonder if many people unaware of about:config started using it.

Please forgive me if this is not the place for this kind of feedback. I'm a Linux user and I really hate this change. I'm not alone, and there are many others like me who agree.

Please bring back the "browser.urlbar.clickSelectsAll" option. I understand that the new default is how it works on other OSes and on other browsers, and that you want to be consistent. I'm fine with that, even if I don't like it and I disagree with it. But let me change it at least! This behavior is not consistent with the rest of the system. When I click on an input box in any other application (except Chromium) on Linux I don't get a full selection of its contents. This basically made Firefox inconsistent with the rest of the system by making the Windows' behavior a standard.

And it's really confusing regarding the clipboard behavior - on Linux it's idiomatic that selecting a piece of text automatically copies it, and yet here we have an input box that only does this when it's selected twice. The first time it's selected the text is not copied, and then if you select it again it is. But it's completely not obvious that this happens, and it's contrary to how everything else works on the system.

Also, I think the way this change was introduced is really bad. What was basically done was:

  1. Decide that the default should be changed.
  2. Change the default and make it impossible for the users to change it back.
  3. Gauge the users' reaction.

What should have been done:

  1. Decide that the default should be changed.
  2. Change the default.
  3. Gauge the users' reaction.
  4. Make it impossible for the users to change it back if appropriate.

I'm in general used to everyone treating us (Linux users) as second class citizens, but it's really disheartening to see it from Mozilla too. :(

(In reply to J from comment #30)

And it's really confusing regarding the clipboard behavior - on Linux it's idiomatic that selecting a piece of text automatically copies it

Right, when the user selects a piece of text, in this case it's not the result of a user action, and that's why it's not copied.

I'm in general used to everyone treating us (Linux users) as second class citizens, but it's really disheartening to see it from Mozilla too. :(

That's not what happened here. We are trying to limit differences across platforms because every difference is causing troubles, introducigin subtle bugs and slowing down improvements, we're trying to make easier for users to move across OS because that's happening more and more often, and we're also trying to welcome users from other browsers without forcing them to set a bunch of hidden preferences.
Leaving hidden preferences behind doesn't completely solve the problem, those are rarely tested and don't go through QA, they can break at any time, or can cause other bugs, or can wrongly conflict with other preferences. Someone has to handle all of that, or it ends up causing those 10 years old bugs that frustrate everyone.

I'm not sure where you see a prejudice towards Linux users here, many Mozilla developers use Linux indeed, and prefs were removed for Windows and Mac too (for other features as well).

I'm not sure where you see a prejudice towards Linux users here
me neither, reducing configurability is generally user hostile, no matter the platform

(In reply to Marco Bonardo [:mak] from comment #31)

(In reply to J from comment #30)

And it's really confusing regarding the clipboard behavior - on Linux it's idiomatic that selecting a piece of text automatically copies it

Right, when the user selects a piece of text, in this case it's not the result of a user action, and that's why it's not copied.

But it is a result of a user action! My mouse didn't click on it by itself - I did! And by clicking on it that piece of text was selected. I don't understand - how this is considered not a result of a user action? :) I click on it - it's selected, hence I expect it to be copied to the clipboard. That's how it works on Linux in general. But it doesn't here, hence it's confusing. It's not idiomatic. In other places where I've seen a single click select everything (e.g. on Github when you press the "Clone or download" button on a repository's main page and click on the URL) the text is copied even though it was selected with a single click.

On Linux the rule is - if it's selected then it's copied. This exceptional case of "single-click-select-all doesn't copy" which was introduced here is just not a thing, and is simply confusing.

I'm in general used to everyone treating us (Linux users) as second class citizens, but it's really disheartening to see it from Mozilla too. :(

That's not what happened here. We are trying to limit differences across platforms because every difference is causing troubles, introducigin subtle bugs and slowing down improvements, we're trying to make easier for users to move across OS because that's happening more and more often, and we're also trying to welcome users from other browsers without forcing them to set a bunch of hidden preferences.
Leaving hidden preferences behind doesn't completely solve the problem, those are rarely tested and don't go through QA, they can break at any time, or can cause other bugs, or can wrongly conflict with other preferences. Someone has to handle all of that, or it ends up causing those 10 years old bugs that frustrate everyone.

I'm not sure where you see a prejudice towards Linux users here, many Mozilla developers use Linux indeed, and prefs were removed for Windows and Mac too (for other features as well).

Mostly due to the way this was introduced. Yes, it also affects other OSes, but there this was not the default behavior! I feel like if the default behavior on Windows was being changed it would have been introduced a lot more carefully, without simultaneously disabling the pref, with more weight given to conforming to the OS' native user interface idioms (instead of giving more weight to cross-platform consistency), and perhaps by running a study first.

Nope, it would have been handled the same. Just a recent example: on Windows we changed DEL to remove entries from the urlbar to SHIFT+DEL, that was the default on Mac until then. We received, of course, some negative feedback because things changed. Now all platforms use SHIFT+DEL. There's no prejudice in changes, at a maximum the market share affects prioritization of resources.

I use both Windows (at work) and Linux (teleworking and the rest of the time). Under Windows, since all Windows has the same behavior, it's not disturbing and it makes sense that the bar has this behavior: everything already acts this way.

Under Linux, as explained in a previous comment, nothing works like that.Mouse in hand, if I switch from another application or even a textbox on a website from Firefox to the Firefox bar, I have to change the behavior while I'm in the same system or even in the same application and while the requested behavior exists only for this bar. If I am using only the keyboard, there is already a keyboard shortcut that selects everything in the address bar and therefore, it does not change anything.

In addition to hiding the top half of the personal bar when it's active (when adding a new tab, for example), which seems like a pretty basic design error to me, you also removed an option (I'm not even talking about the default setting, just the option) that makes Firefox consistent in Linux. Firefox is not (no longer, never was) an OS, don't start doing like Chrome by forcing behavior that only works in itself because under Linux, that behavior only exists with this bar.

I'm not sure where you see a prejudice towards Linux users here
me neither, reducing configurability is generally user hostile, no matter the platform

Because it's already the default behavior on other platforms and nobody cares that the option doesn't exist anymore on other platforms precisely because their system already works like that. Under Linux, the Firefox bar is the only thing that has this behavior. So we took a generalized behavior on other platforms to make it by default and unchangeable on Linux while it makes no sense. Why is that? To reduce the risks. At whose expense? The people who use Linux.

As I side note, because I really don't want to leave anything behind, I just looked at an updated browser market share list on Linux, I had already tested Chromium and derivatives, I added to my testing Opera and Vivaldi. This covers pretty much 95% of the browsers on Linux.
All the browsers present the same behavior, click selects the whole text.

The default file manager on Ubuntu doesn't have a urlbar by default (it can be enabled with hidden gsettings pref) and it doesn't select by default, though I couldn't really find many apps that by default show a urlbar-like widget. Normal input fields don't matter here, because the urlbar is a specific kind of widget with its own behavior, not just an input field.
Could you please make some examples of urlbar-like widgets in commonly used Linux apps?

(In reply to Marco Bonardo [:mak] from comment #38)

Could you please make some examples of urlbar-like widgets in commonly used Linux apps?

Thunar (XFCE), Dolphin (KDE) and PCManFM (LXDE) are some examples.
Interestingly, PCManFM-Qt (LXQt) selects everything on one click by default.

Could you please make some examples of urlbar-like widgets in commonly used Linux apps?

The address bar of Epiphany (GNOME browser) behaves just like a normal text field. Single click puts the cursor, double click selects the word, triple click selects all.

// Given that Epiphany supports Firefox Sync to some extent, it might be a viable alternative to migrate to :)

(In reply to Marco Bonardo [:mak] from comment #38)

The default file manager on Ubuntu doesn't have a urlbar by default (it can be enabled with hidden gsettings pref) and it doesn't select by default, though I couldn't really find many apps that by default show a urlbar-like widget. Normal input fields don't matter here, because the urlbar is a specific kind of widget with its own behavior, not just an input field.

What I have been wondering the entire time: how is the location bar not just an input field? It has text that I can edit. I can submit that text. I get completions (which depending on the kind of form also isn't any weird behaviour at all). Location bars are inputs with a very specific goal, so they just don't appear in a lot of other apps, making your "challenge" harder. But that doesn't make them not an input field, and it makes the inconsistency even weirder, because there just aren't a lot of other location bars to "learn" that location bar-specific behaviour.

Could you please make some examples of urlbar-like widgets in commonly used Linux apps?

One that I did find that hasn't been mentioned yet, is FileZilla, and of course the actual platform native browsers: Epiphany and Konqueror. They just put the cursor wherever you click, as expected. But as I said, I don't actually think the location bar is special at all.

As an extra, this "select on single click" behaviour is also added to the search bar, probably for consistency reasons (which already refutes your previous argument that the location bar is special somehow). Here's a non-exhaustive list of apps with a search-like widget that doesn't automatically select everything with a single click:

  • Thunderbird
  • Firefox's find in page
  • Literally every KDE app I could find: Discover, System settings, Kate find bar, Qt Creator, Okular, Ark...
  • Some GNOME apps apparently just hide the search bar/find if you unfocus it, but the ones I could find that don't, all just placed the cursor wherever I clicked: Files, System settings, Documents, Fonts, Maps (can't get a more literal location bar if you ask me!)
  • Even some Electron apps, which generally don't conform to any platform standards don't select the entire search bar when I click it (note: I don't know how they behave on other platforms): Postman, Signal, Riot

Apps with a location/search-like bar I encountered that do select everything on a single click:

  • Firefox/Chromium/Vivaldi
  • LibreOffice Find in page

In all my search, these are the only apps I encountered that have this weird "select everything" behaviour in any location or search widget I could possibly find.

If you agree that the new behaviour is platform inconsistent for search widgets (which this quick run-down of apps on my system definitely seems to support), then the options for the search bar are:

  • Leave it as it is, making it inconsistent with the platform
  • Make it platform consistent, and thus inconsistent with the location bar
  • Also revert the location bar to the behaviour that is consistent with every other text field in Linux, except apparently the location/search bar in some Chromium-based browsers and LibreOffice's "Find in page".

Hi, I'd like to know when this change has been introduced so I can revert to the old behaviour in my local Firefox build.

(In reply to mattia.basaglia from comment #48)

Hi, I'd like to know when this change has been introduced so I can revert to the old behaviour in my local Firefox build.

https://hg.mozilla.org/mozilla-central/rev/9d574c79405d

(In reply to Marco Bonardo [:mak] from comment #38)

Could you please make some examples of urlbar-like widgets in
commonly used Linux apps?

The closest behaviour I could find to the new Firefox is in VLC.
Open Network Stream has the url already selected upon opening the
dialog box, but any subsequent clicks it acts as a normal urlbar and
never selects all on a single click.

(In reply to tamz from comment #39)

Interestingly, PCManFM-Qt (LXQt) selects everything on one click
by default.

For me it depends on the setting, if I select View -> Path Bar ->
Location it acts like every other urlbar. But if it is set to Buttons
and I right click Edit Path, it is pre-selected before clicking.

(In reply to Marco Bonardo [:mak] from comment #7)

it was a special behavior only implemented for Linux, it was not
consistent with Firefox on other OSes, and with other browsers on
Linux itself

Under non "mainstream" browsers like Midori, Netsurf, Badwolf and
Falkon, clicking on the address bar places the cursor without selecting
it all. Even Steam's Web browser, including the Big Picture web
browser, operates the same way.

In fact every other urlbar in Firefox still acts normally, selecting
urls in bookmarks, setting the homepage in preferences and the urlbar
in about:logins. I don't see why the main urlbar need to be special
under Unix.

Keeping the option to toggle this behaviour would be much appreciated.

I'm finding this change is actually having the opposite effect of what it claims to do. I'm so used to the old way of selecting the entire address that I keep doing it that way without thinking about it, which of course means I am just selecting some portion of the current URL under the new behaviour. Then before I realise what has happened, I've typed the next URL fragment (e.g. "you" for youtube) and end up going to http://www.originalurl.com/you instead.

I agree. Right now it takes me at least twice as many clicks to do the same thing I used to do.

Single click turned into: single click, f-word, single click.
Double click is now: double click, double click, f-word, (possibly failed) triple click. Muscle memory.

Both new defaults are just wrong from my point of view.

The fact that new single click does not put selection into primary is just an additional annoyance (and no, I do not agree with the argument that it was not "my" selection).

I sometimes wonder - are there any Linux users in UX team ? And I mean - people who really use Linux as the only system, not just doing 99% on Windows with 1% shared between Mac and Linux ?

I have an idea: if the main reason the option was removed is overhead when testing code changes around the address bar, I volunteer to test this myself and if something breaks to provide fixes for it.

to put the cursor at a certain point just click twice, like on any other OS or common browser.

But not (almost) every other text field. It's a gratuitous inconsistency.

(In reply to Ron Yorston from comment #57)

to put the cursor at a certain point just click twice, like on any other OS or common browser.

But not (almost) every other text field. It's a gratuitous inconsistency.

Not to mention that clicking twice selects a word. Nothing about this works as it should.

(In reply to Marco Bonardo [:mak] from comment #3)

This is expected, to put text in the primary selection you can triple click, to put the cursor at a certain point just click twice, like on any other OS or common browser.

Sorry but this is the wrong way to see it: as a user I expect all GUIs in my system to behave in the same way.

It is extremely confusing and frustrating for one single application in my system to forcefully emulate some other OS behavior.

Heads-up for "me-too" commenters: please use the vote feature in the "Details" block on top of this page: I see 25 unique profiles on this page expressing desire for this regression to be fixed while just approx 10 of them voted (7 profiles voted and haven't commented). FWIW voting serves this purpose in clearest way Firefox developers can observe without sifting through discussion.

I'm a Windows user but still appreciate doubleClickSelectsAll. I have been using this configuration for over a decade. Double click to select everything in the address bar, this is a large portion of my reasons for choosing Firefox on Windows. I don't have an opinion on what the default behaviour is. It is just ridiculous to not allow this customization. I don't want to ever swear to my favourite browser. Please.

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

Heads-up for "me-too" commenters: please use the vote feature in the "Details" block on top of this page:

This vote feature is so well hidden, that I doubt anyone is going to find it unless directly told where it is...

(In reply to Adam Kowalski from comment #63)

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

Heads-up for "me-too" commenters: please use the vote feature in the "Details" block on top of this page:

This vote feature is so well hidden, that I doubt anyone is going to find it unless directly told where it is...

I actually looked for one when I made my comment and didn't realize it was there. Thanks for that Details tip, but the hidden factor is still an issue.

Would it be possible to re-add this pref but not support the case where it is false? (and add "unsupported" or similar somewhere in its name if needs be)

This reduces your support cost, and allows power users to disable it at their own risk.

(In reply to Marco Bonardo [:mak] from comment #38)

This covers pretty much 95% of the browsers on Linux.
All the browsers present the same behavior, click selects the whole text.

And this is a the reason why I'm using Firefox and not other browsers.

Here is another idea:
Just make browser.urlbar.clickSelectsAll=false the default on all platforms.
Then it is consistent with all other input-fields and you can remove even more sourcecode.
I am sure that there are much more users who would like that behaviour but are unaware of the existence of the "browser.urlbar.clickSelectsAll" pref...

So another disgruntled Linux user here, chiming in with my two cents worth.
This change sucks. I am a regular "URL hacker". Just now I was reading a blog, and I went to change the year to see what was published on the blog previously, but things didn't work as expected. I regularly use Wikipedia and change the topic by editing the URL. I regularly go to the home pages of sites by editing the URL (rather than trying to find the relevant home link, which is in a different place on each website, and sometimes the logo works, and sometimes it doesn't -- for example to get to mozilla.org from bugzilla.mozilla.org, it's quicker to just edit the URL than any other option). And so on and so forth.

In Nautilus (the Gnome file browser) when the equivalent file path bar is first displayed (ctrl-L) the entire path is selected. A single click will then allow someone to change the path easily.
In Rhythmbox, I can search for something. If I want to change what I'm searching for (perhaps I misspelt it), I can single click and correct the mistake.
In Thunderbird, if I search for something, I can single click and then edit without having to either click again or type the whole darn thing again.
In Tomboy, again, same deal with searching.
(Yes, none of these three have an equivalent of a file path or URL bar, but the same principle applies. In Firefox it also sucks that single clicking the search bar selects everything in it.)
In Firefox 75, I have to click, wait, then click again. This behaviour sucks. (It would suck slightly less if there wasn't a delay.)

The fact that other browsers are also broken does not mean that Firefox should also be broken. (If all the other kids jumped off a bridge, would you?) I use Firefox because all the other options are terrible.

I even have tracking turned on so that you can see how I use my damn browser so that you don't take away features I use!

Does anyone know if the old behaviour can be replicated by writing an extension that injects code into the UI? I'm looking at the documentation but it isn't really clear if it's possible.

Or maybe have an extension that replaces the address bar completely with a plain textbox.

in Firefox you'd be able to, but quantumfox is crippled in terms of extensions

(In reply to Mary Arnold from comment #68)

In Nautilus (the Gnome file browser) when the equivalent file path bar is first displayed (ctrl-L) the entire path is selected. A single click will then allow someone to change the path easily.

You can use CTRL+L and then click on any part of the url to put the cursor, if you already have that workflow in mind, it works the same.
IIRC you can also use F6 instead of CTRL+L, that is a single key.
You can also drag-select a part of the url and type over it.

Sorry if I don't reply to everyone, but I'd end up repeating the same things, that wouldn't benefit anyone.

For people who don't mind compiling from source, I've created a fork that reverts a couple commits that removed some address bar options: https://gitlab.com/mattia.basaglia/mozilla-central

I'm using git instead of mercurial because it's easier for me, but everything else works the same as regular firefox source build

(In reply to Marco Bonardo [:mak] from comment #71)

Sorry if I don't reply to everyone, but I'd end up repeating the same things, that wouldn't benefit anyone.

You have yet to answer the question of why a binary setting of standard mode vs power user mode, rather than the many combinations of settings you had been dealing with before, is too much overhead.

(In reply to Marco Bonardo [:mak] from comment #71)

You can use CTRL+L and then click on any part of the url to put the cursor, if you already have that workflow in mind, it works the same.
IIRC you can also use F6 instead of CTRL+L, that is a single key.
You can also drag-select a part of the url and type over it.

Instead of a single click to start editing you're proposing a keyboard+mouse combo as a workaround for this bug. Prior Firefox 75 introducing this new buggy selection behaviour editing and copying the url was quick and easy. Now it isn't.

Sorry if I don't reply to everyone, but I'd end up repeating the same things, that wouldn't benefit anyone.

That's understandable. There's a lot of people disappointed with this issue. Thank you for your replies but I'm afraid not many people are convinced this change was a good idea. I've been using Firefox since it was Phoenix 0.6. It's been one of my favourite pieces of software. That's why this is so very disappointing for me and I'm sure of other long time Firefox users. That it's basically a port of buggy behaviour from Windows to Linux makes it even worse. Please revert to how url selection and copying worked in the previous version or at least give us the option to change this via a preference.

(In reply to Marco Bonardo [:mak] from comment #13)

I don't see the fine-motion issue you're pointing at, if it was real we'd receive complains on other OSes
Here's a complaint for an other operating system: I've always used Windows primarily, and I am FURIOUS that browser.urlbar.clickSelectsAll=false is now ignored on my Windows system. It's counterproductive to my workflow as I OFTEN modify the URL of the current webpage throughout the course of web development, and having to click, wait, wait, wait, wait, wait, wait, wait, click is a productivity barrier. (I'm not going to adjust my system's double-click sensitivity because double-clicking at the current rate still makes sense in other contexts, like double-clicking a file in a file browser.)

Whenever I've wanted to select the entire URL, I mashed ALT+D which is much quicker than maneuvering the mouse cursor and clicking. (Keyboard is king!) If the "issue with other issues" is specifically deciding what to do for a double-click, I can live without special double-click handling; I don't use it; I use CTRL+SHIFT+ARROW when I need to select an entire word.

I agree that the default is peculiar but it doesn't trouble me. I either:

  1. click-and-drag if my intention is to overtype or delete a selection; or
  2. Control-L then → if my intention is to append.

Append

For me, the two keyboard actions (above) are quicker than two hand movements (away to a trackball, back to the keyboard).

I do, however, recognise that browser.urlbar.clickSelectsAll false is of great value in other use cases (e.g. trackpads and other environments where hand/finger movements are minimal).

Given the use cases, and the peculiarity of the default:

  • I added my post-closure vote to this bug.

(In reply to Martin from comment #74)

That's understandable. There's a lot of people disappointed with this issue. Thank you for your replies but I'm afraid not many people are convinced this change was a good idea. I've been using Firefox since it was Phoenix 0.6. It's been one of my favourite pieces of software. That's why this is so very disappointing for me and I'm sure of other long time Firefox users. That it's basically a port of buggy behaviour from Windows to Linux makes it even worse. Please revert to how url selection and copying worked in the previous version or at least give us the option to change this via a preference.

As someone who's been using a Gecko-based browser since Mozilla Suite 0.9, and who is incrementally finding less and less reason to convince family and friends to switch from whatever's installed by default on their systems, I have to agree.

Consistency with OS conventions for whatever kind of widget you're enhancing the concept of, please.

Also, I just found an example where this breakage directly impairs my productivity.

(It's quicker for me to click at a boundary in a URL and then use word-wise delete (Ctrl+Backspace or Ctrl+Delete) than to click-drag select what I want to remove.)

The urlbar is probably the single most often used widget of the whole OS for likely the majority of the users.
If the users complain, listen.

I for one registered a user account on Bugzillajust now after using Phoenix^wFirefox as my primary browser since it hit the deck, only to express my grief on the changes that have been made to the urlbar and the decision that has been made to keep it this way, because reasons.

The urlbar selecting everything upon single click has always annoyed me to the max and setting browser.urlbar.clickSelectsAll to false was always one of the first steps after FF installation.

Please reconsider your design decision.

Removing the browser.urlbar.clickSelectsAll preference seems to violate several of Firefox's stated UX design values: https://design.firefox.com/values/. Specifically, "user-sovereignty", "no surprises", "user control and choice", "performance is objective, but responsiveness is subjective", and most importantly "a happy user performs better".

This preference is important. It greatly affects how users interact with the browser on a regular basis. The urlbar is probably the most used UI component of the entire browser. If Firefox is to allow user-customizable options at all, surely options for the urlbar should be considered some of the most important options available.

I encourage the maintainers to re-consider how much overhead is actually required to maintain such a simple preference that has such a large effect on so many user's workflows.

This violates my expectation of how an input box should work. What are the steps to revert back to an old version?

It seems that the problem is inconsistency.

If the URL bar were the only element in the web browser, then however it behaves would be fine. However, the URL bar is a text input field in an application that presents many text input fields. This particular field behaves differently than all the other fields, for no benefit. The only result of the inconsistent behaviour is breaking user expectations.

Hello Marco Bonardo, I've read your comment https://bugzilla.mozilla.org/show_bug.cgi?id=333714#c27 and your commit (https://github.com/mozilla/gecko-dev/commit/784bf6634e7e925f2c9a5d2ab333ec9174ac99d9) and understood what you implement this. But you could let the two properties customizable and set it to default values across all platforms, or add more tests on update1 if true if it this causes issues.
Can you please restore the two keys so we can adjust them, FYI we already put update1 to false and now we are in the old urlBar.
Thanks

Flags: needinfo?(mak)

Really I'm trying, but I simply hate this change. Elsewhere on the system - one click - focus on field, double click - select all. If I do the same in FF urlbar, it results to one word selection and causes that each time I have to click much more than before.

Please return back the old functionality.

Flags: needinfo?(mak)

For what is worth, I wanted to point out that the issue where it was requested to have this behaviour only had 4 people voting for it (https://bugzilla.mozilla.org/show_bug.cgi?id=333714) and this issue has currently 54 votes.

and default doesn't mean the only option

(In reply to mattia.basaglia from comment #88)

For what is worth, I wanted to point out that the issue where it was requested to have this behaviour only had 4 people voting for it (https://bugzilla.mozilla.org/show_bug.cgi?id=333714) and this issue has currently 54 votes.

For what it's worth, I don't tend to come to Bugzilla unless I notice a bug. Which this is.
Also for what it's worth, it's not exactly obvious how to "vote" for a bug. I just did a search on the page for the word 'vote', and unless the details thing is expanded, it doesn't come up. As other commentators have said, it's well hidden. I have now voted.

this patch is what I'm using for my locally built Firefox, in order to prevent LMB click on unfocused urlbar from doing a Select All
(^ worksforme, tested)

tested on ArchLinux:
local/firefox-hg r523766+.078326f48100+-1 (builtbydaddy)

(In reply to mattia.basaglia from comment #88)

For what is worth, I wanted to point out that the issue where it was requested to have this behaviour only had 4 people voting for it (https://bugzilla.mozilla.org/show_bug.cgi?id=333714) and this issue has currently 54 votes.

I think that has something to do with the current situation. Back when it was first requested to have the behavior this bug is titled after, said behavior was just double-clicking to select all instead of selecting a word. Now, this bug report has become the center of frustration over the entire new urlbar change, especially 2 aspects of it: both the lack of double-click-to-select-all functionality, as well as the removal of being able to click the urlbar without immediately selecting all.

tl;dr Part of why this has so more noise now is there is now much more to be frustrated by and complain about.

(In reply to JimiJames.Bove from comment #93)

Now, this bug report has become the center of frustration over the entire new urlbar change, especially 2 aspects of it: both the lack of double-click-to-select-all functionality, as well as the removal of being able to click the urlbar without immediately selecting all.

Quite possibly, and there's no single, simple solution that'll please everyone.

I'd be frustrated if it was "single click to place the cursor, double-click to select all". All I want is for Firefox to go back to matching the "one click to place cursor, two clicks to select word, three clicks to select line" that all the other text-entry widgets have on my Linux desktop.

(I'm reminded of what I read in my university introduction to HCI course. In many cases, it doesn't matter what you pick, as long as it's consistent with the habits and muscle memory the user gained from the rest of the desktop, and the negative effects of deviating from that will swamp any benefit you can measure in isolation.)

(In reply to Stephan Sokolow from comment #94)

I'd be frustrated if it was "single click to place the cursor, double-click to select all". All I want is for Firefox to go back to matching the "one click to place cursor, two clicks to select word, three clicks to select line" that all the other text-entry widgets have on my Linux desktop.

Same here.

Quite possibly, and there's no single, simple solution that'll please everyone.

Besides reverting back to the old urlbar, or providing a non-default option that fully truly reverts. But they claim that leads to too many use cases to test, even though I'm pretty sure the amount of use cases is on a single-digit order of magnitude. The level of outrage going on so far has me thinking maybe that's worth the effort.

I think this change affects a lot of developers negatively. I had the behavior set up to not select the entire URL on Windows too.

I have to make fine edits to URLs regularly, and double clicking often doesn't work correctly. On the second click it selects a segment of the URL or an equals sign.

The whole URL bar has been going downhill for a while. I don't want to see something cover up part of the page unless I start typing in the URL bar. I'm often trying to read something on the page while editing the URL, but I'm never looking through a list of sites to figure out where I want to go. It serves no use to have a dropdown in the address bar if I'm not typing. I know that Chrome has that behavior, but that's another reason why I don't like Chrome. The great thing about Firefox is that it's customizable and not just locked into features for the average consumer.

Please make the click behaviour either configurable or complying with my operating systems default again (Linux in this case).

It is inconsistent with the rest of the operating system, and therefore going against decades of muscle memory.
Being in the middle of a project right now I don't have time retraining myself at the moment, so I had to switch browser at work.

Which begs the question, why should I even have to retrain myself?
If I want this behaviour [and lack of configurability], I'd use Chrome. (!)

And about 'consistency in Firefox across platforms', well, shouldn't the browser behave like a platform native to a certain degree?
Most people have a reason to choose one operating system over another, one of which is the user experience. I'd expect Firefox on Windows or OSX to behave like a windows or OSX program, same on Linux.
You do e.g. respect '⌘+C' on OSX, and don't force users there to use 'CTRL+C' to improve 'consistency in Firefox across platforms'.

(In reply to Josh from comment #96)

I don't want to see something cover up part of the page unless I start typing in the URL bar.

Please refer to bug 1627858 -- I think it is quite relevant for most participants around here. (And I'd like to point out that it is nearing hundred votes, is not Closed and has quite honest keywords including "losing-users" one. I think this bug should mimic that one.)

It seems that removing the clickSelectsAll feature has now made these 2 use cases inconsistent.
Click in the address bar [the address is hilighted, the list drops down], press TAB and you start tabbing through the list.
CTRL + L to the address bar [the address is hilighted, the list drops down], press TAB and you tab to the search box.

Please restore the original behavior. I have to echo many of the comments in this thread.

  • Clicking in a box should put your cursor right where you clicked. Tabbing into a text box should select the whole text like CTRL + L.
  • Don't open a list and hide the page that I am viewing.

A power user's main use cases, CTRL+L to get to the address bar to copy or start typing (I next hit TAB to get to the search box).
Click in a specific place in the address bar [at the end or in the middle] to copy or change part of the address.

There was a setting for this that power users would change and now it is gone. Pointless change.
I too will stay on FF74 or use a different build with this feature restored. It was bad enough that Mozilla took away the showQuitWarning, I was able to find a replacement with Tab Session Manager. With this also gone, I will have to look elsewhere.

The most frustrating part for me about this change is that on Linux, one click will select the entire URL but does not put it into the selection buffer. I will be using a patched version to remedy this, I hope we get this option to revert soon!

(In reply to Phil from comment #99)

It seems that removing the clickSelectsAll feature has now made these 2 use cases inconsistent.
Click in the address bar [the address is hilighted, the list drops down], press TAB and you start tabbing through the list.
CTRL + L to the address bar [the address is hilighted, the list drops down], press TAB and you tab to the search box.

This is totally unrelated, we made that change for accessibility reasons, and it's not related to this change.

Apart from what I already said regarding the will to unify the behavior for the more commonly found case of users moving across OS and browsers, and the cost of options in general, I'd like to explain a further reason why it's not just matter of reintroducing a pref; the change we made here will allows us to experiment more broadly with the unfocused Address Bar contents, for both UX and security reasons.
Keeping browser.urlbar.clickSelectsAll around would make experiments a lot more problematic, and at a certain point we may have to remove the pref regardless, because it would block landing improvements. So we'd end up causing you frustration twice.
We totally understand your point of view on this matter, unfortunately sometimes changes must happen, to be able to evolve things.

While the final words have not yet been spoken, I'm now restricting comments on this bug because I think most had the possibility to express feedback, concerns and workarounds. The latest comments are mostly me-too reactions, understandable but spamming many of the cc-ed people now.

Restrict Comments: true
See Also: → 1328637
See Also: 1328637 →
Duplicate of this bug: 1848444
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: