Recommended Posts

How do you think the content blocking addons work? The browser calls into their code for every single resource load.

That's the point, Safari native content-blocking (ships with iOS 9) doesn't. There's no continuous interaction between the browser and the addon, no slow javascript code, no giant RAM-wasting stylesheets. It takes the filters directly from the add-on and does the handling itself, a bit like Microsoft TPL lists but with more complex rules.

Ahh, ok, I assumed Safari had a proper content blocking API, seems it's just a simple list format though.

The big difference is that content blockers in Firefox (And Chrome I assume) can identify the context the resource is being loaded from, that's why something like NoScript can block a specific resource on a specific domain unless it's loaded under a specific condition. The Safari API on the other hand is just a simple list of things to block, and some simple logic to go with it (i.e. block resource X unless domain is Y), the problem is that if you go beyond very simple blocks, you start ballooning out the logic blocks (How do you allow resource X on Site A, but not on Site B, unless Site B is loaded under HTTPS?)

That being said, you could probably implement the Safari method currently because Firefox already has a list based content blocker built in, it's sued for Safe Browsing the Tracking Protection. Whether or not addons want to make use of that is a different matter of course.

It doesn't need to be like the Safari implementation, Firefox could implement all the conditions used by the Adblock filters so that all the blocking can be done natively with a much smaller performance hit. And even if Adblock would need some super-special-complex check it could still be done at runtime, native and addon checks don't have to be mutually exclusive. Also Safe browsing and Tracking Protection AFAIK only block URLs, Safari instead allows element blocking like Adblock.

Edited by francescob

Is it only me or Nightly doesn't work on Windows 10 10525? All I get is a white page with an everlasting spinning circle when I try to load a website.

64bit Nightly is broken much like Google Chrome, under Windows Insider Preview build 10525. Uncheck "multi-process Nightly"  (E10) in the General Options panel and it should work fine.  Not sure if 32bit Nightly has the same problem.

Also... I did do re-install first and check the status of your extensions, mine all seem to disappear from Firefox and from Nightly when I upgraded Windows.

Edited by AndyAmo
Just in case
  • Like 1

64bit Nightly is broken much like Google Chrome, under Windows Insider Preview build 10525. Uncheck "multi-process Nightly"  (E10) in the General Options panel and it should work fine.  Not sure if 32bit Nightly has the same problem.

Also... I did do re-install first and check the status of your extensions, mine all seem to disappear from Firefox and from Nightly when I upgraded Windows.

Thank you very much, disabling muli-process made firefox work. Apart from this, firefox was unaffected by the upgrade, my extensions were there after I installed the insider build.

Yes it is multi-process (it is already multi-threaded) but it doesn't make it any faster but more stable.

multi process can help with UI responsivness, since content and UI are now separated. Content loading should no longer hang up the UI as much. Its one of the reason chrome 'feels' faster than firefox.

From https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ :

Today we are announcing some major upcoming changes to Firefox add-ons. Our add-on ecosystem has evolved through incremental, organic growth over the years, but there are some modernizations to Firefox that require some foundational changes to support:

  • Taking advantage of new technologies like Electrolysis and Servo
  • Protecting users from spyware and adware
  • Shortening the time it takes to review add-ons

To help the add-on development community understand how we will enable these improvements, we are making four related announcements today:

  • We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers.
  • A safer, faster, multi-process version of Firefox is coming soon with Electrolysis; we needdevelopers to ensure their Firefox add-ons will be compatible with it.
  • To ensure third-party extensions provide customization without sacrificing security, performance or exposing users to malware, we will require all extensions to be validated and signed by Mozilla starting in Firefox 41, which will be released on September 22nd 2015.
  • We have decided on an approximate timeline for the deprecation of XPCOM- and XUL-based add-ons

Firefox is going to change a lot in the short to mid-term future. 

As part of this, they'll be implementing the new WebExtensions API that is "largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers." Add-ons will also support Electrolysis for the faster, multi-process version of Firefox.

With Firefox 41, Mozilla will also require all extensions be validated and signed by the browser company. Mozilla will also begin deprecating XUL and XPCOM add-ons.

They must be loosing momentum fast. Because one of the last reasons to use Firefox over Chrome is the richer add-on library.

But you can sill have "native" addons ??

I think the Webextension Api is primarily a preparation for the new Servo engine, since there is a discussion to replace XUL by web technologies.

 

  • Like 7

XUL-based 'native' add-ons will be deprecated sooner rather than later. Prepare to say good-bye to Firefox as we know it; in the future it'll be much more like Google Chrome. 

 

Deprecation of XUL, XPCOM and the permissive add-on model

The deprecation will take place within 12 to 18 months, and Mozilla plans to continue to support SDK add-ons as long as they don't use require ('chrome') or low-level APIs that provide access to XUL elements.

The add-on model that XUL and XPCOM provide give add-ons full access to Firefox's internal implementation.

The tight interaction between browser and add-ons cause short and long term problems. Mozilla mentions the release of Electrolysis and the breaking of add-ons as an example.

The organization plans to extend the WebExtension API to support "as much of the functionality needed by the most popular Firefox extensions as possible".

That's not good for anyone who uses extensions to change/fix things in Firefox's UI (e.g. Classic Theme Restorer). Taking away customization and user choice, I have a feeling, won't bode well for Mozilla in the long run. My guess is they'll lose a lot of users over this and their market share will diminish even more.

as knew this was gonna happen eventually, XUL has been dead  for ages. time an Technology moves on. the Desktop Browser is nearly Dead, its all Mobile or phablet or ipad now. i'll miss Firefox as it is now but there are other Browsers out there, its called CHOICE.

People have been calling for HTML/CSS extensions for ages (Even though Firefox supported them), Mozilla says ok and suddenly everybody wants XUL extensions back again.

Edit: I'd say the main reason is that they want to deprecate XUL entirely, it's from an earlier era of the web where you couldn't create useful UIs with HTML, but now you can. It's also a pain to work with restartless addons, they've been trying to deprecate XPCOM for years too, and none of these extensions worked properly with the Android release (Or Firefox OS)

Edit 2: Also, this new extension model is more closely aligned with Chrome/Edge/Safari, that's not a bad thing.

Edit 3: Since I'm on a roll, they also want to run extensions in a separate process to avoid memory leaks and crashes, guess what doesn't work with XUL/XPCOM.

Edited by The_Decryptor

The_Decrypter, what you said is all true however XUL addons is what made Firefox better than Chrome/Edge/Safari. If Firefox is limited in the same way as C/E/S when it comes to extensions what added value do I get using Firefox? Why not just use Chrome? I have stuck with Firefox all these years (since the early Phoenix days) because of how powerful some extensions were. Even when Chrome came along with its super fast JS engine and more stable browser I stayed with Firefox. In a years time it is basically just going to be a Chrome clone using a different rendering engine. 

The_Decrypter, what you said is all true however XUL addons is what made Firefox better than Chrome/Edge/Safari. If Firefox is limited in the same way as C/E/S when it comes to extensions what added value do I get using Firefox? Why not just use Chrome? I have stuck with Firefox all these years (since the early Phoenix days) because of how powerful some extensions were. Even when Chrome came along with its super fast JS engine and more stable browser I stayed with Firefox. In a years time it is basically just going to be a Chrome clone using a different rendering engine. 

That's pretty much was I was thinking too -- If the Chrome-like HTML/CSS extensions were in addition to the existing XUL addons, hey great, I'm all for it.  Deprecating XUL entirely though pretty much just makes Firefox "yet another Chromium fork/knockoff", which we've got tons to pick from already. I mean seriously, I can use a different browser every day of the week... meh.  There's a lot of functionality that Chrome just can't possibly do that Firefox can, and tossing that functionality in the trash is going to make this browser totally pointless, I'll just go back to Chrome (or eventually Edge once the extensions are there) and watch Firefox go the way of Mosaic and Netscape.  I was hoping that Mozilla was getting back on their game by improving things, adding features, etc etc, but this.. *sigh*

XUL is just the UI layout markup, not sure why anybody is going to miss that (As in, Mozilla wants to remove it entirely from Firefox, not just addons). They're moving more towards the Vivaldi model of using plain HTML/CSS for the interface, vs. custom XML and custom CSS layout properties.

XPCOM is what you guys are upset about, but that's still ehh. There's absolutely nothing stopping Mozilla from exposing similar APIs to the new style addons (And the NoScript author has already said that it'll make the transition, and it's a pretty low level content blocker). The difference is now that the devs can choose what APIs to expose, instead of just letting addons poke around the internals (And do stupid things like replace the HTTP protocol handler), it'll also get rid of their compatibility issues between releases, something people have been complaining about ever since Mozilla switched to a rapid release schedule. It doesn't stop addons calling into native code either, Mozilla has been pushing ctypes for that for a long time.

Edit: Also, Firefox for Android and Firefox OS, it'll unify the addon model across all their variants, instead of just desktop Firefox.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now