updates Meet the browser: Firefox Next

[francescob]

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.

[The_Decryptor Veteran]

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.

[francescob]

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 August 13, 2015 by francescob

[Neyht Member]

This is new to me.  Do you see it?

Hint: it's in the tabs.  Don't think it's been mentioned before.

[bawz]

This is new to me.  Do you see it?

Hint: it's in the tabs.  Don't think it's been mentioned before.

it was there in mid/late 42 i believe. so not new

[Konstantine]

Hangouts is broken on the last 2-3 Nightly builds. Either on Google+, Gmail or Inbox, I cannot view my messages. it just shows a white list. I tried with Edge and everything works fine. Can anyone else confirm?

[+Heartripper Subscriber¹]

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.

[AndyAmo]

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 August 20, 2015 by AndyAmo
Just in case

[+Heartripper Subscriber¹]

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.

[Coxlap]

I saw mention of Multi Process??? Does that mean Firefox is multi threaded in the new builds...Aka fast?

[Karl-Johan]

There's a bug filed for this. 1196403 – [e10s] Firefox x64 does not work on Windows 10 Build 10525

[kozukumi]

I saw mention of Multi Process??? Does that mean Firefox is multi threaded in the new builds...Aka fast?

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

[ViperAFK]

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.

[+Frank B. Subscriber²]

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. 

[BooBerry]

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.

 

[+Frank B. Subscriber²]

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. 

[BooBerry]

Mozilla’s self-destruct course continues: major add-on compatibility changes announced

[dysgenics]

better bold it

[Boo Berry]

 

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.

[bawz]

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.

[The_Decryptor Veteran]

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 August 22, 2015 by The_Decryptor

[kozukumi]

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. 

[Max Norris]

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*

[The_Decryptor Veteran]

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.

[BooBerry]

Reactions to Mozilla’s announcement about upcoming Firefox add-on changes