オープンなWeb標準で定義された機能はAPIからは削除する。ServiceWorkerベースのAPIへの更新。いわゆるメインスレッドとして走る処理のための物。以上、翻訳とメモの中間みたいな物でした。280blockerで詳しく解説されている。コンテンツのデータへのアクセスについて、<all_urls>を廃止して、コンテンツに触れたければ必ずactiveTabの権限の範囲でできる事だけに制限するというのは、かなり息苦しくなるなあという感じがある。複数選択されたタブのそれぞれについてコンテンツの内容を収集してきてクリップボードにコピーする、みたいな事はできなくなるという事だろうか?Promiseベースにするというのは、FirefoxのWebExtensionsが既にそうなっているし、ChromeのAPIをそのスタイルに合わせるためのPolyfillも既に広く使われているようなので、妥当だと思う。Chrome開発チームが思う所の「こうあるべき」という思想を前面に押し出した案だなと感じた。Firefoxの拡張機能がXULとXPCOMでなんでもできたのに対して、無害そう・使用頻度が高そうなニーズに応える機能だけ取捨選択してChromeの拡張機能APIとしてまとめたのが、今からほぼ10年前。10年を経てさらに取捨選択を進めると同時に、新たに明らかになってきたリスクを改めて潰し直すというのが、マニフェストV3でやりたい事なんだろう。Googleのやり方を強硬的で独善的だと非難する向きもあるようだけど、それは今に始まった事じゃない「Googleの社風」なんだと思う。Googleが認めるやり方での広告ブロック以外は認められないという形に結果的になっているのは事実のようだけれど、巷で騒がれている「広告ブロックを禁止するための陰謀だ」みたいな見方は深読みしすぎだと思う。Googleの人達はそこまで考えてなくて、彼らはきっと、性能劣化がとにかく嫌で、それに繋がりうる物をなくしたら結果的にこうなった、という事なんだと僕は思ってる。文句の付け所があるわけ?(キョトンとした顔で)」くらいの事なんじゃないかな。ブラウザは最低限の機能だけでええやん、常時表示するカスタムUIなんて無駄なだけやん(キョトンとした顔で)」みたいな感じなんじゃないのかなと僕は認識してる。僕はツリー型タブを「脳内ワーキングメモリが極めて貧弱な自分でも、Webのブラウズ履歴を視覚的にその場に残して常に全体をざっと眺められるようにできれば、ワーキングメモリの小ささを補って人並みの仕事ができる」という使い方をしてるけれども、優秀なGoogleの人達は(※やっかみ)ワーキングメモリが広大で、そんな風にツールで補う必要がきっと無いから、それで必要性を認めないんだろう、と僕は思ってる。速度以外のセキュリティについても、セキュリティが担保されるなら利便性はどうでもいいというのが彼らの本音であるように思う。いや、セキュリティ第一であるべきというのは一般的にもちろん正しいし、一般ユーザー向けに「セキュリティより自由度を」なんて言ってる人がもしいたら、アホだとは思う。「よく分かってる人・開発者向けにだけ裏道を残しておけばいい」とは言っても、大抵の人は自分が何をしてるか分からないまま自分の足を撃ち抜きがちで、しかもその事に気付いてすらいないものだから、そういう「パワーユーザー向けにだけ解放」が絵空事でしかないというのも分かる。これって何かに似てるなと思ったら、あれだ、アメリカの銃規制に似てるんだ。アメリカは銃を所持する事が自分の自由を守る事とセットだという建国の精神だから、いくら安全のためとはいっても銃を完全に社会からなくそうとすると強い反発が起こる、っていう。銃乱射事件が起こる度に出てくる「全米ライフル協会『(被害者が)銃を持っていればこんな事件は防げた』」というジョークを見る度に「アホやなあ」と僕は思っていたけれど、それを笑っていた僕自身もまた、リスクに目を瞑って、危険な武器を自分が手にできる自由を声高に叫んでいた人の1人だったのだな、と。コンテキストメニューのコンテキストのオーバーライドのように「安全」とのバランスを取りながら自由度を増す事に寛容な姿勢が垣間見えていて、方向性としてはまだそういう自由度を尊重してくれているように思えるので、それで僕はFirefoxを使い続けてるんだな。自分が独り立ちできた事の根底にあった「建国の精神」とガッチリ結びついてるから、僕は自由度をなるべく捨てたくないんだな。いうことを、Chromeの拡張機能マニフェストV3のいざこざを見ていて改めて意識させられた。いう感じでなんかこうセンスというか目指すところが合わないので、僕は今後も当面Chromeに移ることは無いかなと思っているのでした。「じゃあサイドバーAPI付きのChromiumベースのブラウザならどうなんよ、Operaとか」っていう疑問も当然浮かぶわけだけれど、ベースになってる物の設計思想が決定的に自分とマッチしてない(と僕は思ってる)以上、その上に組み上げられた物も自分にはマッチしないんじゃないかなあという見方をしてしまうし、それにChromeチームの意向で梯子を外されてOperaも他のChromiumベースの製品もみんなおじゃんになっちゃいましたみたいな未来もあるんじゃないかくらいに悲観的に考えてるので、やっぱりその路線も無しというのが今の自分の考えです。2019ただの苦労話です。ツリー型タブをWebExtensionsに移行してからこっち、ずーーーーーっと悩まされてる事がある。それは、TSTのサイドバー上のタブとFirefox本体のタブの並び順が一致しなくなる事があるという問題。いう事が起こるのかというと、色々な背景があるのですが......当初はタブの並び順の制御については、WebExtensionsのAPI経由でタブを移動した後、それがtabs.onMovedで通知されるのを待って、通知された情報に基づいてツリーを更新するということを考えていた。実際にそうしてみると、まあ遅いこと遅いこと。Firefoxとアドオンのプロセスが別だからなのかそれとも別の理由があるのか、イベントがTSTに通知されてくる(結果が返ってくる)までにかなりのタイムラグがある事が分かった。そこで、WebExtensionsのAPI経由でFirefoxのタブを並べ替えるのと同時に、別途runtime.sendMessage()でタブの移動を行う指示をバックグラウンドページとサイドバーの間でやり取りして、イベントの通知を待たずに先にツリーだけ更新するようにした。タブを一つ一つゆっくり操作している場面(僕の普段の使い方)ではこれで問題無かったんですが、このやり方には、リンクからタブをまとめて開くとかブックマークレットを使うとかしてTSTのあずかり知らぬ所で複数のタブが一気に開かれた場合に、TSTのツリーとFirefoxのタブの順番の同期が崩れやすくなってしまうという、大きな大きな副作用がありました。tabs.onCreatedやtabs.onMovedなどのイベントがそれぞれ非同期で送られてくる。そのリスナの中で非同期に、タブを親タブにattachしたり、タブを並べ替えたりしている。している間に新しいタブが開かれたり移動されたりする事もある。それどころか、処理中だったタブが閉じられてしまう事もある。(開かれたタブを自動的に別のコンテナで開き直す、みたいなアドオンがあると起こる)こういった感じでもうシッチャカメッチャカで、こんな状況の中でタブの並び順やら存在確認やらを厳密に把握して破綻の無いように管理するなんて、どだい無理なわけです......全部のイベントをキューに積んでシーケンシャルに処理していけば安定はするだろうけど、そうしたら死ぬほど遅くなるだろうし。いまですら遅い遅いと言われているのに、これ以上遅くなったらどうなることか、考えるだけでもそら恐ろしい。それでも何もしないわけにはいかないので、とりあえず、挿入中のタブがある時は最低限IDが確定するまでは次のタブを挿入する処理を止めるとかの、焼け石に水のような細かい対策をちまちま重ねていました。最近になって「ちまちまやっててももうどうしようもない」という境地にようやく至りまして、とりあえずタブの並び順の制御についてだけは、まずruntime.sendMessage()でTSTのツリーだけ並べ替える。これはリアルタイムに行う。tabs.move()の呼び出しは、ある程度キューを溜めておいて後でまとめて行う。その時は、TSTのツリー上のタブの並び順をマスターとして、それに合わせるようにFirefoxのタブを並べ替えるという事を徹底する。いう事をやるようにしました。この方向で愚直にやると、全部のタブの並び順をチェックするような処理が頻繁に実行される事になって、タブが何千とか開かれてる環境ではますます遅くなってしまうと容易に予想できるわけで。やだ......どうやっても詰みじゃん......安定性を突き詰めればクッソ遅くなっていって、体感速度の向上を意識すれば安定性が犠牲になって......こんなことならもっと早くに現行の設計を諦めてReactDOMとかの仮想DOMベースに作り直しとけば良かった。あれなら確か、JSON形式のマスターデータを雑に編集してそれをビューに随時渡すだけで、ビュー側は現時点のDOMツリーから期待されるDOMツリーの状態への最短の編集距離を求めて、最小限の変更で高速にDOMツリーを更新してくれるっていうじゃないですか......という所まで考えて、はたと気が付きました。タブの並べ替えも最小限の変更だけで済むようにすればいいんじゃん、と。実はこれにはアテがありました。昔にアドオンの自動テストをやりたくてUnitTest.XUL略してUxUというアドオンを会社で作っていたのですが、テストケース中のアサーションの期待値と実測値の差分をdiff形式で出力するために、当時すとうさんがPythonのdiffの実装をJavaScriptに移植した物を入れて下さっていて、これが使えそうだったのです。Diffのテキスト形式を出力するだけの実装だったのですが、僕がTortoiseSVNやTortoiseGitで見慣れていたカラフルな差分表示をUxUでもやりたくなって、HTMLのタグを含めた出力を組み立てるような処理を自分で書いた事があり、その時に、diffの実装は内部的には行単位ではなく1文字単位で違いを検出できているという事を知ったのでした。いうことは、それを応用すれば「元のDOMツリーからこの要素だけ移動すれば期待したDOMツリーになる」「元の並び順のタブからこのタブだけ移動すれば期待したタブの並び順になる」というような必要最小限の編集手順を特定するのにも使えるはずです。いうことで、実装をそのままTSTに持ってきて、いまどきのES2017っぽいスタイルに直した上で、tabs.move()でのFirefoxのタブの並べ替えとDOMツリーの編集をそれぞれなるべく少ない手順でやるようにしてみました。コードを見ると分かりますが、実際に使っているのはdiffの実装の中のSequenceMatcherというコア機能だけです。本来は文字列を1文字単位で比較するための物ですが、実装的にはArrayを渡せばArrayの要素単位で比較してくれそうな雰囲気だったので、文字列の代わりにタブのIDを入れた配列を渡してみた所、いい感じにequal(変更無し)、delete(削除)、insert(追加)、replace(置き換え)という形で最小の編集手順を導き出してくれました。タブの並べ替えでは「タブがなくなる」という事は前提としてあり得ないため、insertとreplaceのうち挿入箇所にあたる部分だけを編集情報として使っています。これのお陰で、いままでは無駄に何度もタブを行ったり来たりさせていたのが、場合によってははるかに高速に並べ替えが完了するようになってくれました。レガシーなやり方を捨ててモダンな仮想DOMへの移行のきっかけになるはずが、何だかんだで結局、部分的にとはいえ似たような事を自前でやるようにしてしまったということで、なんだかなあ......と頭を抱えているのが「今ココ」ということで、特にオチはありません。Qiitaという訳が既に出ていたので激しく今更なのですが、自分でもえっちらおっちら訳してみたので、せっかくだから置いておきます。さようなら、EdgeHTMLMicrosoftは公式に、インターネット用の独立した共有のプラットフォームの維持を断念しました。Chromiumの採用により、Microsoftはオンライン生活の支配権をより一層Googleに譲り渡します。これは実利と無関係の情緒的な話のように聞こえるかもしれませんが、そうではありません。Quantum――は、私達がオンラインで何をできるかの大部分を実質的に決定づける開発者向けのソフトウェア部品です。それらは、私達が消費者として目にする物、私達がコンテンツを見る時の安全性、Webサイトやサービスが私達に対して行う事(訳注:位置情報の取得、デスクトップ通知の表示、などの事か)をどれだけ制御できるかといった、基本的な能力を決定づけます。Microsoftの決定は、私達ユーザー個々人に何ができるかという事をベンダ側で一方的に決定してしまえる能力を、Googleに対してより多く与えるものです。ビジネスの観点から、Microsoftの決定は充分に納得のいく物と言えます。Googleは私達のオンライン生活の基盤のコントロールをほぼ完全に握っており、この分野でGoogleに競合し続ける事はビジネス上有益ではないでしょう。私達に一度は与えられた自由と選択肢の提供を諦めたとしても、Microsoftの株主達の利益は保たれるでしょう。Googleは非常に多才なスタッフを雇用しユニークな資産を独占する、すさまじい競合相手です。個人的な権利の観点から、基本的なオンラインの基盤のコントロールをたった1つの企業に譲り渡す事は、恐ろしい事です。これが、なぜMozillaが存在するかという理由です。私達は、ビジネス上の好機があるからGoogleに競合するのではありません。インターネットとオンライン生活の健全性というものが、競争と選択に依存するからです。それらは、一般の消費者自身がより良い物を求めて行動を起こす事を自己決定できる、という事に依存しています。Googleをより強力にする事は、様々な面で危険です。その答えの大部分は、サービス・Webサイトを作ろうとするWeb開発者や業界・企業が何をするかに依存します。Chromiumのような1つの製品が充分なマーケットシェアを持っているなら、Web開発者や業界・企業にとって、サービスやWebサイトがChromium以外のブラウザで動作するかどうか気にかけないでいる事が容易になるでしょう。それは、Firefoxがリリースされるより以前の、Microsoftが2000年代初頭にブラウザのシェアで寡占状態にあった時に起こった事です。それはまた起こるでしょう。今日こんにちのオンライン生活で何が起こっているか気になるのであれば、Firefoxにも注意を払って下さい。Firefoxは18ヶ月前よりも劇的に改善されています――Firefoxは速度とパフォーマンスの点で再び引けを取らなくなっています。1週間ほど既定のブラウザとしてFirefoxを試してみて下さい、そしてそれから判断して下さい。Firefoxを強くする事がオンライン生活の問題のすべてを解決する訳ではありません――ブラウザは様々な要素の中のごく一部に過ぎません。Firefoxがあなたにとって良い製品だと気付いたら、あなたがFirefoxを使う事がFirefoxを強くします。あなたがFirefoxを使う事は、Web開発者と業界・企業がChrome以外の事を考える事を手助けします。それはFirefoxとMozillaがインターネット上の生活をより良くする手助けとなります――より多くの選択肢、より多くのセキュリティの選択肢、より多くの競争によって。参考までに、本件についての日本語で書かれた記事へのリンクもいくつか示しておきます。EdgeがChromiumベースにすると公式に発表。Calendar要にXULRunnerの話を書いた直後に、Gecko自体ロストテクノロジーになっちゃうねこれっていう感じの発表があったというのは、何とも皮肉な話です。5日目に予告無しで飛び入り参加のPiroと申します。これらがElectronというChromiumベースの実行環境上で動作するHTML/CSS/JavaScriptで書かれたアプリであるという話を聞いたことはないでしょうか。実際の所は、そういう試み自体は過去から何度もあったのです。Application(.hta)。この記事で語るXULRunnerも、そんな試みの中の一つです。2018このエントリの日本語版はこちらにあります。