-Поиск по дневнику

Поиск сообщений в rss_planet_mozilla

 -Подписка по e-mail

 

 -Постоянные читатели

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 19.06.2007
Записей:
Комментариев:
Написано: 7


Cameron Kaiser: Mozilla's future footgun add-on policy (or, how MoFo leadership is getting it totally wrong)

Суббота, 22 Августа 2015 г. 07:02 + в цитатник
So long, Firefox. It was nice to know you.

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.

http://tenfourfox.blogspot.com/2015/08/mozillas-future-footgun-add-on-policy.html


 

Добавить комментарий:
Текст комментария: смайлики

Проверка орфографии: (найти ошибки)

Прикрепить картинку:

 Переводить URL в ссылку
 Подписаться на комментарии
 Подписать картинку