近況報告たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。動向はもえじら組ブログで。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。Tab(以下、TST)のバージョン4.0をリリースしました。このバージョンではサイドバーパネルの設計を大きく変更し、タブの数が多い場面での動作パフォーマンス(消費メモリー、CPU消費、体感速度)が大幅に向上しました。122.0.1、タブの数536個)で、Firefoxを起動しセッションを復元した直後、TSTも初期化完了した時点でのabout:memoryで計測したTST関連リソースの消費メモリー量は以下の通りとなっていました。自分の主観的には、タブを開いた時やツリー開閉時などのもたつきも軽減され、体感的な快適さは大きく向上した印象があります。タブの数が数千個に及ぶような状況や、Firefoxのプロセスが長期間生存する状況では、メモリー消費量の点でも体感的な速度の点でも、もっと顕著に効果が表れるのではないかと思います。この改善のために、今バージョンでは前の版に比べて、CSSでのカスタマイズやヘルパーアドオンとの互換性が一部損なわれています。既知のヘルパーアドオンについては問題無さそうなことを一通り確認済みですが、僕の把握していない物は動かなくなってるかもしれません。後述しますが、今回のTSTの改善はWaterfoxプロジェクトからの支援によって実現されました。この場を借りて、プロジェクト主催のAlexさんに感謝の言葉を述べさせて頂きます。2023Android版Firefox(開発コード名Fenix)用のアドオンを作る上で必要になる、実機での確認の仕方について。開発でWSL1(Windowsのディスク領域へのアクセスがWSL2より高速なのでWSL2でなくWSL1を敢えて選んでる)上のUbuntuのコマンド操作を多用しているので、その流れでWSL1上のUbuntuに諸ツールを設定できればよかったんだけど、それは使えない。adbでUSB機器を認識させるフェーズで躓く。WSLでやりたければ、WSL2でないといけない模様。今回はWindowsネイティブでやることにした。必要なソフトウェアをインストールする。自分は現時点でのLTSの最新版であった20.10.0LTSを入れた。Files\nodejs\を登録しておく。(Node.jsのインストーラが自動で設定してくれるかもしれない。)web-extのなるべく新しい版。自分はdogfooding用の改造版web-extをソースからインストールしている。ユーザー環境変数→PathにC:\Users\piro\AppData\Roaming\npmを登録しておく。(Node.jsのインストーラが自動で設定してくれるかもしれない。Studioコマンドラインツールのみ。Files\android\sdkに置く。Files\android\sdk\cmdline-tools\binを登録しておく。Platform-Tools)。Files\android\sdkに置く。Files\android\sdk\platform-toolsを登録しておく。adbを動かすのに必要。21.0.1をインストールした。Files\Java\jdk-21(パスは実際にインストールしたJDKのバージョンに依存する)を登録しておく。USBドライバーでよい模様。ドライバーをインストールする。Nightly(Android版):アプリストアからインストールする。必要な物が揃ったら、adbでの接続を試みる。Auto」を選択する。Windows上で「MTP」として端末が認識されていればOK。Android端末のUSBデバッグを有効にする。設定→システム→開発社向けオプション→デバッグ→USBデバッグ)を有効にする。コマンドプロンプト(cmd.exe)を開く。実行してadbのデーモンを起動する。ここまでの手順が成功していれば、接続しているAndroid端末のデバイスIDが以下の要領で列挙される(数字は例示用のダミー)。org.mozilla.fenixを実行する。Firefoxに読み込まれる。2020(1つ前の翻訳記事の末尾には当初、自分の個人的な考えを長々と書いていたのですが、翻訳記事でそういうことをやるのはマナー違反という指摘を頂きました。自分でも確かに、思い入れのあまり熱くなって書きすぎと感じていたので、別記事に分けるついでに増補改訂することにしました。Newsでの反応や、僕の翻訳に寄せられていた反応を見ていると、XULを捨てる判断を間違いと断じる物や、そのような判断をしたMozillaに対する恨み節、あるいは「バカな判断をしやがって、そんなだから俺らパワーユーザーから見捨てられたんだ」みたいな捨て台詞じみた物が結構見られました。それらを見て僕は正直、「これだけ丁寧に書いてあってまだそんな風に思えるってどういうことなの......」と驚くやら呆れるやらしたのですが、自分自身もかつてはそっち側にいた自覚があったので、「なんでそう思うのか」も分からなくはありません。甘い見通し今でも「見境のない拡張機能の仕組み」を支持し続けている人というのは、アドオン開発者にしてもユーザーにしても、ある意味で楽天的というか、性善説を信じているというか、そういう感じなのかなあと思っています。「従来路線でいっても生きていけただろう、少なくとも玄人向けとしてなら生き残れただろう」という意見については、以前の記事で「それでは結局現実に生き残れない」とバッサリ切りましたし、1つ前の記事のコメント欄にも書いてみました。それとは別に「諸々の進歩を継続しつつ、アドオン開発者やユーザーに自己責任での自由を残すのでは駄目なのか?」という主張もあります。Quantum以前はそのような立場でした。この場合の世界観は以下のように要約できるかと思います。アドオン開発者:「自分はFirefoxの変更に振るい落とされることはない、いつまでだって追従し続けられる」と考えている。ユーザー:「アドオン開発者はそのような努力をいつまでも続けてくれる」と考えている。自分の体験と先の記事の内容を踏まえて、今僕が思うのは、「甘い......まったく甘すぎる......」ということです。僕自身、日々壊れていくXULアドオン時代のTSTを維持するのには、ものすごい苦労を要していました。当時はそれが当たり前だと思って麻痺していただけで、実際には狂気の沙汰だったと感じています。TSTをWebExtensions化して以後の感覚では、XULアドオンを書くのなら、実作業時間で1時間あたりN万円くらいのお金を貰って仕事としてやらないと、とてもじゃないけどやってられないです。それくらいに、XULアドオンは維持にコストがかかると言わざるを得ません。「少額ながら寄附を......」とかいうレベルでは収まらない、もはやビジネスの話です。僕自身はライフステージはそれほど変わらないままですが、結婚や子育てなどライフステージの変化の影響で、毎日アドオンのメンテナンスに時間を割くことはできなくなってしまう人も、当然いたでしょう。メンテナンスに膨大なコストを要するアドオンを継続し続けなくてはならないのでは、作者の人生をそれだけに縛り付けることにもなりかねません。作者個人が自分の使う範囲だけで細々メンテナンスし続ける程度なら可能かもしれませんが、それを「第三者が使いやすい」状態でリリースまでするモチベーションはどんどん下がっていく一方でしょう。「見境のない拡張機能」は、もはや「ユーザー」はお断りの世界なぜなら、ものすごく嫌な言い方をしてしまうと、今XULアドオンを一般向けにリリースしても、パッチも提供してくれない・問題の再現条件の特定もしてくれないクレクレ君達からの、「お願いですぅ~直してくださいぃ~ボクにはとてもメンテできましぇ~ん」みたいな声が増えるばっかりで、いいことがないからです。それは言いすぎだろう、パワーユーザー向けならそんなことないのでは、と思う人もいるかもしれませんが、こういう修羅の世界では「敬意を払ってくれるユーザー」や「お金を出してくれるスポンサー」だけいても、結局は搾取構造にしかならない、と僕は考えています。一般的には「OSSにできるコントリビュートはプルリクエストだけではないです。障害報告も立派なコントリビュートです。される結果、実際の結果を明記した良い障害報告をしましょう」ということを僕も言っていますが、「見境のない拡張機能」の世界では、それですら作者側の負担が大きすぎると言わざるを得ません。プルリクエストやコードを実際に提供し合うような、「同じ技術レベルで共に並び戦ってくれる戦友」同士で助け合う以外には成り立たない、そのレベルで戦列に加われない人に関わられて期待されても困る、というのが正直な所です。技術的な事実をいうと、今でもFirefoxでは「見境のない拡張機能の仕組み」と同等のことをやる余地は残っています。false);という内容のファイルを置き、(Firefoxのインストール先)/autoconfig.cfgにゴリゴリ書いていけば、Firefoxのchrome領域上で任意の特権スクリプトを動かすことができます。実際、僕も仕事の上でどーーーーーーしても必要に迫られた場合はそうしていますし、Firefox内部で任意のスクリプトを特権付きで動作させるアドオンだった「userChrome.js」のエコシステムを継続している人達も、この方法を使っているようです。いう使い方をすると、前の記事で散々書かれているような「バージョンアップですぐ動かなくなる」「代替策がない」というドン詰まり状況が頻繁に発生します。見つけたブログ記事やQiitaの記事のコピペで使うだけではとても維持できず、「自分で原因を調べて、自分でコードを直す」ということがどうしたって必要になってきます。誰かが直してくれるのをボケッと待ってるだけでは、今のFirefoxのリリースサイクルにはまず追従できないでしょう。この方法を使っている人達は百も承知だとは思いますが、この方法もいつまで使い続けられるかは分かりません。それでも、「Firefoxのソース自体に手を入れて、Firefoxそのものを独自ビルドする」のは依然として可能です。そこまでやるならChromiumに乗り換える(Chromiumを改造して独自ビルドする)方がいいかもしれません。完全に根性試しの世界ですが、腕力さえあれば乗り切れるのがOSSのいい所です。腹を括って「この方向でも生きていけるんだ」ということを示し続けていく人は、いてもいいとは思います。ESRのスピード(1年ごとのメジャーアップデート)でゆっくり物事が推移しているThunderbirdは、もう少しソフトランディングな方向で進んでいます。APIという仕組みが利用できるようです(これはFirefoxでも提案はされていたのですが、なんやかやで結局実際には使える状態にならなかったと記憶しています)。APIは結局「見境のない拡張機能」と同じことをするための互換レイヤー作りのために使われてしまっているようです。APIでXULオーバーレイ相当のことをしている様子が伺えました。したくなる気持ちは、分からなくもないんですよ。移行ガイドは(ちょろっとしか見てないですが)「こうやってちょっとずつ移行していきましょう」みたいなソフトな書き方をしてるし。一般的に、ハードランディングよりソフトランディングの方がいいとされてますし。前の記事にあった通り、Firefox自体もちょっとずつ段階的に改良されていったわけですし。XULアドオンのWebExtensionsへの移行だけは、TSTのWebExtensions化で僕がやったように、「腹を括ってゼロから作り直す」以外の選択はないと思うんですよ。XULアドオンとWebExtensionsアドオンではパラダイムが違いすぎて、「ちょっとずつ置き換え」なんてできないんですよ。APIの廃止)での完全死だけ。なる前に、いかに早く頭を切り替えて腹を括ってゼロから作り直そうと思い切れるか、それが生死を分けると僕は思ってます。優先順位が違ったから僕は腹を括れたのかもしれないXULアドオンのWebExtensions化では、「WebExtensionsらしいやり方でゼロから作り直して」「APIが足りない部分は、WebExtensionsらしい作法に則ったAPIを提案する」「要望が通らなかったら諦める、無理はしない」というのが最も「正しい」やり方です。自分は一応今のところはそういう方針でやっているつもりですが、改めて考えてみると、僕がこの方針を取れているのは、僕の本心が、多くの「見境のない拡張機能の仕組みに今でもこだわり続けている人達」とは別の所にあったからなのかもしれません。Moonのメンテナーの人のコメントでは、徹底的なカスタマイズを必要としている人のために頑張っているのだ、ということが語られています。それ以外の怨念の籠もったコメントや捨て台詞じみたコメントも、通底しているのは「自分のやりたいようにカスタマイズできることが一番大事、それ以外は二の次」という価値観のように僕には思えました。Webの実現が一番大事、そのために必要な物としてGeckoというレンダリングエンジン実装が継続することが必要、自分のやりたいようにカスタマイズできることは二の次」と考えているようです。Webが失われては元も子もない、という考え方なのだと思います。これはべつに、Mozilla信者だからMozillaの言うことに何でも従ってる、というわけではありません。Webはそれに連なる物だと捉えている、ということです。(そもそもで言えば、僕はWeb標準を素晴らしいと思っていて、そのWeb標準の技術に基づいたXULとCSSて実用的なデスクトップアプリケーションを作れる実例が示されていたから、ということでMozillaに入れ込むようになったのでした。Webなんかどうでもいい、Web技術の標準化とかどうでもいい」なんて言いだしたら、僕はその時の方が深く失望すると思います。この日記の話題が、ここ数年ジェンダーとか差別とか多様性とかそういう話ばっかに偏ってた感じはありましたし、「シス管系女子」でみんとちゃんやその周辺の人物達の様子を描くときにもそれがずっと裏テーマとしてはあったんですが、それらも大きな括りでは近いところにあるんですよね。考えると、僕がやってることはあれもこれもどっかで繋がってるんだなと。しがないラジオのときに自分のやってきたことを線で繋いだ図にしたけど、単にバラバラにそれらがあったわけじゃなく、1つの価値観の多様な表現形だったということなのかなと。W3C信者活動をやめてすっかり軸足がよそに移ってしまったと思ってたけど、判断の根底にはまだまだW3C信者だった頃の何かが残ってたんだなあ、と改めて思い知らされて、感慨深い思いをしたここ数日だったのでした。4.0で公開されている内容の全訳。Qiitaにもクロスポストしています。)要約:Firefoxはかつて、XULとXPCOMに基づく偉大な拡張機能の仕組みを持っていました。この仕組みは長い間私達によく尽くしてくれました。Firefox開発者と拡張機能開発者の両方にとって、メンテナンスコストは増大し続けるばかりでした。ある面では、増大していくコストは、Firefoxをセキュアにしたり、高速化したり、新しい事を試したりするための努力を、少しずつ破壊していきました。別の面では、増大していくコストはアドオン開発者のコミュニティを少しずつ破壊していきました。APIに置き換えるという、難しい決断をしました。この選択のおかげで、Firefox開発者は再び、セキュリティや安全性やスピードを改善するために必要な変更を行えるようになったのです。ここ数日、私はFirefoxのユーザーと会話して、2020年8月のMozillaによるレイオフの結果に関する噂と事実を区別しようとしていました。Quantumへの移行におけるXULベースのアドオンの廃止のことでした。私は非常に驚きました。何年も前に起こったことについて、この選択に感情を害されたと感じている人が、コミュニティにまだいるということにです。誰かがredditで指摘していたとおり、私は、何故XULベースのアドオンの廃止以外に選択の余地が無かったかについて、私達が深いところを説明する機会をまだ持っていなかったということに気付きました。そこで、アドオンとGeckoの内部事情の話に飛び込む準備ができている人向けに、これを機にもう少し詳しい話をしてみようと思います。5日目に予告無しで飛び入り参加のPiroと申します。これらがElectronというChromiumベースの実行環境上で動作するHTML/CSS/JavaScriptで書かれたアプリであるという話を聞いたことはないでしょうか。実際の所は、そういう試み自体は過去から何度もあったのです。Application(.hta)。この記事で語るXULRunnerも、そんな試みの中の一つです。57がリリースされた前後から、アドオンが使えなくなってクソだとか改悪だとかの感想を目にする機会があって、気分が滅入る事が度々ありました。自分自身は、これは必要な事だったと思っていますし、絶望は1年ほど前に嫌というほどし尽くして、今はもう「で、どうやって乗り越えるか」というフェーズに気持ちがすっかり移ってしまっているため、それらの後ろ向きなコメントには正直な所「えっまだそんなこと言ってるの......」という感想を抱いています。そんな後ろ向きな事を言っていないでもっと生産的な事をしましょうよ、と思わずにはおれません。同時に、自分自身も他の分野ではエンドユーザーとして後ろ向きな選択をしている場面は多々あり、同意する部分が無いとも言えません。いうか今絶望している人達と同じような事をつい1年から2年ほど前には自分も言っていた訳で、それを思い起こす度に、し尽くして乗り越えたはずの絶望が何度も蘇ってきて、「何故自分がこんな理不尽な思いをせねばならん(かった)のだ?」と憤りの感情が頭をもたげてくるのは否めません。いう自分の中での混乱を鎮めるために、エンプティ・チェアを2~3個置いて自分の思う所と結論に至るまでの経緯を各立場から辿り直し、考えを整理してみる事にしました。2017この記事の日本語版があります。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になっていないもののうち、自分自身が強く依存していた物は、以下の通りです。セカンドサーチ(入力欄に思いついた検索語句を入力したら、その後で検索エンジンを選択して検索を実行できる、という機能。Searchでそれが可能だが、ブックマークキーワードとして登録した物に対してはそれができないため、ブックマークキーワード用の検索窓を用意する必要があります。)情報化タブ(の中の、タブのサムネイル表示機能。これはFirefox本体のタブに対しては絶対に実現不可能なので、ツリー型タブと組み合わせて使う想定です。)ロケーションバーから新しいタブを開く(技術的な実現可能性は不明ですが、Firefox本体でこれと同等のことを可能にする設定が実装されるのがまだまだ先の事になりそうなので、それまでの当座を凌ぐために挑戦してみたいと思っています。)すみませんが、これら以外の物については、必要としていて作る動機がある方に後継版開発の希望を託したいと思っています。2017このエントリはQiitaとのクロスポストです。57で従来型のアドオンが使えなくなるという事で進めているアドオンのWebExtensions移行作業ですが、ツリー型タブ、マルチプルタブハンドラに続いて、テキストリンクもWebExtensionsに移行しました。移行後の最初のバージョンは6.0.0で、そこから若干の修正を施した最新版は6.0.1となっています。テキストリンクってどんなアドオン?テキストリンクは、テストケースの各種の例のようにWebページ中に普通のテキストとして書かれたURI文字列を、ダブルクリックするだけでリンクのように読み込めるようにするという物です。Add-onsに登録していたアドオンの中では統計上最もユーザー数の多「かった」アドオンです。57リリースが近付いてるけど、テキストリンクの移行はどんな感じ?(大意)」というメールを頂いてしまい、顔を合わせた事のある人から直々にせっつかれてはやらないわけにはいくまい......と、予定を繰り上げて移行に着手したのでした。メールをもらってからリリースまでに要したのがちょうど1週間で、これまでの2例の難航度合いに比べるとびっくりするぐらいあっさり完了した感があります。数を重ねてきてだんだん「WebExtensionsのやり方」に慣れてきたということでしょうか。実を言うと、テキストリンクは1年ちょっと前にWebExtensions移行に挑戦してみた事があったのですが、その時は途中ですっかり投げ出してしまっていたのでした。今回は、この時の成果物をまるっきり無視しての再挑戦での成功と相成りました。1回挫折した物が仕切り直して成功したという典型的な例なので、ここでは「何故前回は失敗し、今回は成功したか」という観点から語ってみようと思います。過去の挑戦時の方針は、端的に言えば「最低限の手直しでの移行」ということになります。テキストリンクは初版が2004年という非常に歴史の古いアドオンで、Firefoxの仕様変更に対し、その都度手直しでの追従を繰り返してきました。最初のバージョンからバージョン4までの間、テキストリンクはすべての処理が特権領域内で完結する仕様でした。RangeなどのWebページの生のDOMに触らないといけない「コンテントプロセス側で実行しなくてはならない処理」を分割するという変更を行いましたが、本質的な設計はずっと変化していなかったと言えます。その延長線上にあったこの時の進め方は、WebExtensions化の作業用にブランチを切って、元のコードを「バックグラウンドスクリプト用」や「コンテントスクリプト用」といったフォルダに移動し、XPCOMやXULに依存していた部分を除去していく形でそれぞれのソースの中身を破壊的に変更していく、というものでした。旧版テキストリンクは、選択範囲(※カーソルも選択範囲の一種なのです)からのURI検出や、ユーザーの操作からタブで開くかウィンドウで開くかといった判断を行う部分など、主要な処理のほとんどがコンテントプロセス側で動作する設計でした。chromeプロセス側は、コンテントプロセスからの指示に従って実際にタブやウィンドウを開くだけという感じです。それとは別にコンテキストメニュー周りの実装がchromeプロセス側にあり、こちらはユーザーがコンテキストメニューを開いたタイミングで処理を開始して、コンテントプロセスに処理を依頼してはその結果を受け取って......という事を繰り返すようになっていました。これをそっくりそのままWebExtensionsに持っていこうとすると、主要な処理はすべてコンテントスクリプトに移植することになります。WebExtensionsではコンテントスクリプトでできる事の範囲が大きく制限されています。そこで「コンテントスクリプトではこの機能が動かないのでバックグラウンドスクリプトに移す」という事をその都度やっていると、キリが無い上に、場当たり的な切り貼りの繰り返しでコードはどんどんカオスになっていきます。従来のアドオンでの「コンテントプロセスで動作するスクリプト」とWebExtensionsの「コンテントスクリプト」には大きな違いがあります。それは、従来のコンテントプロセス用スクリプトは「1つのプロセスにつき1つのインスタンスが作られる」のに対し、コンテントスクリプトはタブ内のフレームの数だけインスタンスが作られるという点です。プロセスの数だけインスタンスが増えるという時点でいかがな物かという感じですが、フレームの数だけ増えるとなると、さすがに主要な機能をそこで動かすのは非効率的です。このほか、コンテキストメニュー項目の動的な更新についての知見がなかったために、選択範囲からのURI文字列の検出結果を受けてメニュー項目を制御するやり方が分からなかった事や、XPCOMとXULがあることを前提として書かれたコードを総点検してXPCOMフリーに書き直すにあたって、代替手段が見つからなかった処理がいくつかあった(WebExtensionsでも最新のWeb技術でも機能が提供されていない部分があった)事など、数々の困難に嫌気がさし、また「シス管系女子」の連載の〆切が迫っていた事も相まって、道半ばで移行作業を放棄してしまったのでした。57でも使えるようにする』ということは不可能」と書きましたが、この時の失敗はまさにこれが原因であったと総括できます。言うなら、従来バージョンから持ち越した既存の実装という大荷物を背負って道を歩いていて、道のど真ん中にある車止めに荷物が引っかかってしまい先に進めず、「こんなもんどけてやる!」とばかりに軽く考えて邪魔な車止めを取り除こうとして、でも地面にしっかりコンクリートで固定されていて蹴っても叩いても動きやしなくて、その埒の明かなさと背負っている荷物の重みとのダブルパンチで心が折れてしまった......という感じでしょうか。今回の再挑戦では、TSTやMTHのWebExtensions移行で成功をもたらした「旧版の動作をリファレンスとして、同等のユーザー体験をもたらす新しいWebExtensionsベースのアドオンを新規に開発する(つもりで臨む)」というやり方を取りました。具体的には以下の順で作業を進めました。「選択範囲とその前後のテキストの抽出」といった必須の要素技術をコンテントスクリプトで実装する。文字列からのURI文字列の検出という、純粋にJavaScriptのコードだけで完結できるモジュールを、従来版から選択的にバックグラウンドスクリプトとして移植する。ダブルクリック操作をトリガーとして、コンテントスクリプトで可視状態のテキストを抽出し、それをバックグラウンドスクリプトに送ってURIを検出させて開く、という形で最も基本的な機能を実装する。開いた後のURI文字列を選択範囲にする、という挙動を実装する。選択範囲の変化をトリガーとして、コンテントスクリプトで可視状態のテキストを抽出し、それを材料にバックグラウンドスクリプトでURI文字列の検出とコンテキストメニューの更新を行う、という一連の事を実装する。テキスト編集領域内での動作に対応する。この説明にも表れている通り、今バージョンのほとんどのコードはスクラッチで書いた物で、旧版からコードを引き継いだのは「文字列の中から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はずいぶん前に立てたのですが、今に至るまで具体的な実装はまだなされていないままなので、諦めて自力で実装してみました。TraversalのTreeWalkerを使って泥臭い事をやっています。TreeWalkerはnextNode()とpreviousNode()を使うとDOMツリー上の全ノードをツリー構造を無視して文書順で参照するイテレータとして使えるので、CSSのセレクタやXPathでは条件にできない生のDOMの情報を条件とした絞り込みを行っています。NodeFilter.SHOW_TEXTでざっくりテキストノードと要素ノードに絞り込んで、さらにそのノードの祖先に非表示の要素ノードがないかをwindow.getComputedStyle()で順にチェックして、確かに可視状態だと確認できたノードだけを取り出しています。その後、テキストノードであればnodeVaueを、要素ノードでdisplay:inline以外の物があれば適宜改行文字を「表示されているテキスト」として取り出しています。以上のようなやり方で、一応実用に耐える精度で「見た目通りのテキストを抽出する」を実現できたのですが、想像の及んでいなかったエッジケースなどで想定外の結果になる可能性は依然としてありそうな気がしています。nsDocumentEncoder相当の機能が実現されるまでは、まだまだ悩みは尽きない感じです。与えられた文字列からURIを検出する処理は、今回の移行で唯一、旧バージョンからほとんどそのままコードを引き継いだ箇所です。この処理は、データ量にして最終的に完成したWebExtensions版テキストリンクの全体の1/3を占める巨大なモジュールなのですが、やっている事は至って単純で、「相対パスも許容するのか?」「全角英数字も許容するのか?」等の条件に基づいてURIらしき文字列にマッチする正規表現を組み立てるだけの物です。相対パスを絶対パスに解決する部分などでXPCOMコンポーネントの機能を使っている部分はありましたが、全体の中ではそういった箇所はごく一部に限られており、ほとんどは単純な文字列処理だけで構成されていました。自動テストを容易にするためにモジュール間の結合を弱めていた結果、機能を使うのに必要なパラメータはほとんどすべて外部から与えられるようになっており、旧テキストリンクの実装の中ではここだけ突出して浮いているようにも感じられるほどでした。いう事情があったため、このモジュールについてはほとんど苦労する事なくほぼそのままの形でWebExtensions版に組み込む事ができました。ダブルクリック操作で開いた後のURI文字列を選択範囲にする旧版テキストリンクでコンテントプロセス側に大部分の処理があったのは、「URI文字列として検出した部分を新しい選択範囲にする」という挙動を実現したかったからでした。これをやるには、Rangeを対象に文字列を検索してヒット箇所をRangeで返すというAPIが不可欠です。旧版ではnsFindというXPCOMコンポーネント(@mozilla.org/embedcomp/rangefind;1)を使ってこれを実現していましたが、当然ですがこれはWebExtensionsでは使えません。W3Cで提案されていたらしいRangeFinderというAPIが実装されていればそれで代替できたのですが、こちらは残念ながら未実装です。いう具合で代わりの手段がなかったという事が、過去の移行失敗時に移行を断念した理由の1つでもありました。57ではRangeFinder的な事ができるようになっています。今回はこれを使ってみる事にしました。Rangeの取り扱いです。Rangeの情報を双方の間で受け渡すかが問題となります。この事について何かヒントはないかとbrowser.find.find()の説明を読み進めてみた所、まさにこの通りの事をやる例が載っていました。このAPIはrangeDataという形式で検索結果のRangeをシリアライズして返すようになっており、その情報に基づいてコンテントスクリプト側でRangeを組み立てれば良いようです。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.menus(browser.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を立ててそれが解決されるのを待つ、という事になっていたでしょうが、今回は「完全でなくても今できる範囲でできる事だけをする」という方針だったため、この点はリリースをブロックする要因にはなりませんでした。まとめはじめからやり直したい症候群や、それに類する言葉を見かける事があります。プログラミングの世界においても、メジャー製品の大規模アップデートで「ここらで一区切り付けて、最初から作り直してもっとスッキリした設計にしよう」みたいな事をやろうとして、収拾がつかなくなり失敗に終わってしまい、最終的に旧版からの小規模な修正のみに留めるしかなかった......みたいな事はたまにあります。いった事例をいくつか見聞きして、また自分自身もそういった無謀な挑戦をしようとして挫折するという経験を何度かした結果、「スクラップ&ビルドですべてが上手くいくようになるというのは甘い幻想で、実際には地道な改良をコツコツ続けていくしか無い」という教訓が、自分の中である種の呪いのように刻み込まれていました。実際には、その「教訓」に従って進めようとした前回の移行は失敗に終わり、大部分でスクラッチに近いレベルでの作り直しとなった今回の移行の方が成功するという皮肉な結果となりました。今回スクラッチせず引き継いだ部分まで作り直していたら、この移行は再び失敗に終わっていた事でしょう。今まさに自分が直面している問題がどちらのケースなのか、を適切に見極めるのは難しい事です。考える事を放棄して当て推量で雑な判断をすれば、痛い目を見ることになるのは自分自身です。確実な成功に繋げるためには、そこで使おうとしている・使わなければならない技術の特性と限界、現行技術とのギャップの大きさ、取り組んでいる問題の複雑さなど、様々な要因を考慮に入れた総合的な判断を、プログラム全体やモジュール単位で下す必要がある、という当たり前といえば当たり前の事を、自分は今回の移行を通じて実感した次第です。