…on the notoriously unreliable Statcounter.

Ah gotcha, that is different indeed!

Ah, gotcha! Well, if it’s any consolation, clearly I didn’t click on the clickbaity headline to read the actual low-quality article :P

Didn’t Arch just have a major security issue due to their packages essentially being random guys too? (And I think the same thing could theoretically happen to most distributions?)

I think it’s just a preview feature, so it’s not accessible through a normal menu yet I think, but if you type about:keyboard in the address bar and press Enter, I think it will allow you to remap these (under the Navigation section).

He’s not involved with Niri and AFAIK not with PaperWM either.

It’s a bit hard to tell, since not every Firefox install necessarily corresponds to a single user, but it’s probably in that ballpark: the number of active installs is hovering around 200 million.

Don’t underestimate the size of the browser market. A small share of a market of a couple of billion users is still a lot of people.

And presumably, like everywhere, not every dollar automatically makes things better, but having to pay people to do stuff like this isn’t cheap.

It’s basically Opera of yesterday. It’s closed source, and has basically no community involvement.

They’re actually pretty much staying on Chrome (and Safari, somewhat), especially as people spend more of their time on their phones instead. (And to some extent, it’s probably not people changing how they spend the time, but the userbase simply changing as older people die and younger people come online - mostly on their phones.)

Donations to Servo (or Mozilla, for that matter) don’t come anywhere near the income from selling the default search engine spot in a browser used by hundreds of millions of people.

It does sound like SUSE mainly removed them due to issues specifically with how Deeping was packaged for SUSE. It’s likely that there were also issues with Fedora’s packaging (if that was also handled by upstream), but not necessarily that they were the same issues, so I get why they wouldn’t just blindly copy their decision.

(It also looks like Deepin’s working to correct the SUSE-specific issues, which is good to see.)

No, I was already convinced that relying on colour alone is insufficient. I still think they can be useful helpful if they don’t rely on colour alone.

True, there are exceptions (that’s why I keep saying most), and I think the pattern is more common on web than on desktop. (Though I think Gnome also compensates a bit with their boxed lists as an additional affordance.)

Note that I am 100% on your side in saying that there are annoying toggle boxes that are unclear. In your image, I can only tell that the second is probably on because the right-hand side is usually used for the on state in LTR locales. But they can be better, e.g. with an on/off label integrated. Ironically, GNOME has a toggle to enable this:

Well, I’d encourage you to keep an eye out; I think you’ll find that the majority of controls on the web behave as I described. And I think that’s a good thing, too: it’s far quicker and easier to be able to deduce behaviour from the control you’re handling at the moment, than having to scan the complete context. And especially if e.g. you’re visually impaired, the latter can be a major hassle.

(And indeed, the other controls you mention almost never apply instantly, so their behaviour is still predictable. When they do, they’ll often still have some other affordances to indicate that they do apply instantly.)

I was trying to make the point that the way a control looks gives you some information on how it will behave, because software has generally been consistent with associating those looks with those behaviours.

So if you see multiple options with a circle in front of them, selecting one, then selecting another will usually deselect the first one.

On the other hand, if those options have squares in front of them, selecting one, then selecting another will usually result in both of them being selected.

And in both cases, usually they will be part of a form and will only take effect when you submit that form using a button.

On the other hand, something that looks like a toggle usually takes effect immediately on toggling.

Of course it is technically always possible to have each of those behave like any of the others, but you will be breaking conventions if you do so. Styling is an affordance to inform the user about the behaviour.

I mean, they can, and they can also be made to be mutually exclusive - but it’s better to use radio buttons in that case. If that pattern is used, there’s not really a good way that a checkbox will take effect immediately beforehand, or whether it will require submitting a form, except scanning the full page to look for such a button.

It’s nice to be able to know that they take effect immediately though, instead of needing to click a submit button.

Oh yeah I wasn’t trying to say this wasn’t interesting, just trying to make sure people didn’t get the wrong idea of what it meant.

Right, so for the vast majority of users, their Firefox instances won’t actually be running this, right?

Is this a step towards implementing Google’s same extension restrictions in FF, setting themselves up as the primary arbiter of adblock tools?

I wouldn’t expect that:

Firefox, however, will continue supporting both blockingWebRequest and declarativeNetRequest — giving developers more flexibility and keeping powerful privacy tools available to users

https://blog.mozilla.org/en/firefox/firefox-manifest-v3-adblockers/

and

And even if we re-evaluate this decision at some point down the road, we anticipate providing a notice of at least 12 months for developers to adjust accordingly and not feel rushed.

https://blog.mozilla.org/addons/2024/03/13/manifest-v3-manifest-v2-march-2024-update/

So even if that would change (which I’d be very surprised by), it wouldn’t happen for another twelve months, so plenty of time for outrage then.