GoogleChromeの拡張を作る上でFirefoxアドオン作者が知っておくべきやればできること

GoogleChromeの拡張を作る上でFirefoxアドオン作者が知っておくべき10の違い【GoogleChromeでニコ動拡張を作ってみた感想】 – love_firefoxportableの日記についてMySpaceのMP3ファイルにID3tagを埋め込みつつダウンロードするJSActionsスクリプトを作ったあたりからFirefoxアドオンの柔軟さに魅了されていろいろ作ってきたけどChromeのUIのブロックしなさが快適でChromeにスイッチしようとしている人間が書きます。

将来にわたってChromeのextensionでFirefox addonのような自由度が実現されるようなことはないと思いますが、それでも今の段階でやればできることもちょっとあります。大半はできないけど。

右クリックはいじれない

いじれません。このへんまだ実装自体がやっつけな感じなので将来的にはいじれるようになるんじゃないかと思ってます。
API Wish List (The Chromium Projects)にも載っています。

データのダウンロード保存はできない

chromeのダウンローダでダウンロードすることはできませんが、どうしてもダウンロードしたければNPAPI pluginを作ればできます。

クリップボードの操作はできない

NPAPI pluginを作ればできます。(ex. chromeでMake LinkみたいにページのHTMLリンクをコピるCreateLink « ku)
通常NPAPI pluginを使うと通常のウェブページからもpluginの昨日にアクセスできてしまいますが、chromeのNPAPI pluginはextensionのオリジンからだけ有効にすることができるオプションがあります。これによってobjectタグを通じて通常のウェブページからは利用できないけれどextensionからは使える関数を用意することができます。

ただ現状プラットフォームごとにべつべつのバイナリを用意することができなくて、ぜんぶおんなじバイナリを読み込むのでターゲットのプラットホーム以外で読み込むとクラッシュしたりします(公式リリースではextensionはwindowsでしか動かないことになっているので問題ないといえば問題ないんでしょうけど…)。これは中の人もちょう怒ってました。Extensions and the Mac – Chromium-dev | Google Groups

ブラウザの通信に対してフックをかけることはできない

できません。
が、Extensions API proposal: access to the HTTP request – Chromium-extensions | Google Groupsで作りたいっていってdesign docを書いてる人がいたのでできるようになるかもしれません。書かれたのは3ヶ月前でその後音沙汰ないですが…

DOM構築前のデータを弄ることはできない

できません。これってFirefoxだとどうやったら実現できるのか知りたいです！

ブラウザの下部に新しくツリーボックスを作る等、ブラウザの構造を変えることはできない

できません。ここはFirefoxの奇跡だと思っています。

昔Netscape社でNavigator6を作り、今はChromeの開発をしているBen Goodgerさんのmillennium | Google Chrome Extensionsを読むと、もともとFirefoxのextensionでブラウザ自体のUIをいじれるようになっているのは意図して設計されたわけではなかったと書かれています。Navigatorの内部で使うためのAPIをハックしてUIをカスタマイズできることが発見されて、それが人気があったので長い年月を経て生き残り、現在のようなextensionにまで成熟したと書かれています。

If this “back door” into browser customization hadn’t existed by virtue of Netscape’s componentized install, it’s not necessarily a given that Firefox would _ever_ have had extensions. Think about that. It’s awesome that it did, because it’s a feature users love.

Firefox extensionの自由さは偶然から生まれて今に至るのです。

外部exeを実行することはできない

NPAPI pluginでできます。

XMLHttpRequestはクロスドメイン制限を受ける（content_scriptsの場合）

これはいちおうbackground pageからきるけどreferrerがつけられないことが大きな制約として残るだろうとConstellationさんが言っていました。が、NPAPI pluginでやればなんでもできます。

content_scripts内のjsからlocalStorageにアクセス出来ない

バグな気もします。Greasemonkeyとは名前空間の分離の仕方が違うことに起因してます。Chromeでどうやって分離しているかはAaronのブログに図解があります。 aaronboodman.com – Aaron Boodman’s work blog

javascript1.6とか1.7とか1.8は無い

1.6の範囲はchromeでもサポートされています。個人的にはE4Xがサポートされてないのが辛いです。でもこのへんはFirefoxでしか使えないのでFirefoxが勝手(?)に色々つけくわえてるという印象が…

拡張を大量にぶちこんでも重くならない

FirefoxのUIがブロックする=重たい印象になってると思われるのでFirefoxでもelectrolysisでかなり改善されるんじゃないかと思っています。

たしかにChromeは拡張の量が増えてもUIは重くなりませんが、絶対的に重くならないなんてことは当然なくて、たくさんインストールするとレンダリング終了までにかかる時間は長くなるという結果がパフォーマンステストから示されています。
Extensions performance data – Chromium-dev | Google Groups

結論

• Chromeでサポートされていないけど欲しいものはNPAPI pluginを使って自分で作ればいろいろできるようになります。NPAPI pluginを作るのは面倒ですがnixysaを使うと少しは楽に開発できるらしいです。いまのところnixysaを利用してWindowsで動くバイナリを作るにはハックしてモノにする必要があります。そのハックはネイティブのアプリケーション開発に詳しくないと難しかんじです(CreateLinkはふつうに手で書いて作りましたが、その時バージョンストリングなどが入ったリソースファイルをリンクしないとchromeがpluginとして認識してくれないという謎現象に遭遇しました)。
• Firefoxアドオンの自由度は奇跡的です。millennium | Google Chrome Extensionsを読んでその奇跡を噛み締めましょう。

所感

自分も「GoogleChromeマジ神wwwwwwwwFirefox（笑）」な人を見るとアホかと思いますが、実際のところ大半の人は現在のChromeの貧弱なAPIでできる範囲の拡張でほとんど困らないんだと思います。

それはたまたまなわけでもなくてAaron Broodmanが書いているように

Here’s an interesting factoid about browser extensions: lots of them are not about extending the browser at all. By my count, about 75% of the this week’s top 20 Firefox extensions are more about extending the web content rendered by the browser than extending the browser itself.
aaronboodman.com – Aaron Boodman’s work blog

AMO上位20拡張のうち75%はGreasemonkeyでできることしかやっていない現実を反映しているだけなんでしょう。たしかに自分も職場のWindowsマシンのChromeにはAutoPatchWorkしか入っていません。そしてこのExtensionはGreasemonkeyでできる範囲のことしかやっていません。実際AutoPatchWorkの祖先であるAutoPagerizeはGreasemonkeyのスクリプトです。

ただ予め意図されているようなextensionしか作れないChromeに押され、極めて柔軟で大半のことは実現できるFirefox extensionの開発者が減っていけば、ブラウザの使い方が均質化して行き、ひいてはウェブ上でのサービスの進化が鈍ってしまうのではないかという恐れを感じます。