When you stop using signal, you can log in to the signal website and say "I'm no longer using Signal"; that will solve the problem with your Signal-using contacts. I just checked and it looks life you have to deregister your account from within the Signal app (ie, can't uninstall first). I'm pretty sure it used to be more lenient: I remember friends being able to deregister their numbers after the fact.
Multisystem inflammatory syndrome in children (MIS-C) was first identified in April 2020 by doctors at children’s hospitals in the United States and the United Kingdom. The condition has also been called pediatric inflammatory multisystem syndrome (PIMS). MIS-C is an illness that can occur after COVID-19 infection and affects mostly school-age children. While the syndrome is rare, it can be dangerous.
You get "free" sites that you actually pay for indirectly through the ad costs embedded in the price of any advertised product you pay for.
Also, how is the claim that "Untargeted ads means less revenue" supported?
I just laughed when I saw your comment, and the bugzilla links are styled as "visted" (i.e. gray instead of black.)
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.
That's interesting. In my case, I hardly edit urls manually in the address bar. Usually I end up on a site either by clicking on links or copying and pasting a whole url from elsewhere. So, when I click on the address bar it's almost always to copy that url. Exception may be if you are front end dev testing different paths on the browser in which case editing in the address bar could be common.
But the automatic single-click selection doesn't fill the X clipboard (meaning it isn't pasted by middle click), so when I want to copy it I have to triple click anyway. Since it looks like it's selected, I frequently forget to do so, which results in pasting something I didn't mean to.
I single-click in address bar, which selects all (in Chrome), then I command-c shortcut to copy.
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.
Thats the only good thing about it... when the X clipboard has an error message in it that I want to search about, I dont need to worry about the search box being already full
I forgot about that use case. I paste into and copy from the address bar all the time. But I still get myself sideways because I treat it like any other text box, and end up de-selecting the URL and having to try again!
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 :)
Time doesn't matter, because you probably interacts with many more normal text fields than browsers URL fields. And since they look the same, and act mostly the same, you won't learn to handle it correctly.
Most of the times when I interact with the address bar it's either to go to a different site, google something or copy the url - in all of those use cases I interact with the entire address to either replace it or select it.
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.
It's sad but true. Googling is probably Firefox's only feature left. After they trashed the dev ecosystem, removed file access, prevented 127. access and prevented ssl bypass for 10. and 192.168. broke markdown rendering, disabled CD access, made development painful, fsckd ftp, banned useful stuff on file:// removed anything useful from about: made developing inside Firefox a nonstarter, borked Web app, and generally broke any use case other than Googling/Shopping.
I doubt many people type much into the omnibar other than input for advertising platforms.
I've never noticed or been bothered by this. Typically when I want to edit a URL it's almost always deleting or replacing a substring in the URL. To do that I just single click + drag which highlights only the selected text instead of everything.
> I just laughed when I saw your comment, and the bugzilla links are styled as "visted" (i.e. gray instead of black.)
>
> 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.
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.
When I click on the URL bar I often want to edit it too.
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.
If you're on a Mac, Ctrl-A and Ctrl-E will send the cursor to the start/end of the line (respectively), just like in Emacs.
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).
Firefox, despite the impression that HN might give, is still very configurable. The existence of about:config means Mozilla can add options without cluttering the more accessible preferences menu. I'm perfectly happy with the default behavior of selecting everything by default, but it does seem like the sort of thing that would be nice to make configurable by those who are willing to mess with about:config.
This is pretty much why I don't use Firefox. Things like this are a deal breaker for me. I really wanted to use that browser, so I even tried at some point fix it myself.
It's more complicated than how you're presenting it.
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.
Their behavior makes Firefox unlike literally every single other program with a text box, except the singular other browser people actually use. Neither browser should be different for the sake of it.
Sorry not sure what you mean? This is exactly how Safari, Chrome, and I guess others I can't immediately test work. Seems good to work as expected from other browsers?
They're saying, I think, that the textbox which is a URL is a special textbox but it shouldn't be. It should be the same as any other textbox in Firefox.
> It should be the same as any other textbox in 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.
Yeah, and that's cool. I get being consistent with other browsers. I also miss being able to invert the choice with an about:config toggle.
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.
Yeah they can't really win - do they try to keep happy a dwindling group who liked Firefox the way it was in the past, or simplify and streamline to innovate more quickly appeal to new users. It's probably impossible to do both. I'm firmly in the anti-customisation camp myself. They obviously aren't ever going to appeal to both of us.
> I'm firmly in the anti-customisation camp myself.
> 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.
IE, the first browser I started using and still use regularly now alongside others, behaves the same with single-click selecting all in the address bar (and it's NOT configurable AFAIK), so I'm used to that; but I also see the value in making it user-configurable.
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!)
A variation on this - Chrome also select the whole address bar, but if you then click a fraction of a second later hoping to position the cursor where you clicked, you find that the https:// appears at the beginning, meaning your cursor is several characters to the left of the position you were hoping for.
There may be a flag to "always show full URL"; if it isn't available (in the address bar context menu) you need to go to chrome://flags/, enable the "Context menu show full URLs" option, restart Chrome, and then enable the option.
Fortunately it can still be reverted if you are willing to compile FF yourself. I've been using Firefox Nightly for a few years (newer features + unsigned addons, and very stable) and recompile it every few weeks to update.
Even if you disagree with the reason might as well give the devs’ stance on it.
> 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.
I'm not totally following what you're saying, but I can answer this:
> 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.
This isn’t a bug though. It’s a feature request where the devs have already vocally said no. This idea that opening an issue for a feature somehow implies that it will eventually get implemented seems so wild.
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.
Interesting, I've always loved this feature. I guess in my use cases, whenever I go to click the URL bar I'm intending to copy/paste it more often than edit. Either way, it's deeply ingrained into my muscle memory by now to go click -> pause -> click to edit.
Yup, same here. I get that some people don't like it, but it's making a mountain out of a mole-hill. I bet that if you do user studies, you will find that a majority of times people click in the URL bar, they are doing so to either copy the entire URL or paste in a new URL. I know I am and I much prefer the current behavior.
UGH the recent Chrome update also adds on top of this if you select then hit left arrow it doesn't even go to start it starts after https:// soooo annoying
I don't remember it doing that before but maybe i have a bad memory
That is the behavior in 3.6; I'm pointing out that the earlier version (3.6) is a upgrade from the later version (70-something?), because Mozilla is making the browser worse over time.
I use mostly Firefox, but that behavior change didn't trigger me.
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.
Agreed, maddening. I kept my Firefox installation pinned to 74 for as long as I could because of this, but I had to give in and update to 85 a couple of weeks ago for something. I scan the release notes for each release in hope, but no.
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.)
Are you a touchpad user? On a PC you get that behavior by simply clicking again, but accurate double clicks are somewhat hard on touchpads, so I get why that'd be annoying.
This may just be laptop/touchpad users complaining, and mouse users not comprehending what the big deal is.
Agree with the sentiment in those bug report threads.
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.
This is how it works in all browsers and is useful because more people on average will click the url to remove all the text so they can type something new
> Now both firefox and chrome dont allow you to change the adress easily to manually remove amp.
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.
Open intents is trying to standardize and promote such cooperation between apps on android.
Tasker and similar apps are also a way to stitch together apps.
