9 ms·

WebExtensions in Firefox 48

106 points by matteotom 10y ago

nathancahill 10y ago
The topic's been discussed to death, but I'm really disappointed that Firefox extensions have gone the direction of Chrome's. Sure, it's nice to have compatibility, but at the cost of Firefox's more powerful extensions? No thank you.
- jd3 10y ago
  Yeah it's honestly pretty disgusting. Mozilla's strong add-on system has been one of their largest advertisable features for /years/. Just because a bunch of people have switched to inferior webkit/blink based browsers doesn't necessarily mean that the opposition's technology is superior. If I were the head of Mozilla, I'd get rid of everyone who has suggested: removing complete themes, removing the XUL/XPCOM add-ons and SDK, cutting off support for thunderbird/SeaMonkey/etc. Servo is an interesting browser project, but it's also a /separate/ project. They need to stop focusing on stupid fluff like pocket/hello/etc; instead, focus on bug zapping and core technology improvements (HTML5, etc.) If Mozilla continues gimping their core software any more, their user base will literally be 0. Disclaimer: I am an ardent supported of the Suite (SeaMonkey) and everything Mozilla will be doing in the next year will probably completely kill it (ChatZilla, themes, add-ons, etc.) Example: by this time next year, pretty much nothing you see here will be possible in SeaMonkey anymore thanks to the idiotic decisions from the Mozilla top brass: http://i.imgur.com/g4SwoFa.png http://i.imgur.com/g4SwoFa.png http://i.imgur.com/uDHcZpw.png http://i.imgur.com/uDHcZpw.png http://i.imgur.com/fO4Qz8A.png http://i.imgur.com/fO4Qz8A.png
  - yuhong 10y ago
    I have been thinking that the move to Servo and browser.html is a good time to do things like restore customizable toolbars, since the UI would need to be rewritten anyway.
    - pcwalton 10y ago
      browser.html doesn't even have toolbars.
  - nwah1 10y ago
    You have a misunderstanding of what is going on. Hello, for instance, is not some sort of project is draining resources and/or bloating firefox. It is essentially a WebRTC demonstration. Since WebRTC is a technology that needs to be implemented anyways, and is worth promoting, Hello becomes very interesting. It is basically just a little bit of javascript that runs on top of all the WebRTC code that they'd have to build anyways. Trying to do cross-platform screensharing, for instance, can be quite a hassle, but this will allow it to be done all without any sort of plugins, or any need for TeamViewer, GotoMeeting, etc. And as for XUL and XPCOM, they've already been moving away from it internally for years. It is horrible. Talk about bloat and security problems. And they already are needing to rewrite their APIs for things like Electrolysis, which I assume we want. So why not actually do a good job with the rewrite? The ultimate goal is to have the UI based on web standards (browser.html). This will reduce bloat and reduce the attack surface. And the UI will only get more customizable as a result.
    - nathancahill 10y ago
      > the UI will only get more customizable as a result. It's not the UI, it's the APIs behind powerful addons like Firebug that made Firefox the browser that it is. Those powerful APIs are going, going, gone.
      - clouddrover 10y ago
        Firebug 3 integrates with Firefox's native DevTools so you'll still have Firebug (or you can just use Firefox's DevTools without Firebug if you want): https://hacks.mozilla.org/2015/10/firebug-devtools-integration/ https://hacks.mozilla.org/2015/10/firebug-devtools-integrati...
        nathancahill 10y ago
        Firebug isn't what's at stake here. It's the level of API access to browser internals that allowed things like Firebug to be built.
        10y ago
  - aswan 10y ago
    It's remarkable the extent to which people assume the worst every time this topic comes up. The Mozilla stance has always been that the add-on community is a huge asset but that supporting add-ons based on XUL, XPCOM, and the SDK imposes real costs in security, performance, and maintainability. The plan, intended to keep the benefits while addressing the problems, is to migrate to a new set of APIs -- web extensions. This is meant to be a migration, not a narrowing of the capabilities -- building compatibility for existing Chrome extensions is just the first step in this plan, when that foundation is in place the next steps are to extend the webextensions APIs to keep expanding the set of add-ons that can be written as webextensions. A transition like this has two halves: adding the new (performant, maintainable, secure) APIs and deprecating the old ones. Comments like the one above jump to the bizarre conclusion that Mozilla will decide to remove of the old APIs but never add the new ones. The closest thing to an explanation for why this would happen is ... uh, something about pocket and hello?
    - kuschku 10y ago
      Mozilla has publicly said several times that they will NOT provide the same set of APIs. What we want is the ability to modify the whole browser chrome as if it was a website, and the ability to modify every action that happens in the browser. (For example, for tree style tabs, or a tab bar at the bottom, or stuff like redirecting some keypresses to other processes). Vivaldi does provide these things. Vivaldi allows users to literally rewrite 100% of the actual browser with simple JS addons. Mozilla should provide at least what Vivaldi provides.
    - protomyth 10y ago
      > XUL, XPCOM, and the SDK imposes real costs in security, performance, and maintainability. Is there some report on the security implications of supporting XUL?
    - the8472 10y ago
      In my eyes mozilla's stance on security is patronizing towards power-users because it assumes that every addon and every non-root application on the system is potentially hostile. Thus the goal is to prevent free interaction between processes or between addons and native in general (unix philosophy anyone?). Everyone has to suffer just to protect those who click on "yes, install" whenever prompted. The result are less powerful APIs in the name of security. Just look at addon signing. Mozilla refuses to add an off switch to that (and thus user control) because they fear that some other processes already running on the user's computer might inject unsigned addons. In my eyes this is a crazy kind of threat model that basically writes off the user's system security as a lost cause and tries to defend FF against that lost cause. It's elevating mozilla's needs over interoperability between applications. Imagine if awk refused to run unless the parent process is bash, signed by canonical, because they deemed some other shell's argument expansion as potentially confusing to the user or something like that. Crazy, right?
  - pjmlp 10y ago
    > Yeah it's honestly pretty disgusting. Mozilla's strong add-on system has been one of their largest advertisable features for /years/. Just because a bunch of people have switched to inferior webkit/blink based browsers doesn't necessarily mean that the opposition's technology is superior. For me, even though I also do web development now and then, the web should have stayed as interactive hypermedia documents. What matters are network protocols. I always use native applications, when given the option. As such, I never cared for add-ons other than dictionaries. Blocking ads and nasty JavaScript sites? That is what the computer networking configuration is for.
    - the8472 10y ago
      > Blocking ads and nasty JavaScript sites? That is what the computer networking configuration is for. If everything is behind cloudflare IPs and piped through TLS that gets more difficult. And you'd have to defeat all the certificate-pinning/sts/etc. security just to filter some stuff. On the other hand the browser has more knowledge about each request, e.g. whether it's actually intended to be executed as javascript or loaded as an image etc.
      - pjmlp 10y ago
        Yeah, but the other hand you have Adblockers selling themselves out with exceptions for partner companies.
        the8472 10y ago
        There are a dozen content- and ad-blockers. Only one or two do what you mention.
- rpgmaker 10y ago
  They also "updated" the search box, beside extensions the main reason why I still prefer it over Chrome. Firefox is slowly but surely becoming unbearable. It's a real tragedy that its market share has suffered as much as it has but Chrome users aren't coming back. If they keep this Chrome-ization their remaining users just won't see any reason to choose Firefox over Chrome and they will leave.
  - nol13 10y ago
    Still, an extension for a popular message board that was being developed was about to get me to switch to Chrome, but turns out that with almost no modifications it works great in Firefox nightly too! If not for that there's no way anyone was going to bother to port it.
  - giovannibajo1 10y ago
    Yeah I agree. Firefox is slowly becoming a Chrome clone. It took them a long while to migrate everything to follow the Chrome lead (release strategy, update strategy, multiprocess architecture, sandboxing, extension API, HTML UI, etc.) but I wonder what's the benefit of having two identical browsers. Yes the HTML engine is different but then so what, I don't think end users are ever going to switch because of HTML engines.
    - nathancahill 10y ago
      Privacy is a big reason I'm still using Firefox over Chrome.
    - derefr 10y ago
      Does there need to be a difference? Having two independent "rival" implementations of every feature is useful for the health of the web development ecosystem. The two apps could just be completely interchangeable from a user's perspective—a single site giving users one or the other for download at random—and that would still be true.
      - malka 10y ago
- clouddrover 10y ago
  > but at the cost of Firefox's more powerful extensions? What do you believe you'll be missing? Add-on authors say the new API will meet their needs. Giorgio Maone, the author of NoScript, says he's satisfied with the direction of the development of the new API: https://hackademix.net/2016/03/09/webrequest-where-were-where-were-going/ https://hackademix.net/2016/03/09/webrequest-where-were-wher... If you develop some add-on that needs features the new API doesn't currently provide then I'd say the best thing to do is to get involved with the development and get those features added.
  - Veratyr 10y ago
    Does the new API support things like tree style tabs [0]? This is one of the things I've failed to see other browsers implement. [0] https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/ https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...
    - detaro 10y ago
      The second link in the article goes to the WebExtensions overview page, which mentions "Tree Style Tabs" by name as something that new APIs need to be build for. https://wiki.mozilla.org/WebExtensions https://wiki.mozilla.org/WebExtensions
    - clouddrover 10y ago
      If it doesn't yet, it will. Support for add-ons like Tree Style Tabs has been on their radar since development of the new API started: 1. https://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-changes/ https://billmccloskey.wordpress.com/2015/08/21/firefox-add-o... 2. https://wiki.mozilla.org/WebExtensions#Additional_APIs https://wiki.mozilla.org/WebExtensions#Additional_APIs 3. https://wiki.mozilla.org/WebExtensions/RoadMap https://wiki.mozilla.org/WebExtensions/RoadMap
      - the8472 10y ago
        That just means that certain popular addons will get the support necessary to have their needs satisfied. Some niche ideas won't get support and thus die. That's the problem with a gated system where you can only do things approved by HQ.
lewisl9029 10y ago
I've been working on a very simple WebExtension [1] lately, mostly to experiment with the API and familiarize myself with extensions development in general, and the reload functionality and compatibility improvements are definitely very welcome additions. I would also prefer to have the extensions debugging controls available in the about:addons page as opposed to in a separate about:debugging page, similar to how Chrome's chrome://extensions/ page is organized. Also, I'm curious if there are any plans to implement something like Chrome's event pages [2] as an alternative to having a background page running constantly for extensions that don't require a long-running process? [1] https://github.com/lewisl9029/just-save-webextension https://github.com/lewisl9029/just-save-webextension [2] https://developer.chrome.com/extensions/event_pages https://developer.chrome.com/extensions/event_pages
TazeTSchnitzel 10y ago
Firefox is taking a subset of Chrome's API, and adding its own pieces. I wonder if some of Firefox's additions will make their way back to Chrome.
BuckRogers 10y ago
I've used Firefox since about 2001 when it was in beta and I agree with those that say this isn't an improvement. It seems like control. You need Mozilla to approve of any advanced API you may need access to. It's probably high time to write a libre browser that focuses on being completely customizable. And not focus primarily on speed. I'm bewildered by those who are deadset on that over all else, it just serves into the goals of for-profits who can dump tremendous resources into optimizing to bamboozle away freedom. Freedom doesn't cost millions of dollars. A libre Vivaldi, with a tighter feature scope (no email client etc) is where it would be at.
- drdaeman 10y ago
  <offtopic rant="yes" sorry="i am"> I always really wanted a browser that'd be just a bunch of programs adhering to UNIX philosophy and then striving for simplicity. I mean, components interacting together by talking to each other through the simplest means available, with simplest protocols possible, and with every component being freely swappable. But without a DIY approach to things - instead, trying to bring a Firefox/Chrome-like experience by default, but being hackable and with everything very loosely coupled under the hood. uzbl is somewhat close, but it's not really portable and still a has a pretty big monolithic webkit engine component, that handles rendering, scripting and networking. </offtopic>
- alexvoda 10y ago
  I would point you towards this: https://kver.wordpress.com/2015/09/18/on-ad-blocking-tracking-and-privacy-in-fiber/ https://kver.wordpress.com/2015/09/18/on-ad-blocking-trackin... Unfortunately development is at a standstill right now. More hands on deck are needed. If other people will not participate at first it might not even use CEF as planned. Using CEF would be great because it will eventually allow it to use both Servo and Blink. Also worth mentioning is the other (than Vivaldi) let's recreate classic Opera project: http://otter-browser.org/ http://otter-browser.org/ Of course both of these are very very young projects and aren't really ready to replace Firefox.

106 points by matteotom 10y ago

The topic's been discussed to death, but I'm really disappointed that Firefox extensions have gone the direction of Chrome's. Sure, it's nice to have compatibility, but at the cost of Firefox's more powerful extensions? No thank you.

jd3 10y ago
Yeah it's honestly pretty disgusting. Mozilla's strong add-on system has been one of their largest advertisable features for /years/. Just because a bunch of people have switched to inferior webkit/blink based browsers doesn't necessarily mean that the opposition's technology is superior. If I were the head of Mozilla, I'd get rid of everyone who has suggested: removing complete themes, removing the XUL/XPCOM add-ons and SDK, cutting off support for thunderbird/SeaMonkey/etc. Servo is an interesting browser project, but it's also a /separate/ project. They need to stop focusing on stupid fluff like pocket/hello/etc; instead, focus on bug zapping and core technology improvements (HTML5, etc.) If Mozilla continues gimping their core software any more, their user base will literally be 0. Disclaimer: I am an ardent supported of the Suite (SeaMonkey) and everything Mozilla will be doing in the next year will probably completely kill it (ChatZilla, themes, add-ons, etc.) Example: by this time next year, pretty much nothing you see here will be possible in SeaMonkey anymore thanks to the idiotic decisions from the Mozilla top brass: http://i.imgur.com/g4SwoFa.png http://i.imgur.com/g4SwoFa.png http://i.imgur.com/uDHcZpw.png http://i.imgur.com/uDHcZpw.png http://i.imgur.com/fO4Qz8A.png http://i.imgur.com/fO4Qz8A.png
- yuhong 10y ago
  I have been thinking that the move to Servo and browser.html is a good time to do things like restore customizable toolbars, since the UI would need to be rewritten anyway.
  - pcwalton 10y ago
    browser.html doesn't even have toolbars.
- nwah1 10y ago
  You have a misunderstanding of what is going on. Hello, for instance, is not some sort of project is draining resources and/or bloating firefox. It is essentially a WebRTC demonstration. Since WebRTC is a technology that needs to be implemented anyways, and is worth promoting, Hello becomes very interesting. It is basically just a little bit of javascript that runs on top of all the WebRTC code that they'd have to build anyways. Trying to do cross-platform screensharing, for instance, can be quite a hassle, but this will allow it to be done all without any sort of plugins, or any need for TeamViewer, GotoMeeting, etc. And as for XUL and XPCOM, they've already been moving away from it internally for years. It is horrible. Talk about bloat and security problems. And they already are needing to rewrite their APIs for things like Electrolysis, which I assume we want. So why not actually do a good job with the rewrite? The ultimate goal is to have the UI based on web standards (browser.html). This will reduce bloat and reduce the attack surface. And the UI will only get more customizable as a result.
  - nathancahill 10y ago
    > the UI will only get more customizable as a result. It's not the UI, it's the APIs behind powerful addons like Firebug that made Firefox the browser that it is. Those powerful APIs are going, going, gone.
    - clouddrover 10y ago
      Firebug 3 integrates with Firefox's native DevTools so you'll still have Firebug (or you can just use Firefox's DevTools without Firebug if you want): https://hacks.mozilla.org/2015/10/firebug-devtools-integration/ https://hacks.mozilla.org/2015/10/firebug-devtools-integrati...
      - nathancahill 10y ago
        Firebug isn't what's at stake here. It's the level of API access to browser internals that allowed things like Firebug to be built.
        10y ago
- aswan 10y ago
  It's remarkable the extent to which people assume the worst every time this topic comes up. The Mozilla stance has always been that the add-on community is a huge asset but that supporting add-ons based on XUL, XPCOM, and the SDK imposes real costs in security, performance, and maintainability. The plan, intended to keep the benefits while addressing the problems, is to migrate to a new set of APIs -- web extensions. This is meant to be a migration, not a narrowing of the capabilities -- building compatibility for existing Chrome extensions is just the first step in this plan, when that foundation is in place the next steps are to extend the webextensions APIs to keep expanding the set of add-ons that can be written as webextensions. A transition like this has two halves: adding the new (performant, maintainable, secure) APIs and deprecating the old ones. Comments like the one above jump to the bizarre conclusion that Mozilla will decide to remove of the old APIs but never add the new ones. The closest thing to an explanation for why this would happen is ... uh, something about pocket and hello?
  - kuschku 10y ago
    Mozilla has publicly said several times that they will NOT provide the same set of APIs. What we want is the ability to modify the whole browser chrome as if it was a website, and the ability to modify every action that happens in the browser. (For example, for tree style tabs, or a tab bar at the bottom, or stuff like redirecting some keypresses to other processes). Vivaldi does provide these things. Vivaldi allows users to literally rewrite 100% of the actual browser with simple JS addons. Mozilla should provide at least what Vivaldi provides.
  - protomyth 10y ago
    > XUL, XPCOM, and the SDK imposes real costs in security, performance, and maintainability. Is there some report on the security implications of supporting XUL?
  - the8472 10y ago
    In my eyes mozilla's stance on security is patronizing towards power-users because it assumes that every addon and every non-root application on the system is potentially hostile. Thus the goal is to prevent free interaction between processes or between addons and native in general (unix philosophy anyone?). Everyone has to suffer just to protect those who click on "yes, install" whenever prompted. The result are less powerful APIs in the name of security. Just look at addon signing. Mozilla refuses to add an off switch to that (and thus user control) because they fear that some other processes already running on the user's computer might inject unsigned addons. In my eyes this is a crazy kind of threat model that basically writes off the user's system security as a lost cause and tries to defend FF against that lost cause. It's elevating mozilla's needs over interoperability between applications. Imagine if awk refused to run unless the parent process is bash, signed by canonical, because they deemed some other shell's argument expansion as potentially confusing to the user or something like that. Crazy, right?
- pjmlp 10y ago
  > Yeah it's honestly pretty disgusting. Mozilla's strong add-on system has been one of their largest advertisable features for /years/. Just because a bunch of people have switched to inferior webkit/blink based browsers doesn't necessarily mean that the opposition's technology is superior. For me, even though I also do web development now and then, the web should have stayed as interactive hypermedia documents. What matters are network protocols. I always use native applications, when given the option. As such, I never cared for add-ons other than dictionaries. Blocking ads and nasty JavaScript sites? That is what the computer networking configuration is for.
  - the8472 10y ago
    > Blocking ads and nasty JavaScript sites? That is what the computer networking configuration is for. If everything is behind cloudflare IPs and piped through TLS that gets more difficult. And you'd have to defeat all the certificate-pinning/sts/etc. security just to filter some stuff. On the other hand the browser has more knowledge about each request, e.g. whether it's actually intended to be executed as javascript or loaded as an image etc.
    - pjmlp 10y ago
      Yeah, but the other hand you have Adblockers selling themselves out with exceptions for partner companies.
      - the8472 10y ago
        There are a dozen content- and ad-blockers. Only one or two do what you mention.
rpgmaker 10y ago
They also "updated" the search box, beside extensions the main reason why I still prefer it over Chrome. Firefox is slowly but surely becoming unbearable. It's a real tragedy that its market share has suffered as much as it has but Chrome users aren't coming back. If they keep this Chrome-ization their remaining users just won't see any reason to choose Firefox over Chrome and they will leave.
- nol13 10y ago
  Still, an extension for a popular message board that was being developed was about to get me to switch to Chrome, but turns out that with almost no modifications it works great in Firefox nightly too! If not for that there's no way anyone was going to bother to port it.
- giovannibajo1 10y ago
  Yeah I agree. Firefox is slowly becoming a Chrome clone. It took them a long while to migrate everything to follow the Chrome lead (release strategy, update strategy, multiprocess architecture, sandboxing, extension API, HTML UI, etc.) but I wonder what's the benefit of having two identical browsers. Yes the HTML engine is different but then so what, I don't think end users are ever going to switch because of HTML engines.
  - nathancahill 10y ago
    Privacy is a big reason I'm still using Firefox over Chrome.
  - derefr 10y ago
    Does there need to be a difference? Having two independent "rival" implementations of every feature is useful for the health of the web development ecosystem. The two apps could just be completely interchangeable from a user's perspective—a single site giving users one or the other for download at random—and that would still be true.
    - malka 10y ago
clouddrover 10y ago
> but at the cost of Firefox's more powerful extensions? What do you believe you'll be missing? Add-on authors say the new API will meet their needs. Giorgio Maone, the author of NoScript, says he's satisfied with the direction of the development of the new API: https://hackademix.net/2016/03/09/webrequest-where-were-where-were-going/ https://hackademix.net/2016/03/09/webrequest-where-were-wher... If you develop some add-on that needs features the new API doesn't currently provide then I'd say the best thing to do is to get involved with the development and get those features added.
- Veratyr 10y ago
  Does the new API support things like tree style tabs [0]? This is one of the things I've failed to see other browsers implement. [0] https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/ https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...
  - detaro 10y ago
    The second link in the article goes to the WebExtensions overview page, which mentions "Tree Style Tabs" by name as something that new APIs need to be build for. https://wiki.mozilla.org/WebExtensions https://wiki.mozilla.org/WebExtensions
  - clouddrover 10y ago
    If it doesn't yet, it will. Support for add-ons like Tree Style Tabs has been on their radar since development of the new API started: 1. https://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-changes/ https://billmccloskey.wordpress.com/2015/08/21/firefox-add-o... 2. https://wiki.mozilla.org/WebExtensions#Additional_APIs https://wiki.mozilla.org/WebExtensions#Additional_APIs 3. https://wiki.mozilla.org/WebExtensions/RoadMap https://wiki.mozilla.org/WebExtensions/RoadMap
    - the8472 10y ago
      That just means that certain popular addons will get the support necessary to have their needs satisfied. Some niche ideas won't get support and thus die. That's the problem with a gated system where you can only do things approved by HQ.

lewisl9029 10y ago

I've been working on a very simple WebExtension [1] lately, mostly to experiment with the API and familiarize myself with extensions development in general, and the reload functionality and compatibility improvements are definitely very welcome additions. I would also prefer to have the extensions debugging controls available in the about:addons page as opposed to in a separate about:debugging page, similar to how Chrome's chrome://extensions/ page is organized. Also, I'm curious if there are any plans to implement something like Chrome's event pages [2] as an alternative to having a background page running constantly for extensions that don't require a long-running process? [1] https://github.com/lewisl9029/just-save-webextension https://github.com/lewisl9029/just-save-webextension [2] https://developer.chrome.com/extensions/event_pages https://developer.chrome.com/extensions/event_pages

TazeTSchnitzel 10y ago

Firefox is taking a subset of Chrome's API, and adding its own pieces. I wonder if some of Firefox's additions will make their way back to Chrome.

BuckRogers 10y ago

I've used Firefox since about 2001 when it was in beta and I agree with those that say this isn't an improvement. It seems like control. You need Mozilla to approve of any advanced API you may need access to. It's probably high time to write a libre browser that focuses on being completely customizable. And not focus primarily on speed. I'm bewildered by those who are deadset on that over all else, it just serves into the goals of for-profits who can dump tremendous resources into optimizing to bamboozle away freedom. Freedom doesn't cost millions of dollars. A libre Vivaldi, with a tighter feature scope (no email client etc) is where it would be at.

drdaeman 10y ago
<offtopic rant="yes" sorry="i am"> I always really wanted a browser that'd be just a bunch of programs adhering to UNIX philosophy and then striving for simplicity. I mean, components interacting together by talking to each other through the simplest means available, with simplest protocols possible, and with every component being freely swappable. But without a DIY approach to things - instead, trying to bring a Firefox/Chrome-like experience by default, but being hackable and with everything very loosely coupled under the hood. uzbl is somewhat close, but it's not really portable and still a has a pretty big monolithic webkit engine component, that handles rendering, scripting and networking. </offtopic>
alexvoda 10y ago
I would point you towards this: https://kver.wordpress.com/2015/09/18/on-ad-blocking-tracking-and-privacy-in-fiber/ https://kver.wordpress.com/2015/09/18/on-ad-blocking-trackin... Unfortunately development is at a standstill right now. More hands on deck are needed. If other people will not participate at first it might not even use CEF as planned. Using CEF would be great because it will eventually allow it to use both Servo and Blink. Also worth mentioning is the other (than Vivaldi) let's recreate classic Opera project: http://otter-browser.org/ http://otter-browser.org/ Of course both of these are very very young projects and aren't really ready to replace Firefox.