※ 引述《ettoolong (ettoolong)》之铭言： 有神，先膜拜 m(_ _)m : : 1. 引进 WebExtension API : WebExtension API 很不错, 提供这个的话可以让 Chrome 的套件很容易地移殖到 : Firefox 上, 但是如果因为提供 WebExtension API 就把既有的套件系统砍到一个 : 不剩, 反而是本末倒置. 同意 : : 2. 引进多程序系统 (Electrolysis，简称 e10s) : 这个改变只会影响到一部份套件, 不是全部. 套件写法有可能变得比原本复杂, 这 : 是真的, 因为有一好没两好. 这个不是强制的功能, 使用者仍然可以选择关掉e10s. 我有点怀疑...按 Mozilla 最近的作风， 天晓得会不会在几个版本後强制多程序，单程序成为绝响？ 希望不会发生 : : 3. 套件强制签署 : 也就是说, 对原有的开发者来说, 如果你的套件不放上 AMO, 就是多了一个自行 : 签章的动作而已, 这应该不是什麽大问题. 我之前的确不清楚有这样的机制，感谢提供情报。 但这还是有问题，因为所有的套件仍然需要被 AMO 审核才能安装。 就开发者的角度而言，自行签章看起来很简单，但签章一定会过吗？ 不一定，你得符合 AMO 制定的规范， 如果程式码有违反规范的 pattern，会被挡死无法签章； 如果程式码有疑似违反规范的 pattern，会被强制人工审核，那就可能拖很久。 可能有人说，不要违反规范不就好了吗？ 问题是什麽是违反规范？那是 AMO 说了算， 而且自动验证程式是很笨的，没有多特别的程式码也可能被找麻烦， 比如我以前有段程式码： setTimeout(someFunction, 0); 这段程式码就被自动验证程式挑毛病，AMO 还寄信来要我改， 理由是 setTimeout 第一个参数必须放 function（而不能放 string）， 是人都看得出来，我的 someFunction 显然是指向一个固定的 function， 但自动验证程式可没那麽聪明， 而那位寄信过来的审核者其实可以自己检查，但他没有，先要求我改再说。 对，我是可以把它改成： setTimeout(function () { someFunction() }, 0); 但我就是不爽本来可以直接调用的函数被要求改成间接且低效能的写法！ 这段程式码跑一次还好，如果是放回圈里跑几千次呢？ 还有，setTimeout 第一个参数放上来源不明的 string 是有安全疑虑， 但假使那个 string 显然安全，AMO 会放行吗？ 其他还有像： document.createElement(aNodeNameString); // 只能用静态字串 aNode.innerHTML = "Some <em>emphasize text</em>."; // 请改用 DOM API aNode.innerHTML = ""; // 请改用 DOM API 这些都会被自动验证程式挡下来，然後被 AMO 找上门， 我後来和他们说明过，他们是没再强迫我改，但中间还是被拖了很久。 虽然那不是发生在自动签署，但未来你要自动签署时， 难保不会因此被搞成旷日费时的人工审核... 就使用者的角度而言， 他们会因此失去了像这样的选择： 稳定版本的 Firefox + 99% AMO 签署过的套件 + 1% 自行开发供特殊用途的"不安全"套件 我知道我可以使用 Nightly 等版本， 但我为什麽要为了安装极少数我需要的功能而被迫使用非稳定的 Firefox 版本？ 说到底，一个套件能不能安装必须由 AMO 决定，是件很奇怪的事， 也违反开源、自由的精神， 虽然这还不算我完全不能接受的事， 但我认为套件未签署时只警示而不强制拒绝安装会比较合理。 : : 4. 弃用 XUL 及 XPCOM : XUL overlay 作得到, addon sdk 作不到的功能: : 我有几个 XUL overlay 套件, 功能最复杂的那一个, 用了很多 XUL overlay 的东 : 西, 但是这阵子试着移到 addon sdk 上, 还没遇到真的无法搬过去的功能. 你想得 : 到的介面修改, 应该都还是能用 addon sdk 改出来, 只是这可能会用到低阶 API, : 之後需要持续关注相容性问题, 但这些问题, 用 XUL overlay 也一样会遇到. : 当然, 还是有可能会有无法移殖的情况, 例如 Firefox UI 层面的大魔改, 只是我 : 目前还没有遇到, 也许再多移殖几个套件後我就会遇到. XUL overlay 的确不是非有不可， 从以前的 bootstrap 开始，就可以直接用修改元素的方式改变 XUL 了， 而 addon SDK 如果可以使用 require("chrome") 之类的方式， 那就绝对有像 bootstrap 套件一样做到所有 XUL overlay 能做的。 吹毛求疵地说，唯一不能做到的大概是「套件更动时必须重新启动」， UI 大魔改本身不困难，也不是非 XUL overlay 不可， 麻烦的是套件卸载时怎麽改回来， 照说重启 Firefox 是最简单的做法， 但 bootstrap 或 SDK 这种免重启的套件会要求开发者把卸载功能写出来， 有时这会很折腾，麻烦到让人宁可放弃免重启， BUT...你没有这种选择哦XDD : 用 addon sdk 开发遇到语系问题: : 我好像也遇过, 跟语系档的编码有关, 还有一次是 profile 被我搞坏掉造成多语 : 系不正常, 你可以参考看看. 我记得之前确认过语系档编码是 UTF-8 no DOM，但还是不行； 但现在再试一次又正常了，或许是我之前搞错了什麽@@ 总之现在没事了XD : 没了 XPCOM, addon sdk 还能用吗: : 基本上 addon sdk 就是一层介面封装, 所以只要你用 addon sdk 的高阶 API, : 基本上不用太担心 XPCOM 问题, 因为介面不动, 只动底层实作是可行的. 也就是说 : 如果你只用到高阶 API, 就是只用到最上层的介面, 底层的 XPCOM 实作就变成可以 : 被抽换掉实作而不影响你的套件. : 至於低阶 API, 里面当然就有可能用到 XPCOM 或是更多核心元件, XPCOM 被换掉後 : 确实就有可能不能用, 所以开发者就要多多关心一下相关的核心变动. : 但我想这问题就跟你用 addon sdk 开发没啥关系. : 回想一下, 传统使用 XUL overlay/XPCOM 的套件一样会有这些随核心变动而 : 要处理的相容性问题, 不是吗? 我觉得这问题的重点在於，如果拿掉 XPCOM，会不会用不同形式提供相同的功能， 还是拿掉了就是开发者再也没那功能可用。 : Addon sdk 只有 Firefox 能用: : 这可能是个问题, 不过如果是其他社群版的 Firefox, 只要 Gecko 核心版号有跟上 : 官方 Firefox, 应该就没问题, 之前有 Pale Moon 使用者来跟我反映套件相容性 : 问题, 我才发现 Pale Moon 的核心停在很旧的一版 Gecko, 不知道现在是不是还是 : 这样. 如果是的话, 就有可能不能支援. 大大您可能忘了不只是 Firefox only，而是 Firefox >= 38.0 only 以往无论核心 API 怎麽改，甚至是从 XUL overlay 改 bootstrap， 开发者都总是可以写些判断条件让整个套件向下相容。 但只要用 Addon SDK 写，打包出来就是无法支援 Firefox < 38.0， 那我以前写的能支援 Firefox 2.0~45.0 的套件要怎麽办？ 不改 Addon SDK，就是随着 XUL/XPCOM 弃用而有天不能支援 Firefox > x， 改成 Addon SDK，就是跟 Firefox < 38.0 的使用者说再见。 这麽粗暴的拒绝相容，真的是第一次看到，这是我最不爽的地方。 我现在还是很苦恼，要不要转移到 Addon SDK 然後放弃旧版 Firefox 的使用者。 : cfx 被弃用: : 其实 cfx 就只是一个工具, 帮你处理初始化套件, 打包套件这些琐碎的工作, : 你可以想成本来你用记事本写 code, 现在改用 sublime. 我觉得这没有什麽问题. 用记事本和 zip 就能写套件和只能用 node.js + jpm 写套件，自由度是不太一样的， 如果有一天 node.js + jpm 被砍掉，换成另一个我可能懒得学的平台， 我不知道届时我还能不能接受。 这不算很严重的问题，只是吹毛求疵一下而已。 : 套件不给力的 Firefox 和 Chrome/Chromium二创 还有啥不同: : 本质上的不同, Firefox 带给了使用者选择的机会, : 一个不被 Chrome (来自 Google — 全球最大的广告公司) 控制的机会, : 使用者有了选择, 选择 Chrome 或是 Firefox 取决於你自己, : 而不是像回到 IE 垄断的年代, 使用者没有选择. 同意，另外我想补充一点， 现在还在用 Firefox 的使用者， 我想大多是因为只有 Firefox 提供了某些 GC 不提供的功能， 换言之，只要未来 Firefox 套件系统仍能提供 Chrome/Chromium 不提供的功能， 就还是会有一定的市场， 如果 GC 是 30 分的自由度， 新 Firefox 和旧 Firefox 的差别可能是： 80 分自由度/功能性 + 可用 GC 套件 + 开发容易 与 100 分自由度/功能性 + 不能用 GC 套件 + 开发很麻烦 那个比较好，说实话满难下结论的，我觉得还要观望。 : Android 上的 Chrome 为什麽没有套件, 因为类 adb 的套件就是这个最大的广告 : 公司最不想看到的. 精辟XDD : 向 Firefox 团队反映意见: : 开发者的反馈我想还是非常重要的, 如果真的遇到开发上的限制, 可以提出讨论, : 我想不至於搞到最後变成因为限制而无法写出重要的功能啦, 至少目前还不是这样. Mozilla 在 WebExtension 还很草创时就放话要砍 XUL/XPCOM， 确实会让很多开发者紧张起来。 希望未来 WebExtension 确实可以改善到保有和现在 XPCOM 差不多强大的功能， 也希望现在放弃的开发者届时还愿意回来继续开发。 : 想持续关注 Mozilla 的相关议题, 可以来 MozTW 的聊天群组, 当然也会有套件 : 开发的讨论. 可以交流一些使用和开发上遇到的问题. 是指 irc channel 吗？我每次都找不到人XDD --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.243.229.128 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Browsers/M.1458737030.A.4D3.html ※ 编辑: danny0838 (111.243.229.128), 03/23/2016 20:45:29 ※ 编辑: danny0838 (111.243.229.128), 03/23/2016 20:45:55 ※ 编辑: danny0838 (111.243.229.128), 03/23/2016 20:53:36 ※ 编辑: danny0838 (111.243.229.128), 03/23/2016 20:58:02 ※ 编辑: danny0838 (111.243.229.128), 03/23/2016 21:00:29 我猜您想回覆的是 Addon SDK 不支援 Firefox < 38.0 的部分... 没错，bootstrap 可以支援 addon SDK， 事实上 addon SDK 打包後就是个 bootstrap 套件， 但是 bootstrap.js 本身就是由 addon SDK 打包程式产生的， 而产生 bootstrap.js 前几行会调用原生 Firefox 的某些 module， 由於那些 module 是旧版 Firefox 没有的， 因此旧版的 Firefox 跑 addon SDK 打包出来的套件会在一开始载入时就出错。 如果要向下相容，要嘛就是用纯手工的方式写出类似 addon SDK 的程式码， 本来能自动产生的东西全部改为手工写； 要嘛就是打包完以後再手工修改加入向下相容的程式码， （好啦其实也可以写个 script 做这件事） 但会变得麻烦许多。 ※ 编辑: danny0838 (111.243.229.128), 03/23/2016 21:28:21 ※ 编辑: danny0838 (111.243.229.128), 03/23/2016 21:29:21 那些套件当初就是在 Fx 3.0 开发的， 一路走来该处理的麻烦早就处理过了， 唯一有问题的是现在要强迫改用 Addon SDK... ※ 编辑: danny0838 (111.243.229.128), 03/23/2016 22:30:53 ※ 编辑: danny0838 (111.243.229.128), 03/23/2016 22:31:19