Latest topics 近況報告

Chrome Extensionsのマニフェストのバージョン3とアメリカの銃規制 - Jan 29, 2019

ちょっと前に話題になったChromeの拡張機能のAPIの新バージョンの案の概要を把握するために、変更点のまとめの部分だけを読んでみた。全訳するのも大変なので、適宜つまみながら。

---

動機

APIや権限の仕組みに対して大規模な変更を行う物なので、マニフェストバージョンを3に上げる。拡張機能が実際に使用しているAPIや権限の中には、パフォーマンス、セキュリティ、プライバシー、および人間工学的な観点から、ユーザー体験を低下させている物が多数ある。新しいマニフェストバージョンではそういった負の影響を与える要素を一掃し、新しいAPIや機能だけを使えるようにする予定である。拡張機能の作者達に向け、移行を容易にするための明確な手順と、新基準に拡張機能を移行するに足る追加のインセンティブを用意するつもりである。

• 目標: マニフェストV3では、安全・高速・プライバシーに配慮された拡張機能を容易に開発できるようにし、一方で、危険・低速・プライバシー情報の漏洩に繋がる拡張機能を開発しにくいようにする。拡張機能の品質を高め、ユーザーに積極的に勧めやすいような物にする。
• セキュリティ: マニフェストV3に基づいて開発される拡張機能は、外部からの攻撃（その拡張機能を狙ってXSSを仕掛けてくるような悪意あるWebサイトなどからの攻撃）と、内部からの攻撃（悪意ある拡張機能）の両方に対して、より強力なセキュリティ機構を保証するのが望ましい。ユーザーは安心して拡張機能をインストールできることが望ましく、そのためには、その拡張機能が重大な損害をもたらし得ない事を保証する必要がある。その結果、自動および手動でのレビューをより容易にする。
• プライバシー: ユーザーは拡張機能に対してより広範な制御権を持つことが望ましい。ユーザーは各拡張機能に対して、どの個人情報の使用を許可するかを制御できることが望ましい。
• 性能: マニフェストV3に基づいて開発された拡張機能は、より高速になる事が望ましい。長時間動作するバックグラウンドプロセスは禁止されるべきである。APIは高速・効率的である事が保証されている必要があり、性能を劣化させるような誤った使い方がしにくいようなAPI設計となっていることが望ましい。

変更の概要

優先度1（最高）

• バックグラウンドプロセスについては、イベントベースの永続的なバックグラウンドページから、Service Workersへ移行する。
• コンテンツのデータへのアクセスの制限については、activeTabスタイルの、実行時にのみアクセスが許可されるモデルへ移行する。
• リモートに置かれたコードについては、直接の実行を禁止する。
• クロスオリジンの通信は、コンテントスクリプトはWebページのスクリプトと同じルールに基づくこととして、拡張機能のページは過去にアクセスしたことがあるサイトに対してはクロスオリジンの通信を可能とする。
• ホスト単位での権限の指定は、API自体の権限を列挙する permissions 配下でまとめて指定していたのを host_permissions に分離する。
• PromiseベースのAPIとする。

優先度2（高い）

• Webからアクセスできるリソースについては、拡張機能の実行コンテキストから切り離された安全な領域に登録されたリソースを、動的に生成されるURLで読み込む形とする。
• 動的なコンテントスクリプトについては、それに特化した権限の仕組みを設ける。

APIの変更

• webRequest は、リソースの読み込みをブロックする使い方を制限する。
• 代わりに、読み込みブロックのための宣言型の新しい仕組みとして declarativeNetRequest を設ける。
• ツールバーの動作とページでの動作は、browserAction と pageAction を単一の action APIに統合する。
• chrome://favicon に関する権限をchrome.favicon APIに移す。
• tabs, pageCapture, tabCaptureおよび　desktopCaptureを単一のcapture APIに集約する。
• オープンなWeb標準で定義された機能はAPIからは削除する。
• ServiceWorkerベースのAPIへの更新。特に、いわゆるメインスレッドとして走る処理のための物。
• 公に非推奨・廃止予定とされていたAPIの廃止・削除
• その他、性能や利便性、人間工学的な観点での細かい修正。

---

以上、翻訳とメモの中間みたいな物でした。

この中で特に webRequest と declarativeNetRequest に関わる部分は、chromeの機能拡張の変更について | 280blockerで詳しく解説されている。

コンテンツのデータへのアクセスについて、<all_urls>を廃止して、コンテンツに触れたければ必ずactiveTabの権限の範囲でできる事だけに制限するというのは、かなり息苦しくなるなあという感じがある。例えば複数選択されたタブのそれぞれについてコンテンツの内容を収集してきてクリップボードにコピーする、みたいな事はできなくなるという事だろうか？

Promiseベースにするというのは、FirefoxのWebExtensionsが既にそうなっているし、ChromeのAPIをそのスタイルに合わせるためのPolyfillも既に広く使われているようなので、妥当だと思う。

　

総じて、Chrome開発チームが思う所の「こうあるべき」という思想を前面に押し出した案だなと感じた。元々、Firefoxの拡張機能がXULとXPCOMでなんでもできたのに対して、無害そう・使用頻度が高そうなニーズに応える機能だけ取捨選択してChromeの拡張機能APIとしてまとめたのが、今からほぼ10年前。10年を経てさらに取捨選択を進めると同時に、新たに明らかになってきたリスクを改めて潰し直すというのが、マニフェストV3でやりたい事なんだろう。Googleのやり方を強硬的で独善的だと非難する向きもあるようだけど、それは今に始まった事じゃない「Googleの社風」なんだと思う。

Googleが認めるやり方での広告ブロック以外は認められないという形に結果的になっているのは事実のようだけれど、巷で騒がれている「広告ブロックを禁止するための陰謀だ」みたいな見方は深読みしすぎだと思う。多分Googleの人達はそこまで考えてなくて、彼らはきっと、性能劣化がとにかく嫌で、それに繋がりうる物をなくしたら結果的にこうなった、という事なんだと僕は思ってる。やっかみ混じりで悪意に取ったとしても、せいぜい「は？ 俺らが熟慮して『これで充分じゃん』って考えた物なんだから、これで完璧でしょ？ 文句の付け所があるわけ？（キョトンとした顔で）」くらいの事なんじゃないかな。

サイドバーAPIを頑なに付けないのも、要はそういう「は？ そんなもんいらんやろ？ ブラウザは最低限の機能だけでええやん、常時表示するカスタムUIなんて無駄なだけやん（キョトンとした顔で）」みたいな感じなんじゃないのかなと僕は認識してる。僕はツリー型タブを「脳内ワーキングメモリが極めて貧弱な自分でも、Webのブラウズ履歴を視覚的にその場に残して常に全体をざっと眺められるようにできれば、ワーキングメモリの小ささを補って人並みの仕事ができる」という使い方をしてるけれども、優秀なGoogleの人達は（※やっかみ）ワーキングメモリが広大で、そんな風にツールで補う必要がきっと無いから、それで必要性を認めないんだろう、と僕は思ってる。

　

速度以外のセキュリティについても、セキュリティが担保されるなら利便性はどうでもいいというのが彼らの本音であるように思う。いや、セキュリティ第一であるべきというのは一般的にもちろん正しいし、一般ユーザー向けに「セキュリティより自由度を」なんて言ってる人がもしいたら、アホだとは思う。「よく分かってる人・開発者向けにだけ裏道を残しておけばいい」とは言っても、大抵の人は自分が何をしてるか分からないまま自分の足を撃ち抜きがちで、しかもその事に気付いてすらいないものだから、そういう「パワーユーザー向けにだけ解放」が絵空事でしかないというのも分かる。

これって何かに似てるなと思ったら、あれだ、アメリカの銃規制に似てるんだ。アメリカは銃を所持する事が自分の自由を守る事とセットだという建国の精神だから、いくら安全のためとはいっても銃を完全に社会からなくそうとすると強い反発が起こる、っていう。

銃乱射事件が起こる度に出てくる「全米ライフル協会『（被害者が）銃を持っていればこんな事件は防げた』」というジョークを見る度に「アホやなあ」と僕は思っていたけれど、それを笑っていた僕自身もまた、リスクに目を瞑って、危険な武器を自分が手にできる自由を声高に叫んでいた人の1人だったのだな、と。自分自身が「ただのユーザー」から「自分の使う道具を自分で作り替えられる開発者」にステップアップできる余地があったから（他にも理由はあったけど）、僕はMozillaを使っていたし、「Chromeと同じになってしまった」「Mozillaはアドオンを殺した」なんて言われた後の今でもSuccessor Tabs APIや コンテキストメニューのコンテキストのオーバーライドのように「安全」とのバランスを取りながら自由度を増す事に寛容な姿勢が垣間見えていて、方向性としてはまだそういう自由度を尊重してくれているように思えるので、それで僕はFirefoxを使い続けてるんだな。自分が独り立ちできた事の根底にあった「建国の精神」とガッチリ結びついてるから、僕は自由度をなるべく捨てたくないんだな。ということを、Chromeの拡張機能マニフェストV3のいざこざを見ていて改めて意識させられた。

　

そういう感じでなんかこうセンスというか目指すところが合わないので、僕は今後も当面Chromeに移ることは無いかなと思っているのでした。

「じゃあサイドバーAPI付きのChromiumベースのブラウザならどうなんよ、Operaとか」っていう疑問も当然浮かぶわけだけれど、ベースになってる物の設計思想が決定的に自分とマッチしてない（と僕は思ってる）以上、その上に組み上げられた物も自分にはマッチしないんじゃないかなあという見方をしてしまうし、それにChromeチームの意向で梯子を外されてOperaも他のChromiumベースの製品もみんなおじゃんになっちゃいましたみたいな未来もあるんじゃないかくらいに悲観的に考えてるので、やっぱりその路線も無しというのが今の自分の考えです。

ツリー型タブでタブの並び順が壊れる問題との格闘 - Jan 12, 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に移植した物を入れて下さっていて、これが使えそうだったのです。

これは元々はUnified 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への移行のきっかけになるはずが、何だかんだで結局、部分的にとはいえ似たような事を自前でやるようにしてしまったということで、なんだかなあ……と頭を抱えているのが「今ココ」ということで、特にオチはありません。

（まあ、仮に仮想DOMに全面的に設計を刷新したとしても、tabs.move()でFirefoxのタブの並び順を制御する部分はきっとそのまま使い続ける事ができそうではあるので、今回やった事も完全に無駄というわけではないかな、と……）

Goodbye, EdgeHTML（私的日本語訳） - Dec 10, 2018

MicrosoftがEdgeの次期バージョンをChromiumベースにすると正式に発表した事を受けて発表されたMozillaの声明文について、自分が風邪やら何やらでゲンナリしている間にGoodbye, EdgeHTML (日本語訳) - Qiitaという訳が既に出ていたので激しく今更なのですが、自分でもえっちらおっちら訳してみたので、せっかくだから置いておきます。

---

さようなら、EdgeHTML

Microsoftは公式に、インターネット用の独立した共有のプラットフォームの維持を断念しました。Chromiumの採用により、Microsoftはオンライン生活の支配権をより一層Googleに譲り渡します。

これは実利と無関係の情緒的な話のように聞こえるかもしれませんが、そうではありません。「ブラウザエンジン」――GoogleのChromiumとMozillaのGecko Quantum――は、私達がオンラインで何をできるかの大部分を実質的に決定づける開発者向けのソフトウェア部品です。それらは、私達が消費者として目にする物、私達がコンテンツを見る時の安全性、Webサイトやサービスが私達に対して行う事（訳注：位置情報の取得、デスクトップ通知の表示、などの事か）をどれだけ制御できるかといった、基本的な能力を決定づけます。Microsoftの決定は、私達ユーザー個々人に何ができるかという事をベンダ側で一方的に決定してしまえる能力を、Googleに対してより多く与えるものです。

ビジネスの観点から、Microsoftの決定は充分に納得のいく物と言えます。Googleは私達のオンライン生活の基盤のコントロールをほぼ完全に握っており、この分野でGoogleに競合し続ける事はビジネス上有益ではないでしょう。私達に一度は与えられた自由と選択肢の提供を諦めたとしても、Microsoftの株主達の利益は保たれるでしょう。Googleは非常に多才なスタッフを雇用しユニークな資産を独占する、すさまじい競合相手です。Googleの検索・広告・スマートフォン・そしてデータ収集における横断的な支配力は、彼ら以外の残りのプレイヤーに対して大きく傾斜した、Google有利のプレイフィールドをもたらしています。

社会的、市民的、そして個人的な権利の観点から、基本的なオンラインの基盤のコントロールをたった1つの企業に譲り渡す事は、恐ろしい事です。これが、なぜMozillaが存在するかという理由です。私達は、ビジネス上の好機があるからGoogleに競合するのではありません。インターネットとオンライン生活の健全性というものが、競争と選択に依存するからです。それらは、一般の消費者自身がより良い物を求めて行動を起こす事を自己決定できる、という事に依存しています。

Microsoftの決定はFirefoxの繁栄をより困難にするでしょうか？　おそらく、そうでしょう。Googleをより強力にする事は、様々な面で危険です。そしてその答えの大部分は、サービス・Webサイトを作ろうとするWeb開発者や業界・企業が何をするかに依存します。もしChromiumのような1つの製品が充分なマーケットシェアを持っているなら、Web開発者や業界・企業にとって、サービスやWebサイトがChromium以外のブラウザで動作するかどうか気にかけないでいる事が容易になるでしょう。それは、Firefoxがリリースされるより以前の、Microsoftが2000年代初頭にブラウザのシェアで寡占状態にあった時に起こった事です。そして、それはまた起こるでしょう。

もし<ruby>今日<rt>こんにち</rt></ruby>のオンライン生活で何が起こっているか気になるのであれば、Firefoxにも注意を払って下さい。Firefoxは18ヶ月前よりも劇的に改善されています――Firefoxは速度とパフォーマンスの点で再び引けを取らなくなっています。1週間ほど既定のブラウザとしてFirefoxを試してみて下さい、そしてそれから判断して下さい。Firefoxを強くする事がオンライン生活の問題のすべてを解決する訳ではありません――ブラウザは様々な要素の中のごく一部に過ぎません。しかし、もしFirefoxがあなたにとって良い製品だと気付いたら、あなたがFirefoxを使う事がFirefoxを強くします。あなたがFirefoxを使う事は、Web開発者と業界・企業がChrome以外の事を考える事を手助けします。そしてそれはFirefoxとMozillaがインターネット上の生活をより良くする手助けとなります――より多くの選択肢、より多くのセキュリティの選択肢、より多くの競争によって。

---

参考までに、本件についての日本語で書かれた記事へのリンクもいくつか示しておきます。

• MSEdge/README.md at master · momdo/MSEdge：本件についてのMicrosoft公式発表の翻訳
  • Microsoftが独自エンジンとしてのEdgeを断念してしまった日の記録 - 水底の血：訳者の方のブログ記事
• Microsoft EdgeがChromiumベースにすると公式に発表。多様性が失われるウェブへの懸念と祝福の声と - Togetter：各方面の反応集
• Microsoft EdgeのChromium移行とか - fragmentary：Web標準関係で手広く活動されてきた矢倉さん（こたせんせ）のブログ記事
• EdgeHTML死すとも...... | 覚え書き | @kazuhito：Web標準関係で手広く活動されてきた木達さんのブログ記事
• EdgeHTMLを悼む - saneyuki_s log：元Mozillaコミッタでもあって、現在もWebサービス提供者の中の人として働くさねゆきさんによる、各ベンダの事情に踏み込んで解説したブログ記事
• won't fix: RIP EdgeHTML. Software lifecycle is difficult：元IE6メンテナンスチームの一人で、現在はMozillaで開発者として働く加藤さんの、Microsoft製品のリリースサイクルという点に言及したブログ記事
• Microsoft EdgeのChromium化のアナウンスについて思うこと – Yoshifumi YAMAGUCHI – Medium：Googleでクラウド関係のアドボケイトをされている方による、仕様の標準化プロセスへの影響を解説した記事

ロストテクノロジーAdvent Calendar要にXULRunnerの話を書いた直後に、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も、そんな試みの中の一つです。

続きを表示する ...

How to use new "Successor Tabs API" of WebExtensions on Firefox 65? - Dec 03, 2018

• このエントリの日本語版はこちらにあります。
• This article is mirrored to Qiita.

By the fixed bug 1500479, following new features become available on Firefox 65 and later.

• New property previousTabId for activeInfo object notified to listeners of tabs.onActivated.
• New property successorTabId for tabs returned by tabs.get(), tabs.query(), and other APIs.
  • It is updatable via tabs.update().
  • However, there is no way to know changes of the property dynamically. It is not notified to listeners of tabs.onUpdated, and there is no alternative listening API like tabs.onHighlighted.
• New method tabs.moveInSuccession() to set successorTabId for multiple tabs, as an atomic operation.

When you close the active tab (by Ctrl-W or any operation), Firefox instead focuses to its next or previous tab. Or, if the closed tab was opened from another tab, Firefox possibly focuses the opener tab. In short: new Successor Tabs API is a mechanism to override these behaviors.

続きを表示する ...

WebExtensionsのSuccessor Tabs APIの使い方 - Dec 03, 2018

• There is the English version of this article.
• このエントリはQiitaとのクロスポストです。

Bug 1500479が解決され、Firefox 65以降のバージョンで、WebExtensionsのタブ関連APIに以下の変更が入る事になりました。

• tabs.onActivatedのリスナに通知されるactiveInfoに、previousTabIdというプロパティが追加されました。
• tabs.get()やtabs.query()などで取得されるタブのオブジェクトにsuccessorTabIdというプロパティが加わりました。
  • このプロパティの値はtabs.update()で変更可能です。
  • このプロパティの値の変更はtabs.onUpdatedでは通知されません。tabs.onHighlightedのような専用のリスナもありませんので、変更を動的に検知する方法はありません。
• 複数のタブのsuccessorTabIdをまとめて変更するtabs.moveInSuccession()メソッドが追加されました。

Firefoxでアクティブな（現在の）タブをCtrl-Wなどで閉じると、右隣や左隣、あるいはそのタブを開いた親のタブにフォーカスを切り替えるようになっています。上記の新機能は、この挙動に介入するための物です。「successor」とは「後継者」という意味で、つまり、アクティブなタブを閉じられた後に次にフォーカスされるタブを指定する仕組みという事になります。

今までの問題

今までは、WebExtensionsのAPI経由でこの挙動に介入する方法がなかったため、例えば「タブを閉じたら、必ずそのタブの直前に見ていたタブにフォーカスを移す」というような事をアドオンで実現しようとすると、

1. Firefoxによって何らかのタブがフォーカスされる。
2. その後改めて、別のタブにフォーカスし直す。

という手順を踏む必要がありました。これは見た目に美しくない（一瞬無関係のタブがフォーカスされてしまう）のもさることながら、現在のFirefoxの初期設定である「Ctrl-Tab/Ctrl-Shift-Tabで最近フォーカスされた順にタブのフォーカスを切り替える」という挙動にも悪影響を与えます。

拙作アドオンのツリー型タブも、ツリーの最後の子を閉じたら、右隣のタブ（＝下にある別のツリーの親タブ）ではなく1つ前の兄弟タブまたは親タブにフォーカスを移すという機能があり、これを実現するにあたっては前述の点がずっと未解決のままでした。今回のAPI追加によって、ようやくこの問題を解決する目処が立ったと言えそうです。

続きを表示する ...

#しがないラジオ 2 Advent Calendar 2日目：OSSやると英語の訓練になったり公表できる実績積めたりするんじゃないかなって話 - Dec 02, 2018

しがないラジオ2 Advent Calendarをご覧の方々、初めまして。しがないラジオsp.31でゲストとして出させて頂いた、Piroと申します。自分がどういう背景を持つ人間かについては、しがないラジオの当該回を聞いてみて頂けましたら幸いです。前後編で3時間はありますが……

しがないラジオ2 Advent Calendarの2日目は、「しがない」エンジニアになるためにあると良さそうな「人にアピールできる実績」の積み方についてのお話です。

つよいエンジニアって何だ？

さて。しがないラジオに限らず、エンジニア系Podcastを聞いているとよく「つよいエンジニア」というフレーズを耳にする印象があります。

強いとはどういうことか。人によって解釈にブレはありそうですが、「口だけじゃなく、形として実績が目に見えている」というのはわりと共通して言えそうな気がします。例えば、Googleのような著名企業でサービスやプロダクトの開発を主導しているとか、著名なOSSの作者（開発チームの一員）だとか、そういうプロジェクトに外部からパッチを提供しているとか。あるいは、何かの技術イベントを主催してるとか、技術書を（特に、商業出版の書籍を）書いてるとか。

で、いつかはそうなりたい、そうなるにはどうすればいいんだろう、と憧れを抱いている人が多いのかなと思います。

僕がそういう方にお勧めしたいのが、OSSの開発やコミュニティに実際に関わってみてはどうでしょうか？ という事です。既存のプロジェクトに関わるのも、自分で始めるのもどちらでもOKです。

「いやいや、ああいうのはつよいエンジニアの人がやる事で、自分みたいなペーペーがやるなんておこがましい……」そんなふうに思っていませんか？ だとしたら、それは因果関係が逆です。むしろ、OSSの開発に関わったから、その人は結果的につよいエンジニアになった、という風に考えてみて下さい。

続きを表示する ...

「短期的なKPIに踊らされずに、長期的な目で考える」と「目標を遠くに置くんじゃなく、常に近くに置く」は、反対の事ではなく同じ事を言っているという話。「こうありたいという目標」と「絶対にこれは嫌だという弱点」は同じ物だという話。 - Nov 30, 2018

先日しがないラジオmeetup 2の懇親会で若手の方相手に（偉そうに）話してた話です。

　

しがないラジオパーソナリティのzuckeyさんの発表でも触れられていた、ゲームをAIにプレイさせる機械学習の実験で、ゲームのスコアが上がるような行動に報酬を与えるというモデルではなく、今までにやった事がない行動を取る事に報酬を与えるというモデルにしたところ、その方が結果的に高いスコアが出るようになった、という話があります。

これを人間に当てはめると、「何をすれば一番自分が成長できるか？という事を考えて効率の良い成長に繋がりそうな事だけを繰り返すよりも、成長に繋がるかどうかはさておいて新しい挑戦をとにかく手広くやった方が、結果的により高いレベルの成長に繋がる」みたいな感じでしょうか。自分がしがないラジオにゲストで出させて頂いた時に話した、やりたい事をジャンル問わずやっていたら結果的にユニークな価値が生まれたという話にも、どことなく重なる話であるような気がします。

　

IT関係の勉強会で、どこそこの会社の会議室やイベントスペースを借りて開催する、という話はよく聞きます。懇親会で話していたその若手の方も、自社のスペースを使って勉強会を開催しようとしたらしいのですが、会社サイドから「それは採用に繋がるのか？」などの具体的な数字を示す事を求められて、自社スペースの使用を断念したとのことでした。

話を聞いていて、「分かりやすい数字を上げる事に固執して挑戦の芽を潰す」という事例のようにも思われて、まさに前述の話に反する事をしているように見えるなあ、そういう風に短期の数字に囚われないで、もっと長い目で考えた方が、結果的により良い結果に繋がるんじゃないのかなあ。そんなふうにその場で話しました。

　

ところで話はまったく飛びますが、教育先進国では子供に将来の夢を聞く時に「どんな職業に就きたいか」ではなく「どういう人でありたいか」を訊ねる、という説があるそうです。日本では将来の目標を定める時に「どういう地位に就くか」「どういう地点に到達するか」という事を重視しがちなため、一度その目標到達の過程で頓挫すると挫折したままになりがちなのに対し、他の先進諸国では「どういう行動を取る人でありたいか」という事も大事にしていて、そういう教育をしていると「今回は成果を出せなかったけど、こういう行動をしよう・こう振る舞おうという事はちゃんと達成できてたな」と考える事ができ、挫折から立ち直りやすいのだそうです。

考えてみれば、「名の通った有名企業に入りたい」や「歴史に名を残したい」といった目標というのは突き詰めると他人からの評価に依存する物なので、成功できるかどうかは運次第なのに対し、「誠実に生きる人でいよう」や「途中で投げ出さないようにしよう」のような行動指針を定める事は、あくまで「自分がどうするか」というだけの話なので、やればやっただけ確実に成功が積み重なるというおいしい目標設定だと言えます。

なので、その話を引用しつつ僕はその方に、「『つよいエンジニア』になる」のような仰ぎ見る対象の・遠くの地点を目標に設定するのではなく、「目の前の問題の解決に真摯に取り組む人であり続けよう」のような、常に自分の傍らに置き続ける道連れとなる行動指針を目標に設定して、その目標に反しないようにという事に気をつけて活動を続ければ、何かしらの結果が積み重なって自信に繋がるんじゃないでしょうか、という話もしました。

　

• 短期的な数値目標に囚われないで、もっと長い目で・中長期的な視点で考えよう。
• 遠い目標を仰ぎ見るんじゃなくて、もっと身近な所・自分の傍らに目標を置こう。

こうして並べてみると、字面的には矛盾する事を言っているようにも見えます。でも僕の中では、これらは矛盾しておらず、共通する1つの事を言っている、それを別の角度から言い表しているだけに過ぎない、という思いがあります。

続きを表示する ...

ネットの（技術）情報の思わぬ島宇宙化から、知的に真摯に生きる事や、そのように生きやすくする手助けの事を考えた - Nov 13, 2018

自分にとって非常に興味深く感じる事例に遭遇したので、Twitterだけでなくこちらにも記録しておきます。

事の発端は、「topコマンドの日本語の検索結果がデタラメばかりだった。原典にあたらず間違いを拡散している人が多い」という趣旨のツイートを見かけた事でした。

自分も過去にシス管系女子の本編でtopの簡単な説明を書いていたので、これは他人事ではありません。 「もしかして嘘を書いていたか？！」と真っ青になって、詳しくお話を伺ってみました。 その結果分かったのは、自分の心配は杞憂だった（自分が書いた解説の範囲についての話ではなかった）という事と、その人は不幸にも検索キーワードの選び方のせいで誤った情報の海に飲まれてしまった、「検索の仕方」によってネットの技術情報が島宇宙化している、という事でした。

（島宇宙化というのは元々は、宮台真司氏が「社会全体で共通の価値観という物が薄れ、同じ価値観を持つ者同士で小さな社会を作っている様子」を指していった言葉だそうです。自分はその言葉が登場した原典を読んでいませんが、物理的な距離によって隔てられた小集団ごとの社会があるだけだったのが、マスメディア等によって大きな社会が形成され、しかし価値観の多様化により再び小集団に分かれていっている、という事から出てきた表現なのかなあと思っています。）

続きを表示する ...

WebExtensionsのコンテキストメニューの新常識 on Firefox 64 - Nov 06, 2018

Here is the English version of this article.

• このエントリはQiitaとのクロスポストです。
• この記事はFirefox 64での改善についての話で、Firefox ESR60は対象外です。

朗報があります。2016年6月にWebExtensionsへ一本化の方針が示された時に出した要望であるBug 1280347 - Add ability to provide custom HTML elements working as alias of existing Firefox UI items, especially tabsが、最近ようやく解決されました。

何故これが朗報なのでしょうか？　アドオンのXULからWebExtensionsへの移行の話をおさらいしてみましょう。

続きを表示する ...