Home > Latest topics

Latest topics 近況報告

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

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

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

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

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製品を使うのが筋だと思う。技術屋が高級ブランド家電屋になろうというのが無理がある。

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

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 を設ける。
  • ツールバーの動作とページでの動作は、browserActionpageAction を単一の action APIに統合する。
  • chrome://favicon に関する権限をchrome.favicon APIに移す。
  • tabs, pageCapture, tabCaptureおよび desktopCaptureを単一のcapture APIに集約する。
  • オープンなWeb標準で定義された機能はAPIからは削除する。
  • ServiceWorkerベースのAPIへの更新。特に、いわゆるメインスレッドとして走る処理のための物。
  • 公に非推奨・廃止予定とされていたAPIの廃止・削除
  • その他、性能や利便性、人間工学的な観点での細かい修正。

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

この中で特に webRequestdeclarativeNetRequest に関わる部分は、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.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のタブの並び順を制御する部分はきっとそのまま使い続ける事ができそうではあるので、今回やった事も完全に無駄というわけではないかな、と……)

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が使えます。

続きを表示する ...

Various "custom context menu" usages in Firefox 64 - Oct 26, 2018

As I described at the previous article, you can provide more useful and usable context menu for your addon on Firefox 64 and later, if it is focused to control tabs or bookmarks. The previous article described basics of new APIs, but it looked too complex because there are various usecases. So this article aims to describe how to provide context menu simply for different cases:

  1. Extra context menu items for custom commands, when your addon has no sidebar/popup panel
  2. Extra context menu items for custom commands, grouped under a submenu with a custom label
  3. Context menu dedicated to custom commands on your sidebar/popup panel, and expose them as a submenu on other situations
  4. Context menu dedicated to custom commands only on your sidebar/popup panel
  5. Context menu dedicated to custom commands on your sidebar/popup panel, and expose them as a submenu on other situations, with a custom label
  6. Imitated context menu compatible to Firefox's one on tabs or bookmarks, only on your sidebar/popup panel

All following examples assume that your addon named "Bucket" provides ability to send tabs to an online bucket, like the "Pocket".

続きを表示する ...

An improvement of WebExtensions on Firefox 64 about implicit collaboration of addons - Oct 14, 2018

このエントリの日本語版はこちらから読めます。

(Note that this article describes about an improvement on Firefox 64, and Firefox ESR60 is out of target.)

Good news! An old feature proposal filed at the time Mozilla announced that XUL become deprecated and WebExtensions become the next main line has became fixed: Bug 1280347 - Add ability to provide custom HTML elements working as alias of existing Firefox UI items, especially tabs.

Why it is a news for me? Let's look around the short history of addon migration from XUL to WebExtensions.

続きを表示する ...

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

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき