Pull Request が来ているのでサクッと片付けようとしたら、片付かなかったという話。

まず webapp 向けのマニフェストを追加して欲しい、というリクエスト。

webapp とはなんぞやというのは、google によるドキュメントやそのサンプルや W3C によるドキュメントを参照のこと。

で、そのマニフェストというのはつまり、webapp、いわゆる web アプリケーションがあったとして、それをまさにアプリケーションとして扱う場合にそのメタデータ（アイコンとか、エントリポイントとなるパスとか、画面の方向とか、色々）を記述しておくための統一書式に従って記述された json ファイルのことらしい。

Chrome 38+ では、バーガーメニューから例えば「デスクトップに追加…」みたいな項目を選ぶと、現在のページヘのショートカットをデスクトップに保存する。このとき、マニフェストを読み込み、アプリケーション名やタイトルや何やらが自動的に設定される。Android 版の Chrome にも似たようなメニュー項目があり、ホーム画面へ追加することができる。というか、最初 google のドキュメント読んでてタイトルが “for Android” なんてなってるものだから、思わずリクエストをくれた方に「これって Android 向けなの？」とか聞いてしまった。PC 版の Chrome にもあります。

wasavi の場合、textarea に乗せて起動する場合は webapp とは言えないが、http://wasavi.appsweets.net/ をブラウザで開いた場合は自動的に wasavi が起動し、ある程度 standalone なテキストエディタとして使える（ローカルファイルシステムへの読み書きはできず、web 上のストレージが対象になる）。このモードは確かに webapp と見なせて、件のリクエストもこのサイトに置くべきマニフェストを追加するというものだ。

そんなわけで、リクエストを単にマージし、試してみたのだがどういうわけか manifest.json を読んでくれない。何やらエラーになる。え…なんで…というわけで原因を突き止めるのに 1 日かかってしまった。

wasavi が起動する際、上記の通り 2 つのモードがある。textarea が対象となる場合は iframe のドキュメントを操作する。standalone で使用する場合は http://wasavi.appsweets.net/ 上のドキュメントを操作する。さらに iframe の場合はブラウザごとに微妙に分かれるので、計 6 パターン、実質的に 3 パターンがある。

1. Chrome / textarea: エクステンション内の wasavi.html（web_accessible_resources にリストしてある）をソースとする。内容はそのまま使う
2. Chrome / standalone: http://wasavi.appsweets.net/ をソースとする。エクステンション内の mock.html の内容で上書きする
3. Opera / textarea: http://wasavi.appsweets.net/ をソースとする。エクステンション内の mock.html の内容で上書きする
4. Opera / standalone: http://wasavi.appsweets.net/ をソースとする。エクステンション内の mock.html の内容で上書きする
5. Firefox / textarea: about:blank をソースとする。エクステンション内の mock.html の内容で上書きする
6. Firefox / standalone: http://wasavi.appsweets.net/ をソースとする。エクステンション内の mock.html の内容で上書きする

この内ソースを上書きするか否かだが、ソースの内容が元々空だったり（about：blank）、信用できない外部リソース（http://wasavi.appsweets.net/）の場合はエクステンションが用意する DOM の構造で上書きする。Chrome / textarea の場合は自分のリソースをそのまま使うので上書きする必要はない。

この時、上書きする head 要素のマークアップにマニフェストを指定する link 要素を含めているはずなのだが、実際にそれを「デスクトップに保存」すると動的に追加した link 要素ではエラーになってしまうようなのだ。これを突き止めるのに 1 日かかった（自分を擁護すると早い段階で原因の1つにはリストアップしてたのだけど、他の可能性を確認して最後の最後に試してみたのがこれだった）。これはバグなのか仕様なのかよく分からない。

とりあえずのワークアラウンドとしては、http://wasavi.appsweets.net/ が返す内容の head 要素にもマニフェストへのリンクを含めるようにし（これ自体は全くおかしくない）、standalone のときは head 要素の内容については上書きをせずそのまま使う、ということになる。

ここで1つ問題がある。そもそもなぜ上書きするのかといえば、上にも書いた通り信用できない外部リソースだからだ。http://wasavi.appsweets.net/ は単にプレースホルダドメインとしての役割以上の何物でもない。これを翻して、head 要素の内容をそのまま使うとすると、せめて http ではなく https にしないとまったく割が合わないのである。

でもねえ https ってけっこう維持費かかるのよねぇ〜と思っていたのだが、ぐぐってみると最近はかなり低コストで、というか無料で https 化できたりできなかったりするようだ。そのへんも含めて色々変える必要がある。

とこういうわけで 1 つの Pull Request にまったく四苦八苦しているのであった。