6 ms·

> In the absence of a true standard for browser extensions, maintaining compatibility with Chrome is important for Firefox developers and users. About as close

> In the absence of a true standard for browser extensions, maintaining compatibility with Chrome is important for Firefox developers and users. About as close as Mozilla can come to outright saying, "Chrome is big enough and we're small enough that what they do _is_ the standard." Still, it's encouraging to see that they're not removing the blocking API for now. I kind of hope this does push a few adblocker extensions to abandon Chrome.

zzzcpan 7y ago
I find it rather discouraging to hear they are not removing the blocking API for now. It's basically an empty statement, not reassurance. They still may or may not remove the API, they don't want to promise anything or show any commitment to users' needs and priorities.
- wtallis 7y ago
  It's basically the same as what happened two months ago with Firefox for Android being EOL'd pending a major re-write that may or may not support extensions. Mozilla is not willing to publicly commit to keeping their key features alive, and they keep hinting at the possibility that they will be leaving users behind in an attempt to be more like Chrome.
  - Jonnax 7y ago
    A rewrite that is faster than Chrome for Android.
    - hajile 7y ago
      It may be faster than Chrome on Android, but it's certainly not faster than Firefox on Android with adblockers. Not loading/parsing multi-megabytes of Javascript and images is huge. Loads of ads these days incorporate entire JS framework toolchains resulting in a binary bigger than the page they're being injected into. Eliminating a few ads and the rest of your browser could be a lot less efficient and still perform well. That's all before discussing how adblockers also reduce who is tracking you everywhere.
      - Jonnax 7y ago
        It certainly is faster than Firefox for Android. There are benefits to adblocking of course. But there's no point lying.
      - tgsovlerkhgsel 7y ago
        In my experience and limited testing, even with warmed-up caches, Chrome (without Adblocker) was faster than Firefox (with or without Adblocker), sadly. I still use Firefox due to the security benefits of ad blocking, but I don't find the experience particularly enjoyable (although, thinking of it, it may have either significantly improved in the past ~half a year, or I just don't notice because of a more powerful CPU in my new phone).
    - bscphil 7y ago
      Eh. That may be the intent but they aren't there yet. I tested Firefox Preview on Speedometer 2.0 and got the same result I did with Firefox for Android 68. Chrome gets double the score (runs per minute) on my device.
  - lol768 7y ago
    And the other point of view, directly from Mozilla: > We're certainly aware of how significant ad blocking extensions are. This release required a great quantity of features with only a six month timeline until now. > We already support a very limited set of the WebExtensions API to offer features like Reader Mode. Rest assured that more features will land in the coming months. Source: https://news.ycombinator.com/item?id=20298143 https://news.ycombinator.com/item?id=20298143 This reads like FUD to me. The dev team know how important extensions are to their users. Can you provide a source that implies Fennec will be EOL before Fenix has extension and/or ad-blocking support?
    - mjw1007 7y ago
      In that discussion (and indeed in the message you quote), the mozilla developers had every incentive to say, if it were true, « we have decided not to replace fennec with fenix on Android until fenix supports ad-blockers ». They very visibly didn't take the opportunity to do so. From what I can make out on github, they're planning to replace fennec with fenix around the time the next ESR comes out (which I think is early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix.
      - lol768 7y ago
        Thanks for this. >From what I can make out on github, they're planning to replace fennec with fenix around the time the next ESR comes out (which I think is early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix. Would you mind linking the GitHub issues that have lead you to draw this conclusion, so I can take a look?
        deleted 7y ago
        [deleted]
        mjw1007 7y ago
        https://blog.mozilla.org/futurereleases/2019/06/27/reinventing-firefox-for-android-a-preview/ https://blog.mozilla.org/futurereleases/2019/06/27/reinventi... says they were planning in June to have a "feature-rich, polished" fennec release "this fall". https://github.com/mozilla-mobile/fenix/issues/879 https://github.com/mozilla-mobile/fenix/issues/879 "[Meta] Fennec -> Fenix Transition" appears to say the transition will happen in Q4 2019. The Android releases of fennec used to be updated for each Firefox release, but moved to ESR with the most recent ESR release. I think that means that since then nobody has been keeping the Android port working as changes come in (but ESRs are supported for a year or more, so maybe I'm wrong to think that the date of the next ESR release is relevant). https://github.com/mozilla-mobile/fenix/issues/574 https://github.com/mozilla-mobile/fenix/issues/574 is about web-extension support; the recent updates say: « Product is looking into feasibility » « Tentatively adding needs:gv label until we know what additional GV work will be needed to support general purpose extensions. » The issue is labelled 'Feature:FennecTransition' and 'feature request'. It isn't labelled 'should', and some other 'Feature:FennecTransition' issues are. It isn't clear to me whether they're planning to release a new version of "Firefox" on Google Play that uses the fenix codebase, or release fenix as a separate app and declare that the fennec one is obsolete. https://github.com/mozilla-mobile/fenix/issues/879 https://github.com/mozilla-mobile/fenix/issues/879 and https://github.com/mozilla-mobile/fenix/issues/934 https://github.com/mozilla-mobile/fenix/issues/934 have some interesting hints, but I can't tell what they've decided.
- Allower 7y ago
  And the alternative is an even more ridiculous claim to NEVER remove this API. Committing to your users needs and priorities is understanding that THEY MIGHT CHANGE.
Ygg2 7y ago
> adblocker extensions to abandon Chrome. Ha. As if that will ever happen. They'll probably just pivot to something else. The reason Chrome can try to ditch ad blockers is that they are big enough, that your only choice is Chrome or GTFO.
- Iolaum 7y ago
  Your choice can well be firefox and chrome as a fallback when a website doesn't work and you care enough to bother opening chrome for it. Chrome has already ditched adblockers on mobile, firefox with adblockers and reader mode is a MUCH better mobile web experience.
  - jefftk 7y ago
    > Chrome has already ditched adblockers on mobile nit: chrome has never had extensions (or ad blockers) on mobile (Disclosure: I work for Google)
    - SquareWheel 7y ago
      That's not even a nitpick. The parent got it completely wrong. If Chrome mobile never supported extensions, then it's false to claim they "ditched" them.
      - michaelmrose 7y ago
        They being an ad company were smart enough not to ever allow the camel to get its nose under the tent.
      - awalton 7y ago
        From the original post, it's more like a language parsing issue - Chrome was original a desktop-only application and it had extensions. When it was ported to Android, they ditched extensions, as well as jettisoning numerous other features. Thus, not "completely wrong."
  - Ygg2 7y ago
Endy 7y ago
What they should be saying is, "No, what Google is doing is Wrong with a capital WRONG and we're not going to accept their wishes in closing off what's left of the open Web." But then they'd have to give up all their Google funding. And they're way too cowardly and corporate to do that.
- tomComb 7y ago
  > "closing off what's left of the open Web." Seems a little over the top to me! Also, Mozilla is very good at standing up to Google. They beat them on webasm, rust is arguably supplanting go, and most of all, it was Mozilla that effectively killed web components which were very dear to Google.
  - hu3 7y ago
    > rust is arguably supplanting go Two very different languages with very different goals. Neither want nor ever will suplant the other.
    - sjwright 7y ago
      Rust is challenging C++ fairly head-on. Golang is challenging Java, C#, Python, nodejs etc. It was also supposed to challenge C++ but based on how the language turned out, if that is ever true then C++ probably wasn't the right language for that project in the first place...
  - atroche 7y ago
    How did Mozilla kill web components?

zzzcpan 7y ago

I find it rather discouraging to hear they are not removing the blocking API for now. It's basically an empty statement, not reassurance. They still may or may not remove the API, they don't want to promise anything or show any commitment to users' needs and priorities.

wtallis 7y ago
It's basically the same as what happened two months ago with Firefox for Android being EOL'd pending a major re-write that may or may not support extensions. Mozilla is not willing to publicly commit to keeping their key features alive, and they keep hinting at the possibility that they will be leaving users behind in an attempt to be more like Chrome.
- Jonnax 7y ago
  A rewrite that is faster than Chrome for Android.
  - hajile 7y ago
    It may be faster than Chrome on Android, but it's certainly not faster than Firefox on Android with adblockers. Not loading/parsing multi-megabytes of Javascript and images is huge. Loads of ads these days incorporate entire JS framework toolchains resulting in a binary bigger than the page they're being injected into. Eliminating a few ads and the rest of your browser could be a lot less efficient and still perform well. That's all before discussing how adblockers also reduce who is tracking you everywhere.
    - Jonnax 7y ago
      It certainly is faster than Firefox for Android. There are benefits to adblocking of course. But there's no point lying.
    - tgsovlerkhgsel 7y ago
      In my experience and limited testing, even with warmed-up caches, Chrome (without Adblocker) was faster than Firefox (with or without Adblocker), sadly. I still use Firefox due to the security benefits of ad blocking, but I don't find the experience particularly enjoyable (although, thinking of it, it may have either significantly improved in the past ~half a year, or I just don't notice because of a more powerful CPU in my new phone).
  - bscphil 7y ago
    Eh. That may be the intent but they aren't there yet. I tested Firefox Preview on Speedometer 2.0 and got the same result I did with Firefox for Android 68. Chrome gets double the score (runs per minute) on my device.
- lol768 7y ago
  And the other point of view, directly from Mozilla: > We're certainly aware of how significant ad blocking extensions are. This release required a great quantity of features with only a six month timeline until now. > We already support a very limited set of the WebExtensions API to offer features like Reader Mode. Rest assured that more features will land in the coming months. Source: https://news.ycombinator.com/item?id=20298143 https://news.ycombinator.com/item?id=20298143 This reads like FUD to me. The dev team know how important extensions are to their users. Can you provide a source that implies Fennec will be EOL before Fenix has extension and/or ad-blocking support?
  - mjw1007 7y ago
    In that discussion (and indeed in the message you quote), the mozilla developers had every incentive to say, if it were true, « we have decided not to replace fennec with fenix on Android until fenix supports ad-blockers ». They very visibly didn't take the opportunity to do so. From what I can make out on github, they're planning to replace fennec with fenix around the time the next ESR comes out (which I think is early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix.
    - lol768 7y ago
      Thanks for this. >From what I can make out on github, they're planning to replace fennec with fenix around the time the next ESR comes out (which I think is early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix. Would you mind linking the GitHub issues that have lead you to draw this conclusion, so I can take a look?
      - deleted 7y ago
        [deleted]
      - mjw1007 7y ago
        https://blog.mozilla.org/futurereleases/2019/06/27/reinventing-firefox-for-android-a-preview/ https://blog.mozilla.org/futurereleases/2019/06/27/reinventi... says they were planning in June to have a "feature-rich, polished" fennec release "this fall". https://github.com/mozilla-mobile/fenix/issues/879 https://github.com/mozilla-mobile/fenix/issues/879 "[Meta] Fennec -> Fenix Transition" appears to say the transition will happen in Q4 2019. The Android releases of fennec used to be updated for each Firefox release, but moved to ESR with the most recent ESR release. I think that means that since then nobody has been keeping the Android port working as changes come in (but ESRs are supported for a year or more, so maybe I'm wrong to think that the date of the next ESR release is relevant). https://github.com/mozilla-mobile/fenix/issues/574 https://github.com/mozilla-mobile/fenix/issues/574 is about web-extension support; the recent updates say: « Product is looking into feasibility » « Tentatively adding needs:gv label until we know what additional GV work will be needed to support general purpose extensions. » The issue is labelled 'Feature:FennecTransition' and 'feature request'. It isn't labelled 'should', and some other 'Feature:FennecTransition' issues are. It isn't clear to me whether they're planning to release a new version of "Firefox" on Google Play that uses the fenix codebase, or release fenix as a separate app and declare that the fennec one is obsolete. https://github.com/mozilla-mobile/fenix/issues/879 https://github.com/mozilla-mobile/fenix/issues/879 and https://github.com/mozilla-mobile/fenix/issues/934 https://github.com/mozilla-mobile/fenix/issues/934 have some interesting hints, but I can't tell what they've decided.
Allower 7y ago
And the alternative is an even more ridiculous claim to NEVER remove this API. Committing to your users needs and priorities is understanding that THEY MIGHT CHANGE.

Ygg2 7y ago

> adblocker extensions to abandon Chrome. Ha. As if that will ever happen. They'll probably just pivot to something else. The reason Chrome can try to ditch ad blockers is that they are big enough, that your only choice is Chrome or GTFO.

Iolaum 7y ago
Your choice can well be firefox and chrome as a fallback when a website doesn't work and you care enough to bother opening chrome for it. Chrome has already ditched adblockers on mobile, firefox with adblockers and reader mode is a MUCH better mobile web experience.
- jefftk 7y ago
  > Chrome has already ditched adblockers on mobile nit: chrome has never had extensions (or ad blockers) on mobile (Disclosure: I work for Google)
  - SquareWheel 7y ago
    That's not even a nitpick. The parent got it completely wrong. If Chrome mobile never supported extensions, then it's false to claim they "ditched" them.
    - michaelmrose 7y ago
      They being an ad company were smart enough not to ever allow the camel to get its nose under the tent.
    - awalton 7y ago
      From the original post, it's more like a language parsing issue - Chrome was original a desktop-only application and it had extensions. When it was ported to Android, they ditched extensions, as well as jettisoning numerous other features. Thus, not "completely wrong."
- Ygg2 7y ago

Endy 7y ago

What they should be saying is, "No, what Google is doing is Wrong with a capital WRONG and we're not going to accept their wishes in closing off what's left of the open Web." But then they'd have to give up all their Google funding. And they're way too cowardly and corporate to do that.

tomComb 7y ago
> "closing off what's left of the open Web." Seems a little over the top to me! Also, Mozilla is very good at standing up to Google. They beat them on webasm, rust is arguably supplanting go, and most of all, it was Mozilla that effectively killed web components which were very dear to Google.
- hu3 7y ago
  > rust is arguably supplanting go Two very different languages with very different goals. Neither want nor ever will suplant the other.
  - sjwright 7y ago
    Rust is challenging C++ fairly head-on. Golang is challenging Java, C#, Python, nodejs etc. It was also supposed to challenge C++ but based on how the language turned out, if that is ever true then C++ probably wasn't the right language for that project in the first place...
- atroche 7y ago
  How did Mozilla kill web components?