First, Electrolysis. As mentioned, we won't support it in TenFourFox; we would need to implement a userland spawn implementation for 10.4 from scratch for starters, and I suspect that the overhead required will end up performing substantially worse on old Macs plus the inevitable OS bugs it will undoubtedly uncover. Currently Mozilla is predicting Electrolysis will reach the release channel by Fx43, which I find incredibly optimistic given predictions for Australis which slipped deadline after deadline, but it's clear Electrolysis' public unveiling in the relative near future is inevitable. Once it becomes no longer possible to launch the browser in single-process mode, likely one or two versions after, that's the end of source parity. My suspicion is that it will actually reach release by Fx45, which is the next ESR anyway, and there should be an emergency fallback to single-process that we can exploit to keep us running at ESR parity for the last time.
To facilitate addons in the new e10s world, Mozilla is effectively announcing that XPCOM/XUL-based addons are now deprecated because of their highly synchronous nature. (Technically, they'll be deprecated six months after Electrolysis goes golden master, and completely unsupported and/or incompatible within six months after that, but as far as I'm concerned announcing a future deprecation is the same as deprecating it now.) This sucks because the use of XPCOM and XUL in the Mozilla Suite and later Firefox and SeaMonkey meant easy cross-platform add-ons that could do powerful things like implementing a completely new protocol within the browser. Although jetpack addons will still work, sort of, any jetpack addon that requires chrome features is subject to this policy also. Mozilla will be enforcing this brave new XUL-free world by refusing to sign addons that rely on XPCOM or XUL in this later timeframe, which dovetails nicely with not allowing unsigned addons starting with Firefox 42. (Parenthetically I don't agree with the mandatory signing policy, and if there is a TenFourFox 45 it will disable this feature. I don't port Gecko code for the walled garden, guys, thanks.)
Calling this a footgun and the future death of Firefox is not merely hyperbole. I suspect, and I suspect Mozilla is ignoring the fact, that many Firefox users use it because of the presence of such powerful addons that just can't be replicated in other browsers. Chrome, for example, doesn't have near the functionality because it doesn't expose it, and its addons are much less useful in general. But Mozilla is not content to merely shoot themselves in the foot here; they've emptied the whole magazine into their leg by making the new add-on world based on the almost completely different WebExtensions API. WebExtensions is Blink-compatible, the engine powering Chrome. That means an author can easily create a much less functional addon that runs not only on Firefox but also on Chrome. Yup, you read that right: soon the only functional difference between Firefox and Chrome at this rate will be the name and the source tree. More to the point, many great classic addons won't work in the new API, and some addons will probably never be made to work with WebExtensions.
Riddle me this, Batman Mozilla leadership: if the addons are the same, the features are the same, the supported standards are the same, the interface is converging and Mozilla's marketshare is shrinking ... why bother using Firefox? I mean, I guess I could start porting SeaMonkey, although this announcement probably kicks the last leg out from under that too, but does Firefox itself, MoCo/MoFo's premier browser brand, serve any useful purpose now? Don't say "because it makes the web free" -- people can just go download and compile WebKit, which is open source, well understood and widely available, and they can even usefully embed it, another opportunity Mozilla leadership shortsightedly threw away. They can fork it like Google did. They can throw a shell around it. Where's the Gecko value now?
Maybe this is a sign that the great Mozilla experiment has finally outlived its usefulness. And frankly there won't be much value in a Gecko-based browser or even a Servo-based one that works exactly the same way as everything else; notice the absolute lack of impact Firefox OS is having on mobile, although I use and prefer Firefox Android personally just because I don't trust Chrome. Maybe that trust will be the only reason to keep using Firefox on any platform, because I certainly can't think of anything else.
Meanwhile, this weekend I'm rewriting TenFourFox wiki documentation on Github ahead of the impending read-only status of Google Code. Since this is true Markdown, I'm using Nathan Hill's SimpleMarkPPC since it works pretty well for simple documents of this type and runs on 10.4. I won't be copying over all the old release notes, but starting with 38.3 all future ones will be on Google Code as well. After that we'll work on the MP3 support to finalize it, and I've got a secret project to share hopefully next week.
I was thinking about waiting until Servo actually replaces Gecko to ditch XUL/XPCOM add-ons, given that Servo will never support it anyway.
ReplyDeleteYou're making the assumption that WebExtensions must and will be limited to the APIs Chrome provides. But this isn't true.
ReplyDeleteThat presupposes that the Firefox-specific APIs will remain specific to Firefox. Chrome cannot match the flexibility of XPCOM/XUL, but they can add the APIs that addon authors demand under this model. It will be, effectively, a new "embrace and extend."
ReplyDeleteXPCOM is the real footgun here, actually.
ReplyDeleteAs an addon developer I've pined for the day where I had stable, documented, public APIs to work with instead of the fragile crap XPCOM usually provides. I've wanted to make it easier to keep my addons working across platforms and themes, have my AMO addons reviewed more quickly, and dreamed to see a standard emerge for making addons more portable across browsers.
As a user I've pined for the day where I can know that addons are restricted in what they can do, and have the more advanced ones break less often between versions. I've been frustrated to no end with how poorly these addons work in Electrolysis, and frankly while TenFourFox is awesome and the work you've done is amazing, I don't want Firefox to be held back anymore by obvious shortcomings that people illogically defend.
We have this silly rose-colored view of XPCOM style addons, always ignoring all of the obvious, terrible problems with them just because they're powerful. Now Mozilla wants to improve the status quo, and all I'm seeing is people making snap judgments, clearly without even reading the statements and insights Mozilla has offered. It's really disappointing.
No, I think you're (mostly) off base. XPCOM *has* stable interfaces. Half of them are frozen, have been for years. Read any number of the IDLs and see for yourself. Besides, you don't even have to muck around with that if you don't want to -- the Jetpack idea added on a friendlier layer. If you don't like the Jetpack API, that's not XPCOM's fault.
DeleteAnd as an addon developer, aren't you concerned about what this actually means for what you're allowed to do? WebExtensions restricts addons to the view of what our betters believe an addon should do. If there is no explicit API, there is no support or even ability, whereas XPCOM let me create a component to do almost anything.
In the end, you might conclude (and Mozilla clearly has) that tossing all that is worth it to make Electrolysis work, assuming it does. That's fine, but I don't share that optimism or that belief.
Actually we dropped the notion of frozen XPCOM interfaces some time ago, around Firefox 4.0 IIRC. Any interfaces that claim to be frozen probably shouldn't.
DeleteAlso this isn't just about electrolysis, we've been talking about removing XPCOM and XUL access from add-ons for some time because it has been a continual source of pain holding back development in many ways.
Fair enough, although I doubt very much there'd be much notable change to any foundation classes such as, say, nsISupports, or the networking components.
DeleteFWIW the thing that is being deprecated six months after electrolysis ships is CPOWs and the compatibility shims that keep many existing add-ons working albeit by imposing a serious performance penalty. The timeline of deprecating XUL and XPCOM access for add-ons isn't tied specifically to the electrolysis release (though the fact that that will likely end support for a lot of add-ons is a contributing factor).
ReplyDeleteI think this is an overly fine point, however. By announcing a more or less firm timeframe for when they will be deprecated, you're essentially saying any future work on them will be for naught, thus deprecating them now. In fact, I'd even argue that effect is desirable for this goal.
Delete