[karajorma]

Living in China this bug rolled round to affect me before it will hit most of you so I figured I'd give you the heads up because I haven't seen it mentioned on any of the tech sites I read.

https://techupdatess.com/firefox-disabled-all-add-ons-because-a-certificate-expired-engadget/

[deathspeed]

Thank you!  I was wondering what the hell happened!!

[Nightmare]

Huh. Thanks to this I've noticed there was some plugin that I never would've installed voluntary.

[Det. Bullock]

Annoying, fortunately apart from a skin and adblock I don't use extensions but it's still a bother to use the debug to turn them on manually every single time.

[Mongoose]

This is why I preach the Pale Moon gospel.

[karajorma]

I don't see why Pale Moon would be any less vulnerable to this kind of cock-up.

[Mongoose]

Well for one, Pale Moon doesn't enforce the sort of add-on signing requirement that enabled this in the first place.

[The E]

That's a bad thing, though.

[Mongoose]

I mean, is it?  Having a single point of failure cripple one's browsing experience (and due to something as inane as an expiring certificate of all things) is pretty unacceptable from where I'm sitting.  I also don't need any sort of external verification to tell me that the extensions that I've been using for in some cases an entire decade are safe to have installed.  Though given the extension apocalypse that Mozilla created with their move to WebExtensions, it's clear that they aren't a very high priority anymore.

[Hunter]

Check out Waterfox, it's IMO a better fork than PM.

[Mongoose]

The main issue with Waterfox is that it's still built on the current extended-release version of Firefox, so when that increments it'll do so in a similar manner.  It's apparently also has some sort of bootstrapped support for traditional XUL-based extensions that will be removed in the future, which is a hard no for me.  Pale Moon is a definitive hard fork of a much earlier version of Firefox that's gone its own way and remains committed to XUL and XPCOM-based extensions, instead of the far more limited WebExtensions system that Firefox solely features today.  At the end of the day my biggest draw to Pale Moon is that it's trying to preserve the early Firefox spirit of a browser that's extensively customizable, whereas Firefox has moved further and further toward a much more locked-down experience.

[Det. Bullock]

They seem to have solved the issue with the last update.

[The E]

I mean, is it?

Yes, absolutely.
The old plugin APIs created a situation where Firefox was essentially impossible to secure. See this Twitter thread for details.

You, personally, may be competent and vigilant enough to be able to avoid malicious extensions. The average user isn't.

[Mongoose]

I know, and I'm okay with that.  The reason why I jumped ship on Firefox is that since almost as far back as version 4, Mozilla has made it increasingly clear that they're exclusively targeting the lowest-common-denominator user at the expense of the customizability that the browser originally stood for.  "Want a status bar at the bottom?  Sorry, you'll need an extension now!  Want your tabs below the address bar?  Lolnope, and here's a bull**** blog post where some UX hack tries to justify his position by stating why you shouldn't even want that in the first place!"  The latter was the straw that broke the camel's back for me, and that's why I went for a browser that lets me have exactly what I want.  If that means having potential security issues that make it a bad idea for grandma and grandpa to browse Facebook with it, I don't really mind.

[X3N0-Life-Form]

... These come off as rather petty first world problems, to be honest - "My browser doesn't look exactly as it did 5-10 years ago, this is unacceptable !". I mean to me FF still works the way it always has, even if some time it can take an hour or two to get used to a major update like the addon/extension things from a few years back.
Besides, if I have do choose between suffering some discomfort for 30 minutes due to a UI change and having potential security issues, I'm not arrogant enough to assume I am *never*, ever going to make the same mistakes gandma or grandpa would in a moment of inattention, so I'd most likely pick the most secure one.

[Phantom Hoover]

UX designers telling you that they know what's good for you (which is invariably following the latest hot trend, usually aping Chrome in this case) better than you do is very repellent, though.

[Mongoose]

... These come off as rather petty first world problems, to be honest - "My browser doesn't look exactly as it did 5-10 years ago, this is unacceptable !". I mean to me FF still works the way it always has, even if some time it can take an hour or two to get used to a major update like the addon/extension things from a few years back.
Besides, if I have do choose between suffering some discomfort for 30 minutes due to a UI change and having potential security issues, I'm not arrogant enough to assume I am *never*, ever going to make the same mistakes gandma or grandpa would in a moment of inattention, so I'd most likely pick the most secure one.

The tabs-only-on-top issue in particular was far more significant than that, because it disrupted a completely-unconscious workflow honed over who knows how many tens of thousands of hours of using the browser from the moment I first downloaded it more than a decade ago.  I move my mouse to certain points on the screen while barely having to fire off a neuron because I've done it so many times before, and now you're throwing that off...and for what gain exactly?  Seriously, the blog post where Mozilla tried to justify forcing tabs-on-top was one of the most wonderfully-spun pieces of bull**** I've ever had the displeasure of reading, full of tripe like "well the address bar and navigation buttons are part of the content, whereas tabs aren't, so this makes perfect sense!"  If you want to put that doofy spin on things, fine, but don't ****ing remove my option to keep things the way I prefer, the way I've used them for over a decade without ever having to think twice about them.  It's really the Windows 8 mess all over again: every single person who'd used PCs since the mid-90s was intimately familiar with the Start menu, which had persisted with comparatively-few changes up to that point...but hey, let's throw out 15 years' worth of experience for something NEW and SHINY and a massive pain in the ass to actually use!

Being forced to use Chrome on my work laptop remains an exercise in irritation, because it's so fundamentally different from my preferred browser workflow.  Even doing simple tasks like clearing the cache takes a few more mouse-clicks than in Pale Moon, because lord forbid Google allow one to use something as basic as a menu bar.  Every design decision Mozilla has made over the past several years has been driving Firefox to look and act more and more like Chrome...at that point, why not just cut out the middleman and use Chrome?  Where's the legitimate option if both "options" are practically clones of one another?

UX designers telling you that they know what's good for you (which is invariably following the latest hot trend, usually aping Chrome in this case) better than you do is very repellent, though.

Oh absolutely. I cannot count how many times a piece of software I've used for years has made some sort of fundamental change in its presentation and workflow, almost always to my detriment, and most of the time I've had to grit my teeth and bear it.  **** that.  Stop. Changing. My. ****.  I know what I want, not you.

[X3N0-Life-Form]

Well, I can only partially relate, I *do* get the workflow-disruption-due-to-UI-changes argument, for a change like swapping the position of two UI elements that were literally side by side, one of said element requiring visual inspection anyway (to make sure you selected the right tab), as far as I'm concerned, it *did* add a significant overhead of about 0.5s to 1.5s to my interractions with it (so doubling to quadrupling the amount of time required to interract with it).
I took me about two weeks or so to rewire my brain to deal with this perturbation and get back to optimal speed, so with about a hundred and tenty interactions per day, that's about 2340 seconds lost to inefficiency during that time, roughly 40 minutes out of a 100 hours for 2 weeks & a half of work.

So yeah, I *really* can't relate to that particular UI tweak, not when there's so many other apps that do more drastic changes that *do* cause people to lose between 30s to entire minutes on a single task (and there's usually more than one task that gets affected), take months to getting used to while risking all kind of errors in the meantime, with little gain once you *do* get used to it.
(Also, I never read any of Mozilla's blog posts on the matter, and I don't really care what their reasons for the change are)


"I have to move my mouse half a centimeter from where I used to move it" is something that I consider a non-issue that is barely an inconvenience to deal with or get used to, meaning that I never got all the vitriol it received, and probably never will, it was still recognisably Firefox. Especially since these :

Being forced to use Chrome on my work laptop remains an exercise in irritation, because it's so fundamentally different from my preferred browser workflow.

[...]

I cannot count how many times a piece of software I've used for years has made some sort of fundamental change in its presentation and workflow

*are* absolutely relevant points, I also groan whenever I'm told that an app only work in some old IE version, or on Chrome or whatever, and I have seen quite a few major UI redesign on specialised apps that were bound to break workflows in dramatic ways.



tldr; swapping tabs & address bars isn't such a bad change in itself

[The E]

Seriously, the blog post where Mozilla tried to justify forcing tabs-on-top was one of the most wonderfully-spun pieces of bull**** I've ever had the displeasure of reading, full of tripe like "well the address bar and navigation buttons are part of the content, whereas tabs aren't, so this makes perfect sense!"

It's interesting, I always thought that the traditional firefox way of doing tabbed browsing was unintuitive and stupid.

If you want to put that doofy spin on things, fine, but don't ****ing remove my option to keep things the way I prefer, the way I've used them for over a decade without ever having to think twice about them.  It's really the Windows 8 mess all over again: every single person who'd used PCs since the mid-90s was intimately familiar with the Start menu, which had persisted with comparatively-few changes up to that point...but hey, let's throw out 15 years' worth of experience for something NEW and SHINY and a massive pain in the ass to actually use!

Speaking as someone who has had to deal with ****ty UI frameworks more than I ever wanted: There are legitimate technical reasons for this as well aside from the UI context stuff that people can legitimately disagree over.
The Chrome-style UI is very easy to implement and requires no communication between the tab (and the browser instance in it) and the frame; Chrome's "every tab is a separate sandbox" design can be kept very pure and constrained by not requiring any communication between the tab and the process hosting the main window. Firefox' traditional style, on the other hand, requires that this exists: without it, the contents of the search bar (and any status bars) cannot be kept in sync with what the tab is actually displaying. By opening the sandbox like that, an attack surface is created; From a purely technical side, chrome-like tabs are simpler, cleaner and more secure.

EDIT: This is wrong, see ngld's post below

Also, while I am not exactly happy with app UX designers and their constant need to justify their existence by redesigning things that do not need a redesign (My personal favourite bull**** change was the Google Mail app on Android and it complicating the process of switching between multiple accounts between versions for no reason), I have never felt the need to get angry over it. I'm just not that interested in optimizing my workflows that minute changes like that actually register.

[ngld]

[...] Chrome's "every tab is a separate sandbox" design can be kept very pure and constrained by not requiring any communication between the tab and the process hosting the main window. [...]

(To the best of my knowledge), that's not true. Chrome is split into several processes (on Windows you can see that if you enable the command line column in Task Manager and look for the --type= parameters). The main process types are: The host process (the one that's first launched), the GPU process and a bunch of renderers. Other process types exist (like the Crashpad handler, utility and maybe others) but they're not as important to the actual browser rendering.

The renderer processes have the least privileges and contain the actual tab runtime. The only resource they have access to is a pipe to the host process (yes, they can't even display stuff on their own). This is also the reason Chrome uses its own layout for default elements like buttons: The renderer can't access the platform-specific rendering APIs. All interaction is forwarded from the host to the renderer process which then re-renders the appropriate sections of the page and sends them to the host. The host combines that with the remaining UI (compositing) and sends the result to the GPU process which then sends this to the GPU for actual rendering / display. Fun fact: Google has/had to workaround a number of bugs in the gpu process since some drivers broke after being sandboxed (the drivers did NOT expect that any filesystem call would fail).

Stuff like the number of blocked ads in uBlock or any extension that displays stuff within the browser UI also requires communication between the host process and the renderer processes. Firefox adapted the same model for sandboxing BEFORE switching to the WebExtensions model (code name for those builds is e10s or electrolysis). This is also one of the reasons extension developers were so annoyed by Mozilla. They spent a lot of effort to update their extensions to work with the new sandbox and then get told to rewrite their extensions AGAIN to fit the new extensions API. Guess what? A lot of them just abondened the extensions instead.

The switch from the old extensions API to WebExtensions had two reasons (as far as I'm aware): Mozilla wanted to drop the XUL framework and make it easier to port Chrome extensions to Firefox. The main issue here is XUL. It both enabled the flexible interface which allowed extensions to modify nearly any part of the UI and made a bunch of other things much more complicated for the browser devs than they had to be. In case anyone here doesn't know what XUL means, it's XML User interface Language, which basically allows to design UI with XML files. The whole Firefox UI was implemented through these XML files. Extensions then could add their own XML files which were merged with the browser's own files and thus could add, modify and remove existing elements. The final result would then be rendered through a framework which translated the XML tree into draw calls using platform-specific APIs.
This system grants a great deal of power to extensions but also complicates the addition of new UI elements since the devs first need to write the XML and then extend the XPCOM interface to call the new C++ routines from JavaScript since all of the UI interaction in XUL triggers JavaScript code (at least the last time I looked into it).
I'm fairly certain that a lot of the performance improvements in Firefox Quantom came from them dropping XUL and XPCOM since that's one of biggest changes they made. However, that change also made it impossible to support the old extensions.

In the end, I think Mozilla had a lot of good reasons for what they did. However, they handled the communication with extension developers horribly (would it have been so hard to give them just a simple heads-up?!).
Sorry for the wall of text. As someone who has worked with the source code from both browsers, I just felt the need to clarify a few things.

TL;DR: The UI and sandbox issues are completely separate and unrelated. Fun fact: Chrome will have tab previews on hover in future stable versions which further illustrate this point (the preview is handled by the host process, not the tab renderer).

EDIT: Typos