Home > Latest topics

Latest topics 近況報告

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

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

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

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

ツリー型タブ バージョン3.0への道 - Mar 30, 2019

これはただの苦労話です。

2月末から3月末までをかけて、長らく懸案事項となっていたツリー型タブ(Tree Style Tab、TST)の大規模改修をやりました。具体的な変更の量としては、改修に取りかかる前の2.7.22からの差分 git diff 2.7.22 で約1MBありました。見た目は変えなかったのであまり代わり映えしませんし、挙動を決定づけるロジックもほぼそのままなのですが、それらが乗っかる基盤にあたる部分が入れ替わった感じです。

何を改修したのか、どういう成果があったのか、という事を説明するために、TSTのこれまでの歴史を振り返ってみます。WebExtensionsに移行した時の話ではあまり触れなかった、細かい実装の話が多めですが、誰の役に立つかは分かりません。

続きを表示する ...

Chrome Extensions Manifest V3とFirefoxアドオンの死(の可能性) - Feb 04, 2019

1523784 - Set up analytics for https://extensionworkshop.com というbug(※bugzilla.mozilla.orgではシステム上でトラックされているタスクを一般的に「bug」と呼ぶ)でどうやら何かアドオン(拡張機能)作ってみましょう的なイベント?の準備が進められているらしいという事を、人から教えて頂いた。キャンペーンサイトの準備中バージョンらしき物を見てみると、絵が豊富で見た目とっつきやすそうな感じに仕上がってる印象で「ほほう」って思ったんだけど、アドオンの構造を図解してる部分でbackground script等の話が出てきてるのを見て、ちょっとキナ臭いというか不安というかそういう思いが頭をよぎった。

というのも、FirefoxのWebExtensionsというのはGoogle Chromeの拡張機能の現行の仕様(Manifest V2)をベースに作られてるわけだけど、他ならぬGoogleがManifest V3でbackground scriptの廃止などのかなり大きな変更をしようとしている状況で、この内容で大々的にリリース打って大丈夫なのか? と。

だって、このキャンペーンサイト(多分)の内容を素直に受け取ると「WebExtensionsのAPIを使ってアドオンを作ろう。他のブラウザにも移植しやすいよ。」というような話になってると思うんだけど、いやちょっと待ってくださいよ。Firefox向けにWebExtensionsでアドオン作っても、Google ChromeがManifest V3に移行しちゃったら、それ動かないじゃんすか。っていうかChromeがManifest V3に移行するってことは当たり前だけどChromiumもManifest V3になるってことで、ということは、Chromiumベースのブラウザも(各ベンダがどう思ってるかに関係なく、強制的に)全部Manifest V3に移行するってことじゃんすか。次期EdgeもOperaもVivaldiもKinzaもみんなManifest V3に行っちゃって、そしたらChromiumベースでないFirefoxだけ置いてけぼりじゃんすか。

つまり、ChromeのManifest V3移行は、ちょっと前に騒がれてた「Chromeの拡張機能の大量死」という影響だけでなく、Firefoxにとっては「大多数の開発者にとっての、(Manifest V2互換の)WebExtensionsでFirefox用アドオンを作る意義の消失」という影響を及ぼすのではあるまいか? という事に、遅まきながら気付いたわけです。

昨年のTokyo WebExtensions Meetupに参加されていた方が実装上困っておられた事について「Firefoxでは(Chromiumに無い独自拡張の)APIがあるから、Firefox向けにだけちょっと便利にするみたいなことはできるよ」的な話をしたら、「いやあ……Chromeで使えないんじゃ、その機能は使えないですね……」と敬遠された時に、改めて思い知ったのですよね。ああ、WebアプリやWebページを作る人達だけじゃなくて、ブラウザを拡張するという拡張機能を作る人達にとっても、いまや「ふつうはChrome」であって「Firefox対応はオマケに過ぎない」んだな、って事を……

FirefoxのWebExtensionsはいまのところManifest V3に追従する予定はないみたいな話をどっかで又聞きした気がしてますが、いやいやそんな悠長なこと言うとれんやないですか。ツリー型タブを実装できなくなるからManifest V3に完全移行はしないで欲しいけど、Firefox一人だけ置いてけぼりを食らわないためには、オプションとしてでもManifest V3に対応は絶対しなきゃいけないじゃないですか。

ほんとどうなるんだこれ。

 

難しい事は脇に置いて、「アドオンを作る人」「ベンダが提供しているUIに気に入らないところがあってイラッてなったときに自分で手を動かして解決したい人」という立場から「こうだったらいいのに」という事を書き留めておきますと、

  • ブラウザ本体が提供するUIが気に食わない時に努力次第でゴッソリ置き換えられる余地は欲しい。(Tree Style TabやVimiumのような)
    • こういう物を実現するにあたっては、筋の良い設計にしようとするとどうしたって「永続的なバックグラウンドプロセスが全体を統括する」という設計になるので、それができる余地は欲しい。
    • 常時見える状態で画面上の領域を占有できる余地は欲しい。現状で言えばSidebar APIはその代表例。
    • この点で、「サイドバーみたいなものは不要」「拡張機能は原則として一時的に呼び出されすぐ終了する物であるべき」「UIの領域においそれと踏み込ませたくない」みたいな設計者達の思想が強く表れているGoogle Chrome、そしてそのChromeの設計に強く引きずられたあまり永続的なバックグラウンドプロセスまで廃止してしまう(と自分には読めた)Manifest V3は、自分が欲している物とはかけ離れている
  • サイトごとの権限と機能の権限は、確かに別々に記述できるべきだと思う。Manifest V2/現行WebExtensionsのpermissionsの書き方はあまりにダサイ
  • フィルタリングを宣言的に簡単に設定できることは、単純に良い事に思える。
  • 現行のwebRequestのような「クライアントサイドでリクエストやレスポンスの書き換えを任意に行える機能」は、新しい事をやる余地を残すために必要だと思う。
    • ただし、現状のようにシレッと他の権限と一緒に一言だけの注意書きで確認を求められる程度ではなく、「黄色と黒の縞々」みたいな禍々しい外観で激しく警告するような事は必要だと思うし、もっと細かく権限の段階を分けた方が良いと思う。
    • このページは拡張機能の何々によって内容が改変されています、みたいな警告をロケーションバーあたりに表示しておくというのもありかもしれない。
  • 総じて、自己責任で愚行権を行使できる余地は認められていて欲しい。警告も何も読まず、危険な物をホイホイインストールして、重くなったとか不安定になったとか言う、自分がやっている事の意味を自分で分からない・分かろうとしないような人のことまで手厚くケアする必要は無いんじゃないの? そういうのが欲しい人はApple製品を使うのが筋だと思う。技術屋が高級ブランド家電屋になろうというのが無理がある。

という風な事を自分は思っています。

ツリー型タブでタブの並び順が壊れる問題との格闘 - Jan 12, 2019

ただの苦労話です。

ツリー型タブWebExtensionsに移行してからこっち、ずーーーーーっと悩まされてる事がある。それは、TSTのサイドバー上のタブとFirefox本体のタブの並び順が一致しなくなる事があるという問題。

何故そういう事が起こるのかというと、色々な背景があるのですが……

  • 当初はタブの並び順の制御については、WebExtensionsのAPI経由でタブを移動した後、それがtabs.onMovedで通知されるのを待って、通知された情報に基づいてツリーを更新するということを考えていた。
  • しかし実際にそうしてみると、まあ遅いこと遅いこと。Firefoxとアドオンのプロセスが別だからなのかそれとも別の理由があるのか、イベントがTSTに通知されてくる(結果が返ってくる)までにかなりのタイムラグがある事が分かった。
  • そこで、WebExtensionsのAPI経由でFirefoxのタブを並べ替えるのと同時に、別途runtime.sendMessage()でタブの移動を行う指示をバックグラウンドページとサイドバーの間でやり取りして、イベントの通知を待たずに先にツリーだけ更新するようにした。

で、タブを一つ一つゆっくり操作している場面(僕の普段の使い方)ではこれで問題無かったんですが、このやり方には、リンクからタブをまとめて開くとかブックマークレットを使うとかしてTSTのあずかり知らぬ所で複数のタブが一気に開かれた場合に、TSTのツリーとFirefoxのタブの順番の同期が崩れやすくなってしまうという、大きな大きな副作用がありました。

  • tabs.onCreatedtabs.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(置き換え)という形で最小の編集手順を導き出してくれました。タブの並べ替えでは「タブがなくなる」という事は前提としてあり得ないため、insertreplaceのうち挿入箇所にあたる部分だけを編集情報として使っています。これのお陰で、いままでは無駄に何度もタブを行ったり来たりさせていたのが、場合によってははるかに高速に並べ替えが完了するようになってくれました。

レガシーなやり方を捨ててモダンな仮想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年代初頭にブラウザのシェアで寡占状態にあった時に起こった事です。そして、それはまた起こるでしょう。

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


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

ロストテクノロジー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

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

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追加によって、ようやくこの問題を解決する目処が立ったと言えそうです。

続きを表示する ...

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

Here is the English version of this article.

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

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

続きを表示する ...

WebExtensionsベースのアドオンが他のアドオンと連携するにはどうするのが良いか? - Nov 06, 2018

Here is the English version of this article. 7月に英語で書いた物の日本語版です。Qiitaにもクロスポストしています

ツリー型タブXULからWebExtensionsに移植した時の話で、アドオン同士の連携が取りづらくなる事への懸念について書きました。この点について現時点での知見をまとめておきます。

続きを表示する ...

WebExtensionsでのタブの複数選択APIのつかいかた - Nov 01, 2018

Tokyo WebExtensions Meetup #3で、標題の通りの発表をしました。スライドはQiitaにありますが、こちらにもクロスポストしておきます。

タブの「選択」状態とは?

タブの複数選択機能が入った事で「選択」という言葉が多義的になってしまったので、まずその点を整理します。 WebExtensions APIにおいては、「選択」という言葉で表されうる状態に以下の2つがあります。

  • アクティブ なタブの事
    • active tab というのがWebExtensions APIの語彙上の言い方
    • current tab という言い方も古くからある
    • foreground tab という言い方もある(background tabとの対比)
  • 選択複数選択) 状態にあるタブの事
    • highlighted tab というのがWebExtensions APIの語彙上の言い方
    • multiselected tab という言い方もされる

「selected tab」という表現は紛らわしいので、このエントリでは使いません。

Firefox本体に入ったタブの複数選択機能

Firefox 63でabout:configbrowser.tabs.multiselecttrueにすると試せます。Chromeでも同じ操作ができます。

  • タブの上でShift/Ctrl(Command)-クリックでタブを選択できます。
    • 選択されたタブは、上に青い線(Linux版ではシステムカラーに依存する。UbuntuのAmbientテーマではオレンジ色)が出る。
      (スクリーンショット)
  • タブが選択されていると、コンテキストメニューほか一部の機能が「選択中のタブすべてについてそれをする」ようになります。 (スクリーンショット:メニューのラベルが「Tab*s*」になっている)
    • まだ一部の機能はそのようになっていない。Firefox 64で一通りの機能がすべてタブの複数選択に対応するという事だと予想される。

アドオンからの2つの利用局面

WebExtensionsベースのアドオンにとっては、このタブの複数選択機能に対して2つの関わり方があります。

  • 選択されたタブに何かする
    • タブを処理対象にした便利な機能を提供するアドオンの場合
  • タブを選択する
    • タブを管理する、タブバーの代替となるアドオンの場合

それぞれ順番に紹介します。 なお、基本的にはChromeの拡張機能でも同様のAPIが使えます。

続きを表示する ...

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

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき