最近 Firefox 不少政策带给开发者和使用者非常多麻烦,甚至不晓得 Firefox
未来能不能存活下去。爬了点文看到不少版友对此有疑惑,但相关讨论并不多,
中文的更少,所以在下稍微抛点砖,或许各位老的与新的 Firefox 支持者有所
了解后能做些什么以突破困局;再不然,早点认清现实以免被套牢也好。
不知不觉写太长了,先讲一下重点:
Firefox 打算让旧方法写成的套件未来无法使用,强迫所有套件开发者改用新
API 写套件,新 API 和 GC 扩充元件的 API 语法几乎一样,也一样功能受限
。问题来了:有 Firefox 特色的套件几乎都是有复杂功能,GC 上写不出来,才
会成为 Firefox 特产,也就是说,这些特色套件十之八九无法用新 API 写出来。
Firefox 声称会和目前特色套件开发者沟通,并适度强化新 API 的功能性,让
目前特色套件能做的在未来也能用新 API 做到,不过说是说,目前还没看到具
体案例。况且,许多特色套件的开发者并没有多余的时间和精力去钻研新 API
与新写法,这些套件可能成为绝响。目前使用者选择 Firefox 的理由几乎都是
因为有功能强大的套件,一但套件无法再支援新版,未来恐怕就没人用火狐了。
以下是落落长废话,有空就看看吧XD
Mozilla 近来有四大政策:
http://j.mp/1RiwaPh
1. 引进 WebExtension API
WebExtension API 是一种和 Chrome extension 相似度极高的 API,因此理论
上开发者只要加入一些特定的相容性程式码,就可以让一个套件能在 Chrome 和
Firefox 上运作,而不用为两者各写一套。
如果不看其他几项,这项基本上是有利无弊。
2. 引进多程序系统 (Electrolysis,简称 e10s)
所谓多程序系统是让浏览器界面和每个分页的界面切开各跑各的,这样能带来的
好处是当分页当掉或程式码跑太久时,浏览器不会因此整个当掉。但是它可能会
比较吃资源(看看多程序的 Google Chrome...)。
此外多程序系统有个很大的问题是把分页和浏览器界面分开,当它们本来是一体
时,附加元件可以直接存取浏览器界面,当它们分开了,浏览器套件就不能直接
存取页面内容,也无法修改它们,而必须使用其他方式,比如联络页面的程序并
在里面加载脚本,然后透过互相传讯交流讯息。
这样的改变就造成了很多本来在单行程系统运作的套件必须大幅改写架构才能做
到相同功能,且大体而言新架构要考虑比较多东西,会比旧架构复杂、难写很多
。
除了程式码架构变复杂以外,Firefox 的开发者工具在换到多程序系统以后也不
正常,本来可以直接 console.log 输出除错讯息的,换到多程序系统可能会看
到除错讯息变成 undefined 或 unavailable,因为它们是来自另一个程序,内
容无法直接存取。
Firefox 自 42.0 版开始支援 e10s,使用者可以自由切换,不过即将改为默认
使用多程序,未来甚至可能再也不能切换为单程序。不能在多程序系统上运作的
旧套件,如果开发者不去做功课再及花时间改写套件,将再也不能使用。
这就是开发者会不爽的理由之一:为什么要花一大堆时间去研究新写法、大幅改
写旧套件?而且这样改写几乎没什么好处,只是为了相容新版而已。还有,为何
一定要改成多程序?难道继续让使用者可以选择单程序与多程序不行吗?
此外,改为多程序会比较顺畅吗?我目前的观察是没有,目前的多程序
Firefox 还是常有莫名的卡顿,有时还会整个视窗冻结(虽然是没有当掉,但
还是不能操作啊XD)希望这只是短暂的 bug 囉 XD
3. 套件强制签署
自 Firefox 42.0 开始,没有在 AMO 上架、通过审核、取得签署的套件,将无
法安装。目前使用者还可以在 about:config 修改设定值覆蓋此设定,但预计在
Firefox 46.0 以后将无法覆蓋设定,换言之,没取得签署的套件将再也无法安
装。
这就是开发者和使用者都会不爽的理由:对使用者而言,为什么要禁止未签署的
套件?秀个警示讯息让我知道套件未签署且可能有安全风险难道不行?对开发者
而言,开发和测试套件要签署也太麻烦了吧?
开发者可以做的是改用其他发行版的 Firefox ,目前只有正式发行版以及
beta 版会强制签署且无法覆蓋设定,其他像 Firefox Aurora、Firefox
nightly、以及开发者版本则可以设定成不强制签署,所以想要装一些 AMO 不放
行高端功能的玩家可以这样做,不过这些发行版更新比较快、也可能较不稳定。
4. 弃用 XUL 及 XPCOM
XUL 和 XPCOM 是深植于 Firefox 及核心渲染引擎 Gecko 的组件。XUL 是定义
使用者界面的一种 XML 语言,其中有个称为 XUL overlay 的特性是让开发者可
以用一个 XUL 的界面覆蓋另一个 XUL,这技术让开发者可以直接改写 Firefox
的核心界面,比如浏览器界面 chrome://browser/content/browser.xul。
XPCOM 则是一整套集网络连线、档案系统存取等功能于一身的组件。
XUL 和 XPCOM 是 Firefox 之所以功能强大、能做多许多 CG 不能做的事的理由
,但 Mozilla 宣布他们即将在一至两年内弃用,理由是 XUL 和 XPCOM 能够整
个改写核心,造成安全风险,此外也让不同套件之间的冲突很难侦测,也让审核
者很难审核。
照说注重安全是好事,换掉这套架构也会让未来开发与相容性处理更轻松,但最
大的难题是──开发者和使用者之所以会选择 Firefox ,就是因为它有功能强
大的套件,能做到 chrome、opera、safari 等浏览器根本做不到的事,如果拿
掉 XUL/XPCOM,Firefox 岂不和其他浏览一样功能不足?这样的 Firefox 还值
得使用吗?
目前 Firefox 有三种套件系统:
1. XUL overlay 套件:就是之前说的,用套件的 XUL 覆蓋原来的 XUL 界面,
并插入额外的样式或脚本。弃用 XUL/XPCOM 以后当然是整个 GG
2. bootstrap 套件:自 Firefox 4.0 引进。使用 bootstrap.js 脚本控制套件
安装、加载、卸载、移除时执行些什么,因此安装、更新、卸载时可以不用重新
启动 Firefox。bootstrap 不能使用 XUL overlay,但基本上还是透过修改
XUL 元素来改变界面,弃用 XUL/XPCOM 以后也是 GG
3. Addon SDK 套件:这是一种用 node.js 写成的模组,开发者写好程式码以后
,可以用 Addon SDK 执行测试环境,也可以把程式码打包成 .xpi 安装档。
由于 Addon SDK 会处理很多低阶的打包任务,让开发者能够用比较简洁的程式
码开发想要的功能,而不必像 bootstrap 套件一样亲自去控制许多安装、卸载
要执行什么东西,或者像 XUL overlay 去亲自控制系统核心。
但 Addon SDK 也有很多问题:
1. 只能在 Firefox 38.0 以后执行
2. 由于 SDK 只针对 Firefox 设计,Addon SDK 套件不能在其他基于 Gecko 的
浏览器上运作,比如 SeaMonkey 和 Pale Moon。这对想开发跨平台套件的人是
个困扰。
3. Addon SDK 功能相当有限,官方声称会支援高阶 API,开发者只要继续使用
高阶 API,就可以在未来及现在的 Firefox 上运作,但其实有非常多功能是高
阶 API 根本不提供的,必须使用低阶 API,而官方没有保证低阶 API 未来不会
变动或无法使用。
其他还有我遇过的问题是多语系翻译总是不正常,我明明有提供 zh-TW 语言包
,执行时却总还是英文 orz
4. 无论是高阶或低阶 API,其实打包后都是 bootstrap 套件,其调用的模组最
后还是会调用 XPCOM 组件,如果 Firefox 要弃用 XPCOM 组件,未来Addon
SDK 怎么可能还能用?
这点 Firefox 开发者也没给明确说明,我之前询问时有人员回答:政策上的弃
用不等于技术上的弃用。言下之意似乎是说所谓弃用 XUL/XPCOM 并非技术上而
是政策上,也就是它们未来还是可以跑,只是 AMO 会把审核这种套件的优先度
压低、甚至拒审。而这些拒审应该也是有条件的,比如既有套件的升级或修
bug 应该不太会拒审。
如果是这样,就能解释前面的问题,也会是超大的好消息──这表示目前的
XUL/XPCOM 套件开发者可以继续原来的做法,AMO 愿意审就审,不愿意审那就
改用允许不强制签署的发行版XD
是否有那么乐观,可能也无法确定,因为有另一种可能是 Firefox 真的打算把
底层的 XUL/XPCOM 全部抽掉,Addon SDK 只是保留 API,但中间的打包阶段全
面修改,让它能在新的 Firefox 上编译成不基于 XUL/XPCOM 的程式码,但这样
针对新版 Firefox 包出来的套件可能会不能在旧版 Firefox 上运作,这会违背
当初说 Addon SDK “跨版本相容”的保证 。
这可能性高不高我无法确定,不高的理由是现在 Firefox 核心架构整个都是
XUL/XPCOM,整个抽掉谈何容易;高的理由是 Mozilla 已开始开发新的浏览器
引擎 Servo,有可能会想用它取代 Gecko(但也可能只是给行动平台使用,而现
在的 Firefox for Android 本来就不使用 XUL 而是使用 Android 原生界面指
令)
还有另一点是连 Addon SDK 也不一定有未来,毕竟在 WebExtension 发展起来
后,我真的想不出有什么理由去写 Addon SDK。况且 Mozilla 有前科:Addon
SDK 前身是 python 开发的 cfx,它现在已经被弃用了。
身为开发者,如果是技术上弃用 XUL/XPCOM,我会非常不能谅解──增加
WebExtension 支援是很好,但为什么要把自己的特色砍掉?把以前一向运作良
好的套件杀死?
第四种则是上述的 WebExtension,它的主要问题是:
- 只支援 Firefox 45.0 以后版本,老一点的都不行
- 目前功能非常有限,GC 写不出来的东西几乎都写不出来
- 有不少 BUG
总之现在 Firefox 套件开发者可说怎么做都不讨好:
1. 使用 XUL、bootstrap 可确保现在能跑;如果需要比较强的功能,更是目前
唯一能做的。但人家都放话说一两年内要弃用,你敢继续写吗?
2. 改用 Addon SDK,但这架构功能非常有限,许多关键功能仍须调用不稳定的
低阶 API,甚至直接调用 XUL 与 XPCOM,而这么做一样无法免于弃用威胁。还
有,在 WebExtension 起来后这东西有未来吗?
3. 改用 WebExtension,但目前这系统和 Chrome 一样功能有限,写不出什么高
端东西,而且因为还在起步阶段,可能会有很多 bug(在下试做时就遇到了一两
个)。
老实说,可以用 WebExtension 写的东西,大概早就能在 GC 上写出来了,而目
前所有 Firefox 有特色的套件,几乎都是 GC 无法写出来的。
据某些开发者所言(如 NoScript 开发者),Firefox 确实有在向热门套件的开
发者征求意见,且据说会据此扩充 WebExtension 的 API 使它能做到许多
Firefox 以往能做到的强大功能。如果这是真的,或许未来 Firefox 在加强版
WebExtension 的加持之下还会有一定地位也说不定。
所以,开发者现在能做什么呢?
1. 持续向 Firefox 团队反映意见,让它们把 WebExtension 功能扩展到够强,
否则 Firefox 未来可能会是只和 GC 差不多弱的死狐狸。
2. 只要可以,干脆先跳槽去写 GC 扩充元件,等 WebExtension 成熟点再移植
过来XDD 或者现在就移植,不能移植就报 bug。
3. 透过各种手段说服开发团队不要真的技术上弃用 XUL/XPCOM,政策上弃用就
暂且吞下去吧...
4. 透过各种手段说服开发团队不要在未来废除单程序 Firefox
5. 早点洗洗睡了,蹚这滩浑水那么久也是醉了吧?
6. 其他?有等高人指教........XDD
时间问题而已就我使用习惯,chrome已经完全取代Firefox要不是OS是FreeBSD,Firefox根本没优势啦
作者:
randy123 (好色怪叔叔)
2016-03-23 00:39:00目前自己使用是没遇过没有非fx专有的套件,仔细找找还是有可取代的相对GC我还是喜欢FX,但fx开大量网页会卡顿(内存使用超过1G),GC开启网页反应快多了,session buddy套件又好用就回不去了呢
想到DTA 作者就是被火狐政策搞到恼羞就直接放弃开发
反正到时走不下去的话 就再走回头路就好了但不管怎么发展 fx的市占只会越来越小尤其未来的战场是在行动装置 android被google把持下其他浏览器机会没几乎 除非google跟M$一样犯傻几乎没机会
作者: hiroki03 (希洛祈) 2016-03-23 02:02:00
我觉得Android上的Fx,优势的确是可以自订插件,能办到其他浏览器做不到的使用体验但我也觉得有安装插件的Andorid版Fx,耗电程度比其他原生浏览器来的高 , 我本来手机也都使用Fx为浏览器,但明显电力能浏览的时间变短了,最后在手机上还是换回了GC,毕竟手机还是以持久浏览为考量当然PC上还是使用FX为主,GC为辅
作者:
mindsteam (24fps狸猫任务)
2016-03-23 02:20:00用Fx的人不见得是因为套件很多。我主力使用的Fx只装了"No Script"这么一个套件而已。
作者: zhtw (人生就是不停的后悔。。) 2016-03-23 02:56:00
选项五,洗洗睡吧XD把自己的优点都砍掉,chrome没有的fx不能有,这才是mozilla的政策吧! 不离不弃被当北七。
作者:
Kreen (æ¯å¤©è¦æ›´å„ªç§€ä¸€é»ž)
2016-03-23 06:20:00推好文。其实我蛮想知道当套件只能做到跟 chrome 一样,换新架构也开始吃资源的“新 Fx”卖点到底是啥没有办法特色化、也失去 Google 整合的助力,除了极少数人根本感觉不出明显差异的核心,那根本沦为“鲁蛇版的 GC”了啊。那处境跟各种 Chromium 二创也差不多呀。
作者:
Syu (海へ)
2016-03-23 08:05:00不当开发者很久了 使用者侧的我找不到任停一个理由让我用fx
作者:
t7yang (t7: 我认为这是一种背叛)
2016-03-23 09:05:00先把用语修正吧,不然真的看到一半就不想看了。这些年台湾人真的被中国和香港荼毒的很严重,根本忘记了台湾叫“接口”(别说什么正义魔人,连自己的文化都不重视,就没人会重视)。multiprocess应该是多处理程序
手机的话 我还是觉得fx没希望 我以前在手机用fx偶尔会遇到用fx开启会有问题的网页 尤其是一些需要登入的网站 然后我就必须再用chrome去开当然大部分状况 就算用chrome开也是会有问题但这还是会造成我的困扰 就是我手机要装两套浏览器手机的内存是很小的 而浏览器通常都满吃内存的所以既然最终都会用chrome开 那我还是用chrome算了
作者:
Kagero (摩荔枝天(茄汁))
2016-03-23 11:17:00Firefox就算倒掉 我想不少人也觉得没差对老手来说不是套件死光 就是变成只会Copy Chrome的Copyfox新手光是看到Google这个招牌 和Chrome方便程度就不会选择Firefox这堕落的东西
作者:
dx90c (DirectX)
2016-03-23 11:47:00台湾没人做科普文,还要怪都是大陆用语本末倒置了吧
作者:
wuliou (wuliou)
2016-03-23 11:49:00Google Chrome用起来太不爽了 应该还是会继续死撑到Fx真的没人用吧…
电脑版Chrome的外观设计比较当代,且动画较顺畅,内建的pdf浏览器比火狐好用,整体上火狐速度虽不慢,但在与人机交互接口的流畅程度有差。
作者:
cattgirl (小喵超爱合购)
2016-03-23 13:04:00套件强制签署 强制关闭我至少一半套件
电脑上我还是死守火狐 手机还是算了 一直觉得卡卡的
作者:
olduck (123)
2016-03-23 14:31:00介绍别人chrome 自已用firefox,比较顺手
作者:
darKyle (飘向星空)
2016-03-23 16:30:0045 ESR 能撑多久是多久吧
作者:
xvid (DivX)
2016-03-23 20:24:00Android 可以试试 Naked Browser, Firefox 装了ublock和ghostery以后网页加载要好几秒
作者:
aza0290 (阿兹)
2016-03-23 22:17:00我想Mozilla可以不必改变 就像Linux一样市占率少也没差或许是Mozilla有什么压力被迫做出改变?
作者:
darKyle (飘向星空)
2016-03-24 12:06:00PC市场对Linux本来就不重要 但Firefox可没什么server市场