Actually their argument was that all other major browsers behaved like that. You can check with chrome, and indeed it behaves like firefox.

For the user hostility, there argument was that people who dislike the new behavior do not have telemetry enabled, and thus they do not deserve to have the features they want. It's quite ironic considering firefox main advantage is their privacy oriented model...

I don't find it ironic at all. The purpose of telemetry is to be able to obtain information about the user population at large. It's anonymous and the data only flows one way (i.e. you don't see personalized ads based on telemetry data), but of course some data about your browsing behavior is being sent somewhere, yes.

It's a trade-off: You sent some anonymous usage data but in turn that contributes to decisions made about the product. If you opt-out of sending this data, obviously, it does not contribute to the pool of data from which decisions are being made.

Now, that a small group of people with very specific opinions and preferences is the same that disproportionally also opt out of sending telemetry... I don't see how that is Mozilla's problem.

You can't have your cake and eat it too, as the saying goes.

> Now, that a small group of people with very specific opinions and preferences is the same that disproportionally also opt out of sending telemetry... I don't see how that is Mozilla's problem.

I disagree. If you create a piece of software and develop a userbase that disproportionately opts out of telemetry relative to your software's alternatives, congratulations, you won. You got the power users, the developers, the people who care enough to submit quality bug reports, they're all on your side. Game over.

You don't need telemetry to understand what features these users need because they will tell you - loudly and forcefully - in bug reports filed if you break something. Assuming we're talking about open source software, and we are, they may also be the people sending you patches and improvements for these features.

Telemetry is what you need if you're making a mass market product that meets the needs of 80% of users. It isn't necessary, and in fact may not be useful, if you're developing software designed around the needs of the people contributing to the software. Some software tries to do both. But the way you do that isn't by looking exclusively at telemetry and then pretending that what you see there describes the behavior of all user categories, at least when it comports with the plans of your UX team. It's by listening to the people who are most passionate about the software.

The users who opt out of telemetry are a very tiny minority barely worth considering in terms of numbers. Further, they are explicitly saying "I don't value my vote on feature usage as much as I value turning off this data report which contains zero personal information and is used for no other purposes than changing the product. Again, don't want a voice in how the product evolves, cool, just don't complain about not having a voice down the road when something you don't like happens. It's like people who don't like their local politician who spent the year before bragging about how voting was stupid and just a way for the government to track you so you weren't going to do it.

An idea can be good regardless of telemetry, telemetry is descriptive and not prescriptive. Telemetry is inherently reductive in that sense. You're making a leap of logic that's genuinely unfounded - an idea can be good or bad and this is wholly independent of telemetry unless your only concern is maximising or minimising use of some kind of feature. I would never dismiss an idea because someone has telemetry disabled and it seems like a genuinely disturbing idea to even hold the position that a user with telemetry disabled is lacking value.

A user with telemetry disabled isn't lacking value, it's throwing away its vote. Plain and simple, if you want a vote that tells the software maker how you think the product is best used, that's telemetry. If you don't care about that vote, throw it away by turning off telemetry. Now, telemetry is only one (small) input into whether a feature warrants maintenance in a codebase of over 20 million lines, but it is one input that you have involvement in. As I said, up to you if you want to use your vote or throw it away but it's silly to complain about not having a voice after tossing yours in the dumpster.

> Actually their argument was that all other major browsers behaved like that

Yes, I understand, and that's true. But no other native text field behaves like this; only other browsers. In fact, one of the formerly big selling points of Firefox over Chrome for me, at the time, was that in Firefox, interacting with the URL bar didn't select all (read: it behaved like all other GTK text fields). "Making Firefox behave more like Chrome" is an anti-feature when most of your users aren't using Chrome precisely because of asinine behaviors like this.

> My greatest "unnecessary Firefox UI change gripe" is the removal of browser.urlbar.clickSelectsAll 4 years ago

Totally agree. Four years on, and it still trips me up daily.

Ironically, the usual failure mode for me is actually the one this change was supposed to help with - I want to select the whole URL, so I instinctively double-click it. This has the effect of selecting everything on the first click, then reducing the selection to a single word on the second. I am momentarily perplexed, then I recover and start clicking again, but now it takes three more clicks to get the whole URL selected.

It's surprising how annoying this is!

The explanation given in the tracker seems to amount to "at some point in the future, we might do something else that justifies this". Four years later and I'm not seeing it?

I vastly prefer the current way. It makes it very easy to manipulate parts of the URL. If I want to replace the URL I just open a new tab instead, and if I want to copy it I use ctrl+d which focuses URL and selects all.

> as you might expect, Mozilla does not care

internal options are internal options, no browser cares much about them outside of e.g. some huge company support contracts

if you have to go to `about:config` for anything but dev or MDA related things then you can't expect things to continue working with any update

and every option is code which needs to be maintained

if I should guess they rewrote the code which used the option and did the faster/cheaper thing of not re-implementing a feature they officially anyway don't support

I switched to Vivaldi as a result of the removal of this feature from Firefox, because Vivaldi still allows you to choose this behavior. Are there other Unix browsers you're aware of that allow you to disable click-to-select? It'd be nice to at least have some options, although I'm generally happy with Vivaldi.

And it's still broken, because the "Paste and Go" feature doesn't work.

Common sense suggests "Paste and Go" would be equivalent to using "Paste" (which correctly inserts text from the clipboard at the cursor position) followed by "Go to the address in the Location Bar." But if you unselect the automatically selected URL, position the cursor within it, then use "paste and go", Firefox ignores the previous URL and simply tries to go to the text in the clipboard. This could potentially be a security risk by tricking people into visiting URLs they didn't intend to.

If they don't want to fix this, it should be renamed to "Clear, Paste, and Go", because that's what it actually does.

For non-technical people it would be a huge security risk of not behaving that way, similar Clear, Past and Go would just be unnecessary confusing.

Technical people have the tendency to use keyboard shortcuts.

If there is one command called "Paste", and another command beginning with and commonly abbreviated to "Go", "Paste and Go" should be equivalent to using both in sequence. If it's impossible to make it act in the expected manner, and impossible to label it correctly, the only remaining option is to remove the feature.

you are missing the point

most non-technical people treat urls mostly as blobs (which doesn't mean they don't understand it's consisted of parts, but that's irrelevant)

so the URL field is mostly operating one urls as a while

that's why if you click on it in difference to normal text it will always select the whole url, because most times most people will either copy that url or fully replace it

similar "Past and Go" also operates as the url as a whole, not text segments. So it pasts the new url to where the old url was and "goes" to the new website

additionally if you don't just replace an url but edit it a "do this edit and directly go without giving me a chance to double check it" functionality doesn't really have any reason to exist as its way too niche and people who do that likely anyway use keyboard shortkuts instead of the context menu

sure there probably could be a better name e.g. "Replace Tab and Go". Or they could not show it if you don't have all text selected.

But "Past and Go" isn't a description of functionality anymore but has become something like a slogan or special term. So neither renaming it nor changing behavior is really acceptable from a UX POV.

> this literally cannot be explained by anything except user hostility

Really?

It literally says why it was changed:

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.

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

So GTK text fields behave a certain way on the entire platform (Linux). Other browsers choose to implement a behavior that is totally inconsistent with the rest of the platform. As far as I am concerned, Firefox was the only browser that implemented this correctly. Do you truly personally believe the right move here was to match the beahvior of other browsers, who themselves are incorrect by not respecting platform conventions?

> The prefs were causing broken edge cases complicate to handle

Don't fix something that isn't broken.

> Not removing the prefs would have not saved many resources, since we still need to maintain them

I can hardly see how "having more code means it makes it harder for me to maintain" is a legitimate argument. This argument makes no sense. Delete the entire URL bar then. The URL bar requires lots of code and is hard to write unit tests for. (/s) 1. Mozilla engineers are literally paid to maintain the browser, 2. not wanting to update unit tests to deal with a pref is pure laziness, no excuse.

I agree. It seems there are two conflicting views here.

"Firefox is a kind of browser, which happens to be running on a desktop."

"Firefox is a kind of desktop app, which happens to be rendering websites."

In the first, Firefox should act like other browsers because "browsers" are the relevant reference group. In the second, Firefox should act like other apps on the platform because the platform is the relevant reference group. Personally, I think the second view is simply correct. How often do you switch between browsers? For all but a few power users, switching browsers is vanishingly rare compared to switching desktop apps. This suggests that at least for browser chrome, desktop consistency is much more important than browser consistency.