Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 1/248: 1 2 3 4 5 6 7 8 9 »

Tree Style Tab 4.0でのパフォーマンス改善に至るまでの17年の歴史を振り返る - Mar 08, 2024

先だって、Firefox用の縦型&ツリー表示タブバーアドオンであるTree Style Tab(以下、TST)のバージョン4.0をリリースしました。 このバージョンではサイドバーパネルの設計を大きく変更し、タブの数が多い場面での動作パフォーマンス(消費メモリー、CPU消費、体感速度)が大幅に向上しました。 参考値として、作者環境(Windows 11、Firefox 122.0.1、タブの数536個)で、Firefoxを起動しセッションを復元した直後、TSTも初期化完了した時点でのabout:memoryで計測したTST関連リソースの消費メモリー量は以下の通りとなっていました。

TST 3.9.22TST 4.0TST 3.9.22→TST 4.0の消費メモリー削減割合
メインプロセス10.87MB6.62MB39.1%減
拡張機能プロセス143.92MB83.35MB42.1%減

自分の主観的には、タブを開いた時やツリー開閉時などのもたつきも軽減され、体感的な快適さは大きく向上した印象があります。 タブの数が数千個に及ぶような状況や、Firefoxのプロセスが長期間生存する状況では、メモリー消費量の点でも体感的な速度の点でも、もっと顕著に効果が表れるのではないかと思います。

この改善のために、今バージョンでは前の版に比べて、CSSでのカスタマイズやヘルパーアドオンとの互換性が一部損なわれています。 既知のヘルパーアドオンについては問題無さそうなことを一通り確認済みですが、僕の把握していない物は動かなくなってるかもしれません。

なお、後述しますが、今回のTSTの改善はWaterfoxプロジェクトからの支援によって実現されました。 この場を借りて、プロジェクト主催のAlexさんに感謝の言葉を述べさせて頂きます。 改めて、ありがとうございます!

続きを表示する ...

Android上のFirefoxにアドオンをロードさせる手順 - Dec 27, 2023

Android版Firefox(開発コード名Fenix)用のアドオンを作る上で必要になる、実機での確認の仕方について。 一通りのことはDeveloping extensions for Firefox for Android | Firefox Extension Workshopに書かれていて、それをWindows 11上で実際に自分でやってみたという記録。

注意点。

  • 普段の開発でWSL1(Windowsのディスク領域へのアクセスがWSL2より高速なのでWSL2でなくWSL1を敢えて選んでる)上のUbuntuのコマンド操作を多用しているので、その流れでWSL1上のUbuntuに諸ツールを設定できればよかったんだけど、それは使えない。adbでUSB機器を認識させるフェーズで躓く。WSLでやりたければ、WSL2でないといけない模様。なので今回はWindowsネイティブでやることにした。

まず必要なソフトウェアをインストールする。

  1. Node.js 16以上。自分は現時点でのLTSの最新版であった20.10.0LTSを入れた。
    • システムのプロパティ→詳細設定→環境変数→システム環境変数→PathC:\Program Files\nodejs\を登録しておく。(Node.jsのインストーラが自動で設定してくれるかもしれない。ちゃんと確かめてない。)
  2. web-extのなるべく新しい版。自分はdogfooding用の改造版web-extソースからインストールしている
    • システムのプロパティ→詳細設定→環境変数→ユーザー環境変数→PathC:\Users\piro\AppData\Roaming\npmを登録しておく。(Node.jsのインストーラが自動で設定してくれるかもしれない。ちゃんと確かめてない。)
  3. Android Studioコマンドラインツールのみ。zipファイルを展開して取り出したcmdline-toolsフォルダーを、C:\Program Files\android\sdkに置く。
    • システムのプロパティ→詳細設定→環境変数→システム環境変数→PathC:\Program Files\android\sdk\cmdline-tools\binを登録しておく。
  4. adb(Android SDK Platform-Tools)。zipファイルを展開して取り出したplatform-toolsフォルダーを、C:\Program Files\android\sdkに置く。
    • システムのプロパティ→詳細設定→環境変数→システム環境変数→PathC:\Program Files\android\sdk\platform-toolsを登録しておく。
  5. JDK Development Kit。adbを動かすのに必要。自分は現時点での最新版らしいJDK Development Kit 21.0.1をインストールした。
    • システムのプロパティ→詳細設定→環境変数→システム環境変数→JAVA_HOMEC:\Program Files\Java\jdk-21(パスは実際にインストールしたJDKのバージョンに依存する)を登録しておく。
  6. 自分が使ってるAndroid端末用のADB USBドライバー。自分の場合はSHARP AQUOS sence 7で、SHARP共通のADB USBドライバーでよい模様。
  7. Firefox Nightly(Android版):アプリストアからインストールする。

必要な物が揃ったら、adbでの接続を試みる。

  1. Android端末をUSBケーブルでWindows PCに接続する。
    • Android上でUSBの接続用途を選択する画面が出るので、「ファイル転送/Android Auto」を選択する。Windows上で「MTP」として端末が認識されていればOK。
  2. Android端末のUSBデバッグを有効にする。
    • Androidの設定画面でAndoroidのバージョン情報の「ビルド番号」の所(AQUOS sence 7の場合は 設定→デバイス情報→ビルド番号)を何度かタップして「開発者向けオプション」を有効化し、その中の「USBデバッグ」(AQUOS sence 7の場合は 設定→システム→開発社向けオプション→デバッグ→USBデバッグ)を有効にする。
  3. Android上のFirefox Nightlyを起動し、USBデバッグを有効にする。
    • 設定→詳細設定→USB経由でリモートデバッグする を有効にする。
  4. コマンドプロンプト(cmd.exe)を開く。
  5. adb start-server を実行してadbのデーモンを起動する。
  6. adb devices を実行する。ここまでの手順が成功していれば、接続しているAndroid端末のデバイスIDが以下の要領で列挙される(数字は例示用のダミー)。

    List of devices attached
    856392147208461 device
  7. アドオンのディレクトリー(manifest.jsonがある場所)にcdして、web-ext run -t firefox-android --adb-device (先程調べたデバイスID) --firefox-apk org.mozilla.fenixを実行する。

アドオンの側に問題がなければ、これでアドオンがAndroid Firefoxに読み込まれる。

「なぜMozillaはXULアドオンを廃止したのか?」に寄せられていた反応を見て、「甘い……甘すぎる……」と思って、W3C信者時代からの価値観に行き着いた話 - Aug 27, 2020

1つ前の翻訳記事の末尾には当初、自分の個人的な考えを長々と書いていたのですが、翻訳記事でそういうことをやるのはマナー違反という指摘を頂きました。自分でも確かに、思い入れのあまり熱くなって書きすぎと感じていたので、別記事に分けるついでに増補改訂することにしました。)

原文に寄せられていたHacker Newsでの反応や、僕の翻訳に寄せられていた反応を見ていると、XULを捨てる判断を間違いと断じる物や、そのような判断をしたMozillaに対する恨み節、あるいは「バカな判断をしやがって、そんなだから俺らパワーユーザーから見捨てられたんだ」みたいな捨て台詞じみた物が結構見られました。

それらを見て僕は正直、「これだけ丁寧に書いてあってまだそんな風に思えるってどういうことなの……」と驚くやら呆れるやらしたのですが、自分自身もかつてはそっち側にいた自覚があったので、「なんでそう思うのか」も分からなくはありません。

甘い見通し

今でも「見境のない拡張機能の仕組み」を支持し続けている人というのは、アドオン開発者にしてもユーザーにしても、ある意味で楽天的というか、性善説を信じているというか、そういう感じなのかなあと思っています。

「従来路線でいっても生きていけただろう、少なくとも玄人向けとしてなら生き残れただろう」という意見については、以前の記事で「それでは結局現実に生き残れない」とバッサリ切りましたし、1つ前の記事のコメント欄にも書いてみました。しかし、それとは別に「諸々の進歩を継続しつつ、アドオン開発者やユーザーに自己責任での自由を残すのでは駄目なのか?」という主張もあります。自分もFirefox Quantum以前はそのような立場でした。

この場合の世界観は以下のように要約できるかと思います。

  • アドオン開発者:「自分はFirefoxの変更に振るい落とされることはない、いつまでだって追従し続けられる」と考えている。
  • ユーザー:「アドオン開発者はそのような努力をいつまでも続けてくれる」と考えている。

しかし、自分の体験と先の記事の内容を踏まえて、今僕が思うのは、「甘い……まったく甘すぎる……」ということです。

僕自身、日々壊れていくXULアドオン時代のTSTを維持するのには、ものすごい苦労を要していました。当時はそれが当たり前だと思って麻痺していただけで、実際には狂気の沙汰だったと感じています。TSTをWebExtensions化して以後の感覚では、XULアドオンを書くのなら、実作業時間で1時間あたりN万円くらいのお金を貰って仕事としてやらないと、とてもじゃないけどやってられないです。それくらいに、XULアドオンは維持にコストがかかると言わざるを得ません。「少額ながら寄附を……」とかいうレベルでは収まらない、もはやビジネスの話です。

僕自身はライフステージはそれほど変わらないままですが、結婚や子育てなどライフステージの変化の影響で、毎日アドオンのメンテナンスに時間を割くことはできなくなってしまう人も、当然いたでしょう。メンテナンスに膨大なコストを要するアドオンを継続し続けなくてはならないのでは、作者の人生をそれだけに縛り付けることにもなりかねません。

あるいは、作者個人が自分の使う範囲だけで細々メンテナンスし続ける程度なら可能かもしれませんが、それを「第三者が使いやすい」状態でリリースまでするモチベーションはどんどん下がっていく一方でしょう。

「見境のない拡張機能」は、もはや「ユーザー」はお断りの世界

なぜなら、ものすごく嫌な言い方をしてしまうと、今XULアドオンを一般向けにリリースしても、パッチも提供してくれない・問題の再現条件の特定もしてくれないクレクレ君達からの、「お願いですぅ~直してくださいぃ~ボクにはとてもメンテできましぇ~ん」みたいな声が増えるばっかりで、いいことがないからです。

それは言いすぎだろう、パワーユーザー向けならそんなことないのでは、と思う人もいるかもしれませんが、こういう修羅の世界では「敬意を払ってくれるユーザー」や「お金を出してくれるスポンサー」だけいても、結局は搾取構造にしかならない、と僕は考えています。。

一般的には「OSSにできるコントリビュートはプルリクエストだけではないです。障害報告も立派なコントリビュートです。必要な環境、再現手順、期待される結果、実際の結果を明記した良い障害報告をしましょう」ということを僕も言っていますが、「見境のない拡張機能」の世界では、それですら作者側の負担が大きすぎると言わざるを得ません。プルリクエストやコードを実際に提供し合うような、「同じ技術レベルで共に並び戦ってくれる戦友」同士で助け合う以外には成り立たない、そのレベルで戦列に加われない人に関わられて期待されても困る、というのが正直な所です。

技術的な事実をいうと、今でもFirefoxでは「見境のない拡張機能の仕組み」と同等のことをやる余地は残っています。AutoConfigの仕組みを使って、(Firefoxのインストール先)/defaults/pref/autoconfig.js

pref("general.config.obscure_value", 0);
pref("general.config.filename", "autoconfig.cfg");
pref("general.config.vendor", "autoconfig");
pref("general.config.sandbox_enabled", false);

という内容のファイルを置き、(Firefoxのインストール先)/autoconfig.cfgにゴリゴリ書いていけば、Firefoxのchrome領域上で任意の特権スクリプトを動かすことができます。実際、僕も仕事の上でどーーーーーーしても必要に迫られた場合はそうしていますし、Firefox内部で任意のスクリプトを特権付きで動作させるアドオンだった「userChrome.js」のエコシステムを継続している人達も、この方法を使っているようです。

こういう使い方をすると、前の記事で散々書かれているような「バージョンアップですぐ動かなくなる」「代替策がない」というドン詰まり状況が頻繁に発生します。ググって見つけたブログ記事やQiitaの記事のコピペで使うだけではとても維持できず、「自分で原因を調べて、自分でコードを直す」ということがどうしたって必要になってきます。誰かが直してくれるのをボケッと待ってるだけでは、今のFirefoxのリリースサイクルにはまず追従できないでしょう。

なお、この方法を使っている人達は百も承知だとは思いますが、この方法もいつまで使い続けられるかは分かりません。それでも、「Firefoxのソース自体に手を入れて、Firefoxそのものを独自ビルドする」のは依然として可能です。あるいは、そこまでやるならChromiumに乗り換える(Chromiumを改造して独自ビルドする)方がいいかもしれません。もはや完全に根性試しの世界ですが、腕力さえあれば乗り切れるのがOSSのいい所です。腹を括って「この方向でも生きていけるんだ」ということを示し続けていく人は、いてもいいとは思います。僕にはとても真似できませんが……

Thunderbirdの場合

FirefoxはFirefox 57で「見境のない拡張機能」をバッサリ切りましたが、Firefox ESRのスピード(1年ごとのメジャーアップデート)でゆっくり物事が推移しているThunderbirdは、もう少しソフトランディングな方向で進んでいます。会社のブログに書いたThunderbirdアドオンのTb78対応の話では「使うな」とサラッと流していますが、アドオン作者向けのThunderbird 78向け移行ガイドによると、Thunderbird 78では「公式のWebExtensions APIには含まれていないけれども、こういうAPIが欲しい」という機能があるときに、アドオン作者がそれを自力で実装する、Experimental APIという仕組みが利用できるようです(これはFirefoxでも提案はされていたのですが、なんやかやで結局実際には使える状態にならなかったと記憶しています)。

ただ、そのような本来の意図とは裏腹に、Experimental APIは結局「見境のない拡張機能」と同じことをするための互換レイヤー作りのために使われてしまっているようです。少なくとも、CardBookという巨大アドオンのThunderbird 78対応ブランチでは、ほとんどのソースはXULオーバーレイ前提になっていて、Experimental APIでXULオーバーレイ相当のことをしている様子が伺えました。

まあ、そうしたくなる気持ちは、分からなくもないんですよ。移行ガイドは(ちょろっとしか見てないですが)「こうやってちょっとずつ移行していきましょう」みたいなソフトな書き方をしてるし。一般的に、ハードランディングよりソフトランディングの方がいいとされてますし。前の記事にあった通り、Firefox自体もちょっとずつ段階的に改良されていったわけですし。

でもねえ、XULアドオンのWebExtensionsへの移行だけは、TSTのWebExtensions化で僕がやったように、「腹を括ってゼロから作り直す」以外の選択はないと思うんですよ。XULアドオンとWebExtensionsアドオンではパラダイムが違いすぎて、「ちょっとずつ置き換え」なんてできないんですよ。

「ちょっとずつ置き換えるためにとりあえずExperimental APIで全部持ち越した」の先にあるのは、「ちょっとずつ移行しようと思ってたけど、どうやって移行したらいいか見当もつかない」という混乱、そして何もできずに手をこまねいての停滞、最終的には時間切れ(Experimental APIの廃止)での完全死だけ。そうなる前に、いかに早く頭を切り替えて腹を括ってゼロから作り直そうと思い切れるか、それが生死を分けると僕は思ってます。

優先順位が違ったから僕は腹を括れたのかもしれない

XULアドオンのWebExtensions化では、「WebExtensionsらしいやり方でゼロから作り直して」「APIが足りない部分は、WebExtensionsらしい作法に則ったAPIを提案する」「要望が通らなかったら諦める、無理はしない」というのが最も「正しい」やり方です。自分は一応今のところはそういう方針でやっているつもりですが、改めて考えてみると、僕がこの方針を取れているのは、僕の本心が、多くの「見境のない拡張機能の仕組みに今でもこだわり続けている人達」とは別の所にあったからなのかもしれません。

元記事に寄せられたPale Moonのメンテナーの人のコメントでは、徹底的なカスタマイズを必要としている人のために頑張っているのだ、ということが語られています。それ以外の怨念の籠もったコメントや捨て台詞じみたコメントも、通底しているのは「自分のやりたいようにカスタマイズできることが一番大事、それ以外は二の次」という価値観のように僕には思えました。

対する僕は、「Mozillaの掲げるOpen Webの実現が一番大事、そのために必要な物としてGeckoというレンダリングエンジン実装が継続することが必要、自分のやりたいようにカスタマイズできることは二の次」と考えているようです。いま自分がインターネットを使いたいように使えるのはOpen Webがあってこそで、その邪魔になるなら自分の細かい要望は(なるべく実現できるに越したことはないけど、どうしても衝突するなら)脇に置いても構わない、というか、自分の要望を無理に押し通した結果Open Webが失われては元も子もない、という考え方なのだと思います。

これはべつに、Mozilla信者だからMozillaの言うことに何でも従ってる、というわけではありません。Mozillaに入れ込むようになるより以前、W3C信者として調子こいてた頃に僕が入れ込んでいた、アクセシビリティとかユニバーサルとかの話が先にあって、Mozillaの掲げるOpen Webはそれに連なる物だと捉えている、ということです。(そもそもで言えば、僕はWeb標準を素晴らしいと思っていて、そのWeb標準の技術に基づいたXULとCSSて実用的なデスクトップアプリケーションを作れる実例が示されていたから、ということでMozillaに入れ込むようになったのでした。)だから、もしMozillaが「Open Webなんかどうでもいい、Web技術の標準化とかどうでもいい」なんて言いだしたら、僕はその時の方が深く失望すると思います。

 

この日記の話題が、ここ数年ジェンダーとか差別とか多様性とかそういう話ばっかに偏ってた感じはありましたし、「シス管系女子」でみんとちゃんやその周辺の人物達の様子を描くときにもそれがずっと裏テーマとしてはあったんですが、それらも大きな括りでは近いところにあるんですよね。

そう考えると、僕がやってることはあれもこれもどっかで繋がってるんだなと。しがないラジオのとき自分のやってきたことを線で繋いだ図にしたけど、単にバラバラにそれらがあったわけじゃなく、1つの価値観の多様な表現形だったということなのかなと。

W3C信者活動をやめてすっかり軸足がよそに移ってしまったと思ってたけど、判断の根底にはまだまだW3C信者だった頃の何かが残ってたんだなあ、と改めて思い知らされて、感慨深い思いをしたここ数日だったのでした。

なぜMozillaはXULアドオンを廃止したのか?(翻訳) - Aug 22, 2020

原著:David Teller, 2020年8月20日CC BY-NC 4.0で公開されている内容の全訳。Qiitaにもクロスポストしています。

要約:Firefoxはかつて、XULとXPCOMに基づく偉大な拡張機能の仕組みを持っていました。この仕組みは長い間私達によく尽くしてくれました。しかし、Firefox開発者と拡張機能開発者の両方にとって、メンテナンスコストは増大し続けるばかりでした。ある面では、増大していくコストは、Firefoxをセキュアにしたり、高速化したり、新しい事を試したりするための努力を、少しずつ破壊していきました。また別の面では、増大していくコストはアドオン開発者のコミュニティを少しずつ破壊していきました。最終的に、古いアドオンの仕組みを守ろうとして数年を過ごした後、Mozillaは、この拡張機能の仕組みを廃止し、それより拡張性は劣るもののメンテナンスしやすいWebExtensions APIに置き換えるという、難しい決断をしました。この選択のおかげで、Firefox開発者は再び、セキュリティや安全性やスピードを改善するために必要な変更を行えるようになったのです。

ここ数日、私はFirefoxのユーザーと会話して、2020年8月のMozillaによるレイオフの結果に関する噂と事実を区別しようとしていました。その過程で何度か持ち出されたのが、Firefox Quantumへの移行におけるXULベースのアドオンの廃止のことでした。私は非常に驚きました。もう何年も前に起こったことについて、この選択に感情を害されたと感じている人が、コミュニティにまだいるということにです。

そして、誰かがredditで指摘していたとおり、私は、何故XULベースのアドオンの廃止以外に選択の余地が無かったかについて、私達が深いところを説明する機会をまだ持っていなかったということに気付きました。

そこで、アドオンとGeckoの内部事情の話に飛び込む準備ができている人向けに、これを機にもう少し詳しい話をしてみようと思います。

続きを表示する ...

XML関連技術に基づくクロスプラットフォームなアプリ開発基盤を夢見たロストテクノロジー:XPCOM, XUL, XBL, GRE, そしてXULRunner - Dec 06, 2018

ロストテクノロジーAdvent Calendar 5日目に予告無しで飛び入り参加のPiroと申します。

アンテナの高い皆さんにとって、開発環境の重要なファクターであるテキストエディタの最低ラインはATOMかVisualStudio Codeでしょうか。では、これらがElectronというChromiumベースの実行環境上で動作するHTML/CSS/JavaScriptで書かれたアプリであるという話を聞いたことはないでしょうか。

Webベースの技術で実用的なローカルアプリを作れるなんて素晴らしい! そこに目をつけるとはさすがGutHub! と思いますか? しかし実際の所は、そういう試み自体は過去から何度もあったのです。WebkitベースでFlashも取り入れて当時のWebのリッチな体験をそのままローカルに持ってこようとしたAdobe AIR、HTMLとJScript/VBScriptのミックスでWindowsローカルアプリを作ろうとしたHTML Application(.hta)。この記事で語るXULRunnerも、そんな試みの中の一つです。

続きを表示する ...

Firefox 57とかWebExtensions移行後のツリー型タブとかがクソとかゴミとか言われているのを見て思う事 - Dec 07, 2017

Firefox 57がリリースされた前後から、アドオンが使えなくなってクソだとか改悪だとかの感想を目にする機会があって、気分が滅入る事が度々ありました。

自分自身は、これは必要な事だったと思っていますし、絶望は1年ほど前に嫌というほどし尽くして、今はもう「で、どうやって乗り越えるか」というフェーズに気持ちがすっかり移ってしまっているため、それらの後ろ向きなコメントには正直な所「えっまだそんなこと言ってるの……」という感想を抱いています。そんな後ろ向きな事を言っていないでもっと生産的な事をしましょうよ、と思わずにはおれません。

しかし同時に、自分自身も他の分野ではエンドユーザーとして後ろ向きな選択をしている場面は多々あり、同意する部分が無いとも言えません。というか今絶望している人達と同じような事をつい1年から2年ほど前には自分も言っていた訳で、それを思い起こす度に、し尽くして乗り越えたはずの絶望が何度も蘇ってきて、「何故自分がこんな理不尽な思いをせねばならん(かった)のだ?」と憤りの感情が頭をもたげてくるのは否めません。

そういう自分の中での混乱を鎮めるために、エンプティ・チェアを2~3個置いて自分の思う所と結論に至るまでの経緯を各立場から辿り直し、考えを整理してみる事にしました。

続きを表示する ...

Why I won't migrate some addons from XUL to WebExtenions? - Nov 19, 2017

この記事の日本語版があります。

Recently I got requests for migration of "2 Pane Bookmarks" to Firefox 57 and later. However, I won't do that. And there are more addons won't be migrated by my hand.

This article describes "why I won't", for example the case of "2 Pane Bookmark".

It was easy on legacy XUL addons, but not easy on WebExtensions

Because old XUL addons were actually dynamic-applied patches, they could recycle Firefox's internal implementation regardless they were not public APIs. Basically "2 Pane Bookmarks" was built on such characteristics of XUL addons.

Actually, it recycled Firefox's internal codes around bookmark trees and just added two changes: "filter to show only folder tree" and "filter to show bookmark items in the current folder". That was all of the addon did - I didn't have to make more effort. Moreover, to be honest, I started the project from just one reason: "Oh, interestedly it is easy to do! I try to do that!" - yes, just for curious.

On the other hand, WebExtensions addon cannot do that. If I migrate the addon to WebExtensions, I will need to implement everything from scratch: listing bookmarks, implementing drag-and-drop, context menu on bookmarks, commands in the context menu, and more. It is very tiresome.

(So I had to reimplement the tab bar completely including the context menu itself on tabs, for Tree Style Tab 2.0 and later.)

Is there any reason to do migration overcoming the tiresome?

As I described above, I started "2 Pane Bookmarks" project just because it was easy to do. However, now it is not easy but very tiresome. If I did the migration, there were any other reason.

  • If I strongly depended the addon, it is the largest reason for migration. Actually, I depended on "Tree Style Tab" and other already migrated addons and I really needed them, thus I migrated them - despite they lost some features from restrictions of WebExtensions APIs. On the other hand, I don't depend on "2 Pane Bookmark" - I ordinarily use "Bookmarks" toolbar button and its dropdown menu.
  • If it is a technically-interesting challenge, I possibly try to do it. However, I'm not interested in WebExtensions-Based 2 Pane Bookmarks - it won't be funny, ther is only tiresome.
  • If it is requested as a business on my employer company, I'll do that. But "2 Pane Bookmarks" seems not for company use, just for private. Sadly no company customer seems to hope its migration.

Basically I have very few time to develop addons in my private time, because I have to spent much time to write/draw technical comic for periodically-issued magazine. By these reasons, sorry but the addon "2 Pane Bookmarks" will never migrated by me.

Conclusion

Still there are some more unmigrated addons I depended on:

  • Second Search: I really want a search box to type arbitrary terms into, and I hope to search it by any web service after the input. Firefox's built-in feature "One-Off Search" does that, but it doesn't list search services I created as bookmarks with keyword. I think I need to provide new search box for bookmarks with keyword.
  • Informational Tab: especially thumbnail in each tab. It is impossible for Firefox's native tabs, so I'll implement it as an addon to extend Tree Style Tab.
  • New Tab from Location Bar: I don't know its technical possibility, but it is not supported by Firefox itself yet and it won't be done in near feature, so I need to try that.

I'm very sorry but addons not listed here won't be migrated by my hand. I hope that someone who really want develops successor version of them.

僕自身の手によるWebExtensions版開発が期待できないアドオンについて - Nov 19, 2017

There is the English version of this article.

2ペインブックマークをFirefox 57以降に対応して欲しいという要望を頂くのですが、残念ながら結論を先に言えば、僕の手による2ペインブックマークのWebExtensions移植はまず行われないと思って頂く他ありません。同様に、他にもいくつかのアドオンについて僕の手による移植は期待できない状況です。

以下、2ペインブックマークの場合を例にとって、何故僕の手による移植が期待できないかを説明します。

従来型アドオンでは簡単にできて、WebExtensionsでは簡単にはできない、という事がある

Firefoxの内部に食い込む従来型アドオンでは、そのような仕組みならではの特徴として、「Firefox本体が使っている仕組みを(APIとして整備されていないものでも)勝手に流用できる」というメリットがありました。

2ペインブックマークは元々、その特徴を最大限に活用して開発されたアドオンでした。 実際、Firefox本体のブックマークツリーのためのコードをほぼそのまま流用し、そこに「フォルダだけ表示するための絞り込み」と「選択されたフォルダの中身だけを表示するための絞り込み」という一手間を加えることによって、それ以外の事をまったくしなくても最小限の労力で実現できる、という背景があったことから成立していました。 というか、「簡単にできるのならやってみよう」というのが動機で作り始めたと言っても過言ではないです。

他方、WebExtensionsではそのような事はできません。ブックマークの列挙、表示、ドラッグ&ドロップ時の動作(ブックマークのツリー上に何かがドラッグ&ドロップされた時の対応も含む)、右クリックされた時のメニューそのもの、その中身となる各種のコマンド、などなど、ブックマークに関わるすべてをゼロから作り上げなくてはなりません。 つまり、実質的には「ブックマークパネルを再実装する」という事になります。これは大変な労力です。

(ちなみに、そういうわけなので、既にWebExtensions移植済みのツリー型タブのバージョン2.0以降も、Firefoxのタブバーに等しい物を、そこで表示されるコンテキストメニューやそれに関わるAPIも含めて、ひたすら愚直に再実装しているという事になります。

面倒さを乗り越えて開発するだけの動機の有無

上述したとおり、2ペインブックマークは「簡単にできるのならやろう」という動機で始めたと言っていいプロジェクトです。 簡単にはできない事が明白である以上、最大の動機がそこにはありません。 それでもなお僕がアドオンのWebExtensions版を開発するとしたら、それ以外の動機が必要です。

  • 自分がそれを使っていて強く依存しているかどうか。「ツリー型タブ」をはじめとして既にWebExtensionsに移行済みのアドオンは、自分自身がそれに強く依存しており「自分自身がユーザーとして、無いと困るので」、そのような強い動機から、APIの制限のために移行できない機能がある事を承知の上でWebExtensions版を作成しました。残念ながら2ペインブックマークは自分自身にそこまでの思い入れがありません(自分は普段はツールバー上のブックマークボタンからの一覧表示だけを使っています)。
  • 技術的な挑戦として面白そうかどうか。上述したとおり、従来型アドオンとしての2ペインブックマークは「最小限の労力でこれを実現できる」という事が自分にとっては技術的に面白い部分でしたが、WebExtensions版は「ひたすら面倒なだけで、特に技術的に面白いわけではない」という事が既に分かっています。自分にとってはこれは魅力的に感じられません。
  • お金をもらえる仕事かどうか。自分が使っていなくても、技術的に面白くなくても、会社の仕事として受注したものであればそれはもちろん仕事としてお引き受けします。が、残念ながら拙作のFirefox用のアドオンはそのほとんどが個人利用向けであることから、そういった展開には期待できません。

そもそも漫画の作業のためにプライベートの時間をあまり割けない状況下で、それを押してでもやる動機が無い以上、僕の手による移植が行われることはまず期待できない、というのが現状での結論ということになります。

まとめ

今の所、僕が手がけたアドオンの中でまだWebExtensionsになっていないもののうち、自分自身が強く依存していた物は、以下の通りです。

  • セカンドサーチ(入力欄に思いついた検索語句を入力したら、その後で検索エンジンを選択して検索を実行できる、という機能。Firefoxの検索エンジンについてはOne-Off Searchでそれが可能だが、ブックマークキーワードとして登録した物に対してはそれができないため、ブックマークキーワード用の検索窓を用意する必要があります。)
  • 情報化タブ(の中の、タブのサムネイル表示機能。これはFirefox本体のタブに対しては絶対に実現不可能なので、ツリー型タブと組み合わせて使う想定です。)
  • ロケーションバーから新しいタブを開く(技術的な実現可能性は不明ですが、Firefox本体でこれと同等のことを可能にする設定が実装されるのがまだまだ先の事になりそうなので、それまでの当座を凌ぐために挑戦してみたいと思っています。)

すみませんが、これら以外の物については、必要としていて作る動機がある方に後継版開発の希望を託したいと思っています。

テキストリンクのWebExtensions移行、失敗と成功の分かれ目について - Nov 04, 2017

このエントリはQiitaとのクロスポストです

Firefox 57で従来型のアドオンが使えなくなるという事で進めているアドオンのWebExtensions移行作業ですが、ツリー型タブマルチプルタブハンドラに続いて、テキストリンクもWebExtensionsに移行しました。移行後の最初のバージョンは6.0.0で、そこから若干の修正を施した最新版は6.0.1となっています。

テキストリンクってどんなアドオン?

テキストリンクは、テストケースの各種の例のようにWebページ中に普通のテキストとして書かれたURI文字列を、ダブルクリックするだけでリンクのように読み込めるようにするという物です。最盛期には10万を超えるユーザーに使われていた事もあった、僕がMozilla Add-onsに登録していたアドオンの中では統計上最もユーザー数の多「かった」アドオンです。

個人的にもこれが無いとイラッとする場面が結構あって地味に依存度が高かったので、いずれWebExtensions移行はするつもりでいたのですが、先月末にMozilla Corporationのアドオンコミュニティマネージャーの方(昨年のMozLondonにアテンドしてくださった方)から「そろそろFirefox 57リリースが近付いてるけど、テキストリンクの移行はどんな感じ?(大意)」というメールを頂いてしまい、顔を合わせた事のある人から直々にせっつかれてはやらないわけにはいくまい……と、予定を繰り上げて移行に着手したのでした。

メールをもらってからリリースまでに要したのがちょうど1週間で、これまでの2例の難航度合いに比べるとびっくりするぐらいあっさり完了した感があります。数を重ねてきてだんだん「WebExtensionsのやり方」に慣れてきたということでしょうか。

実を言うと、テキストリンクは1年ちょっと前にWebExtensions移行に挑戦してみた事があったのですが、その時は途中ですっかり投げ出してしまっていたのでした。今回は、この時の成果物をまるっきり無視しての再挑戦での成功と相成りました。

1回挫折した物が仕切り直して成功したという典型的な例なので、ここでは「何故前回は失敗し、今回は成功したか」という観点から語ってみようと思います。

移行に失敗した時にやった(やろうとした)事

過去の挑戦時の方針は、端的に言えば「最低限の手直しでの移行」ということになります。

テキストリンクは初版が2004年という非常に歴史の古いアドオンで、Firefoxの仕様変更に対し、その都度手直しでの追従を繰り返してきました。最初のバージョンからバージョン4までの間、テキストリンクはすべての処理が特権領域内で完結する仕様でした。バージョン5でのe10s(マルチプロセス)への対応にあたって、DOM RangeなどのWebページの生のDOMに触らないといけない「コンテントプロセス側で実行しなくてはならない処理」を分割するという変更を行いましたが、本質的な設計はずっと変化していなかったと言えます。

その延長線上にあったこの時の進め方は、WebExtensions化の作業用にブランチを切って、元のコードを「バックグラウンドスクリプト用」や「コンテントスクリプト用」といったフォルダに移動し、XPCOMやXULに依存していた部分を除去していく形でそれぞれのソースの中身を破壊的に変更していく、というものでした。

旧版テキストリンクは、選択範囲(※カーソルも選択範囲の一種なのです)からのURI検出や、ユーザーの操作からタブで開くかウィンドウで開くかといった判断を行う部分など、主要な処理のほとんどがコンテントプロセス側で動作する設計でした。chromeプロセス側は、コンテントプロセスからの指示に従って実際にタブやウィンドウを開くだけという感じです。

また、それとは別にコンテキストメニュー周りの実装がchromeプロセス側にあり、こちらはユーザーがコンテキストメニューを開いたタイミングで処理を開始して、コンテントプロセスに処理を依頼してはその結果を受け取って……という事を繰り返すようになっていました。

これをそっくりそのままWebExtensionsに持っていこうとすると、主要な処理はすべてコンテントスクリプトに移植することになります。しかし、WebExtensionsではコンテントスクリプトでできる事の範囲が大きく制限されています。そこで「コンテントスクリプトではこの機能が動かないのでバックグラウンドスクリプトに移す」という事をその都度やっていると、キリが無い上に、場当たり的な切り貼りの繰り返しでコードはどんどんカオスになっていきます。

また、従来のアドオンでの「コンテントプロセスで動作するスクリプト」とWebExtensionsの「コンテントスクリプト」には大きな違いがあります。それは、従来のコンテントプロセス用スクリプトは「1つのプロセスにつき1つのインスタンスが作られる」のに対し、コンテントスクリプトはタブ内のフレームの数だけインスタンスが作られるという点です。プロセスの数だけインスタンスが増えるという時点でいかがな物かという感じですが、フレームの数だけ増えるとなると、さすがに主要な機能をそこで動かすのは非効率的です。

このほか、コンテキストメニュー項目の動的な更新についての知見がなかったために、選択範囲からのURI文字列の検出結果を受けてメニュー項目を制御するやり方が分からなかった事や、XPCOMとXULがあることを前提として書かれたコードを総点検してXPCOMフリーに書き直すにあたって、代替手段が見つからなかった処理がいくつかあった(WebExtensionsでも最新のWeb技術でも機能が提供されていない部分があった)事など、数々の困難に嫌気がさし、また「シス管系女子」の連載の〆切が迫っていた事も相まって、道半ばで移行作業を放棄してしまったのでした。

TSTの移行に際しての振り返りで「直接Firefoxの中身をいじくり回していたレガシーなアドオンを『若干手直ししてFirefox 57でも使えるようにする』ということは不可能」と書きましたが、この時の失敗はまさにこれが原因であったと総括できます。例えて言うなら、従来バージョンから持ち越した既存の実装という大荷物を背負って道を歩いていて、道のど真ん中にある車止めに荷物が引っかかってしまい先に進めず、「こんなもんどけてやる!」とばかりに軽く考えて邪魔な車止めを取り除こうとして、でも地面にしっかりコンクリートで固定されていて蹴っても叩いても動きやしなくて、その埒の明かなさと背負っている荷物の重みとのダブルパンチで心が折れてしまった……という感じでしょうか。

移行に成功した時にやった事

今回の再挑戦では、TSTやMTHのWebExtensions移行で成功をもたらした「旧版の動作をリファレンスとして、同等のユーザー体験をもたらす新しいWebExtensionsベースのアドオンを新規に開発する(つもりで臨む)」というやり方を取りました。具体的には以下の順で作業を進めました。

  1. 「選択範囲とその前後のテキストの抽出」といった必須の要素技術をコンテントスクリプトで実装する。
  2. 文字列からのURI文字列の検出という、純粋にJavaScriptのコードだけで完結できるモジュールを、従来版から選択的にバックグラウンドスクリプトとして移植する。
  3. ダブルクリック操作をトリガーとして、コンテントスクリプトで可視状態のテキストを抽出し、それをバックグラウンドスクリプトに送ってURIを検出させて開く、という形で最も基本的な機能を実装する。
  4. 開いた後のURI文字列を選択範囲にする、という挙動を実装する。
  5. 選択範囲の変化をトリガーとして、コンテントスクリプトで可視状態のテキストを抽出し、それを材料にバックグラウンドスクリプトでURI文字列の検出とコンテキストメニューの更新を行う、という一連の事を実装する。
  6. テキスト編集領域内での動作に対応する。
  7. 設定画面を実装する。

この説明にも表れている通り、今バージョンのほとんどのコードはスクラッチで書いた物で、旧版からコードを引き継いだのは「文字列の中からURIらしき部分を検出する」部分だけです。以下、一般的な話は省略してテキストリンクに固有の事情だった部分に絞って詳しく述べます。

選択範囲やその前後にあるテキストの、見た目通りの状態での抽出

URI文字列を検出するにあたっては、window.getSelection()で取得できるRangeのtoString()の結果ではなく、「ページ中で目に見えているとおりのテキスト」を対象にマッチングを行わなくてはいけません。というのも、RangeのtoString()はその範囲にあるテキストノードの内容を単純に連結した結果を返す物なので、親要素が非表示であるテキストノードがある場合や、CSSのdisplay:blockなどで見た目上改行されているだけの部分がある場合に、「見た目上は改行されているように見えるのにデータ上は改行が存在しないので、複数の行が連結されて見える(そのためURI文字列の検出結果がおかしくなる)」という事が起こるからです。

旧版では、Webページをプレーンテキスト形式で保存する場面や、ThunderbirdでHTMLメールとして編集された本文からプレーンテキストの本文を生成する場面などで使われるnsDocumentEncoderというXPCOMコンポーネント@mozilla.org/layout/documentEncoder;1?type=text/plain)を使ってこれを一発で行えていたのですが、WebExtensionsでは当然使えません。相当する機能を提供して欲しいというbugはずいぶん前に立てたのですが、今に至るまで具体的な実装はまだなされていないままなので、諦めて自力で実装してみました。

詳しい事は当該処理のソースを見てもらうのが一番早いのですが、簡単にいうと、DOM2 TraversalのTreeWalkerを使って泥臭い事をやっています。TreeWalkerはnextNode()previousNode()を使うとDOMツリー上の全ノードをツリー構造を無視して文書順で参照するイテレータとして使えるので、CSSのセレクタやXPathでは条件にできない生のDOMの情報を条件とした絞り込みを行っています。具体的には、まずNodeFilter.SHOW_ELEMENT | NodeFilter.SHOW_TEXTでざっくりテキストノードと要素ノードに絞り込んで、さらにそのノードの祖先に非表示の要素ノードがないかをwindow.getComputedStyle()で順にチェックして、確かに可視状態だと確認できたノードだけを取り出しています。その後、テキストノードであればnodeVaueを、要素ノードでdisplay:inline以外の物があれば適宜改行文字を「表示されているテキスト」として取り出しています

以上のようなやり方で、一応実用に耐える精度で「見た目通りのテキストを抽出する」を実現できたのですが、想像の及んでいなかったエッジケースなどで想定外の結果になる可能性は依然としてありそうな気がしています。nsDocumentEncoder相当の機能が実現されるまでは、まだまだ悩みは尽きない感じです。

文字列からのURIの検出処理

与えられた文字列からURIを検出する処理は、今回の移行で唯一、旧バージョンからほとんどそのままコードを引き継いだ箇所です。

この処理は、データ量にして最終的に完成したWebExtensions版テキストリンクの全体の1/3を占める巨大なモジュールなのですが、やっている事は至って単純で、「相対パスも許容するのか?」「全角英数字も許容するのか?」等の条件に基づいてURIらしき文字列にマッチする正規表現を組み立てるだけの物です。相対パスを絶対パスに解決する部分などでXPCOMコンポーネントの機能を使っている部分はありましたが、全体の中ではそういった箇所はごく一部に限られており、ほとんどは単純な文字列処理だけで構成されていました。

また、元々自動テストを容易にするためにモジュール間の結合を弱めていた結果、機能を使うのに必要なパラメータはほとんどすべて外部から与えられるようになっており、旧テキストリンクの実装の中ではここだけ突出して浮いているようにも感じられるほどでした。

そういう事情があったため、このモジュールについてはほとんど苦労する事なくほぼそのままの形でWebExtensions版に組み込む事ができました。

ダブルクリック操作で開いた後のURI文字列を選択範囲にする

旧版テキストリンクでコンテントプロセス側に大部分の処理があったのは、「URI文字列として検出した部分を新しい選択範囲にする」という挙動を実現したかったからでした。これをやるには、Rangeを対象に文字列を検索してヒット箇所をRangeで返すというAPIが不可欠です。

旧版ではnsFindというXPCOMコンポーネント@mozilla.org/embedcomp/rangefind;1)を使ってこれを実現していましたが、当然ですがこれはWebExtensionsでは使えません。また、W3Cで提案されていたらしいRangeFinderというAPIが実装されていればそれで代替できたのですが、こちらは残念ながら未実装です。という具合で代わりの手段がなかったという事が、過去の移行失敗時に移行を断念した理由の1つでもありました。

幸い、最近になってWebExtensionsにbrowser.findというAPIが追加され、Firefox 57ではRangeFinder的な事ができるようになっています。なので今回はこれを使ってみる事にしました。

RangeFinderを使う時にネックになるのが、DOM Rangeの取り扱いです。コンテントスクリプトとバックグラウンドスクリプトの間ではJSON文字列に変換できるデータしか交換できないのですが、browser.findはコンテントスクリプトでは動作しないためバックグラウンドスクリプトで呼び出す必要があり、しかし選択範囲の操作はコンテントスクリプト側でやらなくてはならない……ということで、どうやってDOM Rangeの情報を双方の間で受け渡すかが問題となります。

この事について何かヒントはないかとbrowser.find.find()の説明を読み進めてみた所、まさにこの通りの事をやる例が載っていました。このAPIはrangeDataという形式で検索結果のRangeをシリアライズして返すようになっており、その情報に基づいてコンテントスクリプト側でRangeを組み立てれば良いようです。DOM Rangeをシリアライズして受け渡す事自体は容易に考えつくものの、どういう考え方でシリアライズするかという事についてはいろいろな考え方が可能であったため、自分で考えていたらそれだけでまた時間がかかってしまっていたでしょう。「既に動いている実装があるのなら、それとフォーマットを揃える」という具合に考える手間を省けたのは助かりました。

ただ、実際にbrowser.find.find()を使ってみるとメチャクチャ遅いです。それもそのはず、このAPIは検索対象の範囲をRangeで絞り込む事ができなくて、実行すると必ずページ全体を対象に検索し、しかもすべてのヒット箇所を列挙してくるのです。検出対象のURIの数が増えれば増えるほど実行回数が増え、ページが長くなればなるほど1回あたりの処理時間が増えるという感じで、テストケースのページ全体からURIとしてマッチした箇所をRandeで取り出すのにトータルで10秒とかそのくらいかかってしまいました。なので最終的には、バージョン6.0.1の時点では「選択範囲が変化したらまずbrowser.find.find()無しでURI文字列の検出だけを行い、それらを開くとかコピーするとかの操作が行われた時点で初めてbrowser.find.find()を実行してRangeを取り出す」という風にして、日常的な操作であるテキストの範囲選択とコンテキストメニューの操作に悪影響が出ないようにしています。

選択範囲の内容に応じてコンテキストメニュー項目の表示・非表示を切り替える

Firefoxの各種メニューに項目を追加するためのAPIであるbrowser.menusbrowser.contextMenusでは、menus.ContextTypeのいずれかを伴って定義したメニュー項目については、その指定にマッチする場面でのみ表示されるようになります。その中にselectionというコンテキストもあり、テキストリンクの「選択範囲内のURIを待て馬手開く」系の機能はそのようにして登録しています。

しかし、ここに1つ問題があります。このコンテキストでは「テキストを範囲選択しているかどうか」しか考慮されず、「その中にどういう内容が含まれているか」までを判断材料とする事ができないのです。

テキストリンクは選択範囲のURI文字列を開く物ですから、選択範囲にURIらしき文字列が無い時にまでメニュー項目が表示されるのは混乱の元です。そこで旧版ではコンテキストメニューが開かれる瞬間に発火するpopupshowingイベントを検知してメニュー項目の表示・非表示を切り替えていたのですが(これ自体はXULで作られたアドオンの一般的な作法です)、他方、WebExtensionsのbrowser.menusで監視できるイベントには「メニューが開かれた時」に発火されるイベントがありません。これじゃあ動的にメニューの表示・非表示を切り替えられないじゃないか!ということで、これも過去の移行失敗時の躓きポイントの1つとなっていました。

現時点に至るまでpopupshowingを代替できるイベント型はまだ実装されていないままなのですが、この回避策はTSTやMTHのWebExtensions移行を進める中で知らず知らずのうちに気が付いていました。要するに、「コンテキストメニューが表示されようとしているその時にメニューを更新する」のではなく、「コンテキストメニューの内容に影響を与える変化が起こったまさにその時に先行してメニュー項目を変化させておく(メニューが開かれる時には、既に定義済みのメニュー項目が表示されるだけになる)」という事なのです。その後実際にコンテキストメニューが開かれなければこの時の処理はまるっきり無駄になってしまいますが、これ以外に方法がない以上は仕方ありません。

WebExtensions版テキストリンクでもこの方針に則って、「selectionchangeイベントコンテントスクリプトで監視し、変化があったらその時点で選択範囲からのURI文字列の検出を開始する指示をバックグラウンドスクリプトに送る」→「バックグラウンドスクリプトでコンテキストメニューの内容を更新する」という事を行うようにしました。バージョン6.0.0の時点では前述のbrowser.find.find()がメチャクチャ遅いという問題に引きずられて、範囲選択から数秒待たないとコンテキストメニューの内容が更新されないという状況でしたが、バージョン6.0.1で範囲選択時のURI検出にはbrowser.find.find()をバイパスした簡易的な処理を使うようにした結果、概ね一瞬でメニューを更新できるようになり、実用上ほとんどの場合では「しばらくお待ち下さい」的なメッセージを目にする事はなくなりました。

この件を通じて、コンテキストメニューでAPIで用意されているコンテキスト以上にきめ細かい判断を行いたい場合に、WebExtensionsでのベストプラクティスはレガシーなXULアドオンでのベストプラクティスとはまったく異なるのだ、という事をまざまざと思い知らされたのでした。

テキスト編集領域への対応

旧版テキストリンクでは、<textarea>などのテキスト入力欄についてもXPCOMコンポーネントの機能を経由して内部的なDOMツリーに触っていました。これは、上記の「検出したURIの箇所を新しい選択範囲にする」という挙動を実現したかったからです。しかしWebExtensionsではその方法が使えず、テキスト入力欄内部のDOMツリーには触れません。

じゃあどうすればいいのかという話なのですが、これについては「無理なものは無理」という事で、テキスト入力欄の選択範囲はその要素ノードのselectionStart/selectionEnd/setSelectionRange()を介して触れる範囲以上の事はしない事にしました。

移行に失敗した時の考え方だと、こういう時も何か対策はないかと手を尽くして、それでも機能が見つからなくて仕方なくBugを立ててそれが解決されるのを待つ、という事になっていたでしょうが、今回は「完全でなくても今できる範囲でできる事だけをする」という方針だったため、この点はリリースをブロックする要因にはなりませんでした。

まとめ

はじめからやり直したい症候群や、それに類する言葉を見かける事があります。プログラミングの世界においても、メジャー製品の大規模アップデートで「ここらで一区切り付けて、最初から作り直してもっとスッキリした設計にしよう」みたいな事をやろうとして、収拾がつかなくなり失敗に終わってしまい、最終的に旧版からの小規模な修正のみに留めるしかなかった……みたいな事はたまにあります。そういった事例をいくつか見聞きして、また自分自身もそういった無謀な挑戦をしようとして挫折するという経験を何度かした結果、「スクラップ&ビルドですべてが上手くいくようになるというのは甘い幻想で、実際には地道な改良をコツコツ続けていくしか無い」という教訓が、自分の中である種の呪いのように刻み込まれていました。

しかし実際には、その「教訓」に従って進めようとした前回の移行は失敗に終わり、大部分でスクラッチに近いレベルでの作り直しとなった今回の移行の方が成功するという皮肉な結果となりました。ただし、今回スクラッチせず引き継いだ部分まで作り直していたら、この移行は再び失敗に終わっていた事でしょう。

  • 「ああもうめんどくさい、リセットしちまおう」と乱暴に投げ出してしまわず、小さな改良の積み重ねで乗り切るのが適切な場合
  • 「これは小さな変更で乗り切れるようなレベルの話じゃない」と割り切って、一からやり直す方が適切な場合

今まさに自分が直面している問題がどちらのケースなのか、を適切に見極めるのは難しい事です。考える事を放棄して当て推量で雑な判断をすれば、痛い目を見ることになるのは自分自身です。確実な成功に繋げるためには、そこで使おうとしている・使わなければならない技術の特性と限界、現行技術とのギャップの大きさ、取り組んでいる問題の複雑さなど、様々な要因を考慮に入れた総合的な判断を、プログラム全体やモジュール単位で下す必要がある、という当たり前といえば当たり前の事を、自分は今回の移行を通じて実感した次第です。

マルチプルタブハンドラもWebExtensionsに移行しました - Oct 13, 2017

ツリー型タブのWebExtensions移行の後半作業と並行して進めてたマルチプルタブハンドラのWE移行ですが、こちらも一区切りとしてバージョン2.0をリリースしました。こちらはTSTほどには語る内容が無いので手短に。

マルチプルタブハンドラ(以下、MTH)は元々、「そこにあるFirefoxのタブを雑にドラッグして選択したらメニューが出てきて『で、この選択したタブをどうしたい?』と次のアクションを訊ねてくる」という、操作対象を起点とした操作、本来の意味での「オブジェクト指向」らしい操作というコンセプトに基づくアドオンでした。そのコンセプトを具現化するために、レガシー版ではタブの上でのクリックやドラッグどいった操作をハンドルし、時にFirefox本体の挙動をキャンセルして、「タブをドラッグして選択」という挙動を実現していました。

ところが、WebExtensionsではFirefoxのタブの上での生のイベントをハンドルすることが許されていませんそういうAPIが欲しいという要望は挙がっていましたが、WebExtensions APIのコンセプトに反するということでWONTFIXになっています。よって今後もそういう事ができるようにはならないでしょう。

ただ、WE版TSTは専用のサイドバーを提供していて、その中で発生するイベントを扱う事に関してであれば自分の裁量で好きなようにAPIを提供できます。 なので、WE版MTHは当初は「TSTに完全に依存したアドオン」として開発を始め、TSTにAPIを実装してはMTHでそれを使ってみるという形で両者の開発を並行して進めていたのでした(TSTのAPI整備とその動作検証のための体のいい実験台になってもらったとも言えます)。 その過程で、ツールバーボタンから開いたパネル内であればドラッグ操作でのタブの選択もできなくはないと思い立ったため、TST完全依存のアドオンではなく一応単体でもそれなりに機能するアドオンとしてリリースする方針に切り替えて不足部分を整備し、この度ようやくリリースに至った次第です。

そういう経緯なので、本来意図していたMTHのユーザー体験は、WE版においてはTSTとの併用時においてのみ実現されています。単体のWE版MTHはあくまで仮の姿で、TSTと併用した時にのみ真価が発揮されるとは、なんとも中二病くさい仕様ですね。

ところで、Firefoxにはずいぶん前から(具体的には8年前から)タブを複数選択する機能の実装提案がなされています。 この機能がいつまで経っても実装される様子がないので、渋々MTHを今までメンテナンスしてきた、という部分も実を言うとあるのですが、なんとここに来てそれなりの優先度で解決(実装)に向けて動き始めてきたようです。 もっと早くやってくれていれば、MTHはWE版を開発せずそのまま開発終了にできたかもしれなかったのに……

ともあれ、将来のどこかの時点でMTHがお役御免となるのなら、それに越したことはありません。 その日が来るまでの間は、できる限りメンテナンスを続けていこうと思っています。

以上、MTHのWE版リリースの裏事情でした。

Page 1/248: 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のコメント

最近のつぶやき