About native.js: isn’t it making it harder to deploy Firefox profiles in a headless server? (i.e. if Zombie Navigator depended on a native.js extension, which must be installed manually, it would invalidate some of the addon’s use cases.)
How about the low-level APIs in the SDK?
https://discourse.mozilla-community.org/t/help-extension-broken-again-in-firefox-developer-edition-nightly/7731/8?u=desktopd
Of course, a Rust-based secure sandboxed type-safe browser with all the Mozilla ideas (user control, privacy, customization) will certainly kill Chromium/Chrome!
Good things for Mozilla
- Servo (Rust)
- Browser.html
- PDF.js
- Shumway
- asm.js
- Some ideas from BrowserID (Persona)
- Extended private browsing mode (anti-fingerprinting)
The problem is, what about add-ons? Moving to a new platform will likely break Add-on SDK, which means by that time all the intersting add-ons must be WebExtensions ready. (Though that will not happen very soon)
Using only high-level APIs in Add-on SDK is not perfect too. We have such an add-on: ClickGuard
https://addons.mozilla.org/en-US/firefox/addon/clickguard/
The problem here is mostly about support for anything other than desktop Firefox. Most prominently, UI related SDK modules do not work at all on Fennec. Neither do they on Seamonkey. This means one of the SDK’s main (perceived) goals is not met.
For this reason, we strongly hope that WebExtensions have (mostly) complete support for Fennec, Seamonkey, and Thunderbird. (B2G is inherently interesting too.)
Many add-on developers want to support ESR (and many derivatives based on ESR), Fennec, Seamonkey or Thunderbird. So please don’t deprecate older technologies until support for those platforms is working in WebExtensions.