[Mito [PL]]

Re: current discussion - I remember that once upon a time, Opera had a bunch of additional statistics you could look at on per-tab basis. For example, a simple value of current transfer speed for the currently open tab slapped somewhere in the bottom corner. Wy did it have to go? I would really find it useful.

So, from what I've read here... Does that mean there's still quite some time until extensions start becoming available for Firefox again? I like using Firefox as my main browser, but I also like using AdBlock .

[The E]

[...] 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 acutal 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 it's 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. This is also one of the reasons extension developers were so 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 extenions 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 wanted to 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 developer 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).

This is good information that I was unaware of.

[The E]

So, from what I've read here... Does that mean there's still quite some time until extensions start becoming available for Firefox again? I like using Firefox as my main browser, but I also like using AdBlock .

Mozilla issued an update on May 6th that should have fixed this.