Electron アプリで日付を偽装する

このモードがあるのは、ある具体的な失敗がきっかけです。Electron で作られたポモドーロタイマーを x60 のセッションで動かしたところ、カウントダウンがまったく進みませんでした。アプリのバンドルを分解すると、互いに独立した 2 つの理由が見つかり、どちらもネイティブ側には対処法がありませんでした。

• カウントダウンは時計を読んでいませんでした。Web Worker の中で動く、setInterval で増えるカウンターだったのです。アプリが「いま何時か」を一度も尋ねないので、フックすべき時刻の呼び出し自体がありませんでした。
• その Worker はサンドボックス化されたレンダラープロセスの中にあります。外部からインジェクトされたライブラリが入り込めない、まさにその場所です。

そのため、Windows 側の仕組みはここでは役に立ちません。答えは、代わりにアプリ自身の JavaScript エンジンと直接やり取りすることです。

アプリはデバッグポートと、きれいな使い捨てのプロファイルで起動され、そのアプリ自身の時間関連 API が DevTools プロトコル経由でセッションの時計に載せ替えられます。対象は Date.now、new Date() コンストラクター、performance.now、setTimeout、setInterval です。

この上書きは、アプリが開くすべてのコンテキストに、Web Worker も含めて設定されます。タイマーがたいていいるのはそこであり、ネイティブのインジェクションがどうやっても届かない唯一の場所です。

操作方法は何も変わりません。同じコマンド、同じウィンドウ、2 つの時計と判定が並ぶ同じセッションパネルです。

もう 1 つ、人を驚かせるのは、すでにスケジュールされたインターバルは、セッション中に速度を変えても元のペースを保つことです。Date.now、new Date()、performance.now はすぐに反応しますが、実行中の setInterval は反応しません。何も起きなかったと誤解させないよう、セッションはこの点について警告します。

実験的です。この言葉には、ここでは決まった意味があります。想定した対象では動作する、広範にはテストされていない、そして信頼できる情報源は、このページではなく内蔵の監査である、ということです。自動化されたテスト一式ではなく、64 ビット Windows 上の実際の Electron アプリで手作業により確認されました。

カバレッジはプロセス単位ではなく JavaScript コンテキスト単位で報告されます。ここで存在する単位がそれだからです。何もせず待機していて時刻を一度も尋ねないアプリは、正直に判定不能を返します。時計を読んでいないので、正しい時計を見たかどうかについては何も言えないのです。判定の意味 →