Right-Click to Calendar - Chrome ウェブストア
3.9.0をリリースしました。終了日時検出と24時以上の表記に対応させました。
内部的な変更としては、background pageからevent pageの利用に移行しました。雑に説明すると「拡張機能のためだけに裏でずっとプロセスを生きたままの状態にせず、必要なときにだけプロセスが起動して、用が済んだら終了する」という修正です。普段の使用中に目にする箇所ではないため地味なのですが、私の環境だと拡張1つにつき25,000kb-30,000kbくらいメモリ専有してしまうのでいい加減（やろうと思ってから6年経ってる）対応しました。たしかRight-Click to Calendar作って半年後ぐらいに追加された機能だった気がします。
background pageとevent pageの違いとか、移行時の注意は以下のサイトが本当によくまとまっているので私からは特に何も説明することはないです。公式ドキュメントとあわせてお世話になりました。
- Chrome拡張では、Background pages よりも Event pages を使用したほうが良い - よんちゅBlog
- Chrome拡張機能におけるエコ対策（Event pageへの移行方法）
コンテキストメニューを設定する場合の注意として、chrome.contextMenus.createはchrome.runtime.onInstalled.addListener内で実行しないと、イベントページが生成されるたびにcreateが呼ばれて無限にコンテキストメニューが増えていきます。あとコンテキストメニュー押下時のイベントはchrome.contextMenus.onClicked.addListenerで定義する必要があります。
このあたりサンプルコード見るとわかりやすいです。
chrome/common/extensions/docs/examples/api/contextMenus/event_page/sample.js - chromium/src.git - Git at Google
あと、Right-Click to Calendarは選択中のテキストを予定登録画面に送信する必要があり、今まではそのテキストをbackground pageに記憶させて、予定登録画面からgetBackgroundPageで取得していました。今回はbackground pageが永続化できないため、以下の方法を取りました。chrome.windows.createで任意のオブジェクト渡せればいいのに…。
- chrome.windows.createで生成するウインドウ（＝予定登録画面）のURLパラメータに、コンテキストメニューの呼び出し元のtab.idを付与
- ウインドウ生成後、ウインドウ内で読み込んだスクリプトでURLパラメータ内のtab.idを取得
- tab.idに一致するcontent scriptに対して、ウインドウからsendMessageを実施
- messageを受け取ったcontent scriptがレスポンスとして選択中のテキストを送信する
- ウインドウがテキストを受信する
これだけいろいろやりましたが、Chrome Extensions Manifest V3でbackground pageを廃止してService Workerに移行する計画もあるみたいなので、すぐ移行できそうなアプリではない限り、今からのevent pageへの移行はおすすめできません。もう少し動向を見たほうが良いと思います。
参考：Latest topics > Chrome Extensions Manifest V3とFirefoxアドオンの死（の可能性） - outsider reflex