I use Firefox exclusively and this is the single most annoying change they made for no apparent reason. So annoying.
https://bugzilla.mozilla.org/show_bug.cgi?id=1621570 https://bugzilla.mozilla.org/buglist.cgi?votes=133
I hate that behavior. When I click in the address bar, it's because I want to edit the URL. If I want to go somewhere else, I'll open a new tab, or use a bookmark, or click a link on a page. In the rare case that I want to type a whole new URL, but keep the same tab, I can easily triple-click or [Cmd]+A before I begin typing.
Notably Ctrl+C/Ctrl+V operate on the clipboard, while selection and middle-click operate on (at least) selection1.
Which is my main use case for clicking in the location bar, copying the URL. So I appreciate that single-click selects all, so I can then copy with a keyboard shortcut.
I'm confused by your comment "when I want to copy it I have to triple-click anyway" -- I'm guessing you are on linux(?)... does triple-click or select alone automatically copy on Linux? (If select alone normally copies to clipboard, then I'd say it's a bug that it "looks selected" but hasn't copied to clipboard?)
This may be a thing where different behavior is appropriate for different OSes. Perhaps the FF devs who rejected the feature are also Linux users? I think FF wants to get market share beyond what can be achieved focusing on Linux users though.
I think they should make this configurable though, I can see both sides of it.
Ctrl+Click -> insert
CTRL+L would be the shortcut, but often I browse without my hand on the keyboard, just the trackpad or mouse.
You'd think after so long, I'd get used to the behavior and just single-click it. But apparently Pavlov would have me culled from his experiment :)
I would wager almost anything that this is the case for the vast majority of regular users because most of the ones I've interviewed (N = 31) for a uni UX study didn't even know how to read URLs for the most part - especially not after the ? query part.
I doubt many people type much into the omnibar other than input for advertising platforms.
They should probably replace
http://
with
today I want to buy...
Sure, these extensions and workarounds are dangerous and inconvenient, but I do love well behaved web browsers.
I'm with you on this. But to me the worst annoyance is how it tends to revert to a previous URL when the new URL fails to load, either because it truly failed to load due to an error or because it timed out while I'm walking through breakpoints.
When I manually entered a URL, the edit should stick even if it doesn't load, dammit.
But it's difficult to click the leftmost or rightmost character to position the cursor.
So after clicking, I usually tap Ctrl+A (Cmd+A) to "select all" anyway, and then tap left-arrow or right-arrow to deselect and jump to the chosen end of the URL.
Cursor keys only junp to the end if it's selected. My keyboard doesn't have dedicated home/end keys, but I'd probably use the select-all-then-arrow trick anyway.
The use of Cmd instead of Ctrl for CUA shortcuts (and the resulting ability to use Emacs-style shortcuts without issue) is one of the few macOS features that I wish would propagate to other operating systems. The only other OS that comes close with this sort of usability is Haiku (which allows configuring either Ctrl or Alt for the CUA modifier, with Alt by default).
When they added the omnibar they just ripped out the feature flag because reasons.
Unfortunately, Alt+D is also sometimes overridden by JS applications. This is especially annoying in Google Sheets.
Ctrl+L will still work.
The comments on the bug report point out that the new behavior makes Firefox on Linux different from other Linux applications, including some browsers. The devs said they want Firefox to be consistent across platforms, whereas the Linux users want Firefox to be consistent with the rest of their system.
The new behavior is also different from the behavior of text boxes rendered by Firefox.
Editing strings in `about:config` seems to behave identical to the URL bar, and Ctrl+F behaviour is similar (but other search bars, like in settings, do not highlight all). Possibly more, just did a quick check of the text boxes I remember Firefox's UI having.
I also know that I'm in the minority, and that maybe the size of my cohort is too small to add yet another thing to check during regression testing.
But I'm still mad about it :) Firefox always seemed like the browser for people who want to configure weird things, or extend it in all sorts of crazy ways. More and more it's becoming a me-too browser, and the only reason I'm sticking with it is out of a sense of duty to fight a Chrome monoculture.
> It is possible to do both. The answer is customization
Err well that’s not doing both then is it? That’s having customisation. I don’t want customisation. So that’s not doing both at all that’s just doing it your way and ignoring me.
Unfortunately, that dumpster-fire of a bug-report/thread is a horrible abomination that shows massive hubris on the part of the developers; and I say this as a developer myself --- and one who fights against this sort of thing far too often to count. Change the defaults if you really want, but never remove the choice.
(The argument that it has "costs" is stupid --- yes, everything has costs, but they actually have perceived value in this case, unlike working on something else, often of much greater complexity and cost, that your users never even asked for in the first place!)
> it [single clicking not selecting all] 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.
Why can’t you just have both options?
> 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.
> 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.
Shame you cant "give the devs opinion" on bugzilla.
> Is a wontfix with lots of comments more expensive, than a wontfix with comments blocked?
Yes, it is more expensive. When 100 developers are CC'd on a bug that is generating regular "but did you consider this argument?" comments, it's a lot of overhead.
You could argue that everyone CC'd should remove themselves from the CC list when this happens, but by that time we'd already have taken the hit.
These bugs are not fun for anybody, dev or unhappy user alike.
Then fix them.
If I opened an issue asking Firefox to switch their rendering engine to Blink you better bet it would be closed wontfix and stay that way for a long ass time.
I don't remember it doing that before but maybe i have a bad memory
So news.ycombinator.com it goes to the right of https:// and www.reddit.com it goes to the right of https://www.
Madness.
[1] https://news.ycombinator.com/item?id=20574210
Personally, my preferred way of displaying a URL and interacting with it is a full, unmolested URL, in a regular UI edit control.
FWIW, this is fixed in Firefox 3.6; you should probably upgrade.
However I can relate: When I tried to use chromium I got really annoyed that clicking and dragging the selection with the mouse up or down would not automatically select the complete text in front or behind the cursor in the url bar.
Firefox still allows to do that under Linux. Hopefully they will not change that as well.
I don't really care about consistency with other browsers - I don't use other browsers very much. I care about consistency with everything else on my desktop.
(It's not just about the option - I didn't even use the browser.urlbar.clickSelectsAll option myself. The clickSelectsAll=false behaviour - the one that was removed - had been the default on Linux.)
This may just be laptop/touchpad users complaining, and mouse users not comprehending what the big deal is.
The one that grinds my gears is that when you select the URL bar in Chrome it shifts the whole thing to the right, so if you want to edit text you have to reposition the cursor, you can’t just click, pause, then click again.
No longer shows up here, because it's now 135 votes.
Now both firefox and chrome dont allow you to change the adress easily to manually remove amp.
I wonder if some Firefox developer was bribed
I don't see what the single-click functionality has to do with removing something from a URL (as almost all users would perform selection with click-and-drag or a double-click). The primary use case would be for adding text.