ふたばの一部の画像掲示板には手書き機能が備えられている。が、赤福プラスはふたばのページを自前のページ構成で上書きしてしまうので、その備え付けの手書き機能をそのままでは利用できない。そこでだいたい同等の手書き機能を赤福プラス自身が内包している。

しかしこの手書き機能が別に使いやすくもなんともなかったりする。とはいえ手書き機能は長年 dat にも img にも関係なかったのでつまり別に困ってなかったのだが、今回 img でも手書き機能が有効化されたので、そういうわけにも行かなくなったのである。そこで改めて手書き機能を眺めてみると、いろいろと機能が欲しくなってきた。具体的にはレイヤー機能が欲しい。

とそういうことで作ってみた。とりあえず開発しやすさを鑑み、赤福プラスとは独立したブックマークレットとして仕立てた。そのほうが多くの「」やとっしーも試せるし。

桃の缶詰
https://appsweets.net/momo/

ネーミングは例によって別に意味はない。さて公開後のいろいろな不満を浚ってみると、だいたい以下の2点に集約されるようである:

• 機能が多すぎるからクソ: つまり、手書きのミニマリズムに反しているのではないか？　という指摘だ。しかしこれはその機能を使わなければいいだけなので、批判としては弱い。
• ペンの補間がクソ: こちらは聞くに値する。手書きの拡張スクリプトとしては肌色キャンバスというものがすでにある。これも描線の補間をするのだがよくできていて描き心地が良い。それ比べると桃缶はクソだな！　という評価なのである。

書き込みに del を入れる際、いつの間にかリクエストに間を置かないといけなくなっている。そのインターバル内に複数リクエストすると「操作が早すぎます」云々と怒られる。

現状では del フォームの OK ボタンが押された際に同期的に処理していたのだが、これを改めて del リクエスト専用のグローバルなプロミスを用意し、OK ボタンのハンドラでは単にそのプロミスにリクエスト（及び 10 秒待機するディレイ）をチェインするだけにした。これにより操作が早すぎると怒られることはなくなる。また、del 済の書き込み上の del リンクはイタリック体にするようにした。ただしこれは永続化的な処理はしてないのでページをリロードすると元に戻る。

副作用として、山ほど del を入れて即ページを閉じたりすると予約されたほとんどのリクエストが水の泡となってしまう。まあ普通山ほど del を入れること自体がかなり奇妙な行動なのでこれはこれでいいか。

フルリロード、差分リロードした際に読み込んだバイト数を記録しているのだが、これは実は概算であって正確な値ではない。というのは意外なことに javascript から実際に読み込んだバイト数を得る方法はけっこう限られている。特に、レスポンスボディが圧縮されているとそれが顕著になる。

まずレスポンスヘッダ内の Content-Length があれば、それが読み込んだバイト数となる。終わり。圧縮されている場合は圧縮されている状態の転送バイト数となる。ふたばのサーバでは、html ファイルを読み込むと gzip 圧縮されたものが Content-Length 付きで返ってくる。しかし、差分リロードした際のリクエスト（これも gzip 圧縮されている）には Content-Length はない。したがって差分リロードの際に何バイト読み込んだかは全くわからない。

次に XMLHttpRequest の progress イベントをリスンすると、loaded プロパティと total プロパティで転送バイト数が得られる。ただし、内容が圧縮されている場合はこのイベントは少なくとも Chrome ではあまり役に立たない。全体を読み込み終えたあとで 1 回だけ発生し、その際 total は 0、loaded は展開後のバイト数が格納されている。つまり、圧縮状態の転送バイト数は読み取れない。

また、ここまではレスポンスボディの話だったがレスポンスヘッダのサイズも javascript からは正確なその値を取得できない。XMLHttpRequest#getAllResponseHeaders() が返す値は微妙に加工されている（HTTP/1.1 云々のラインなど）。加えて書くと、プロトコルが HTTP/2 の場合はヘッダも圧縮されているのでなおのこと実際に転送されたバイト数はわからない。

ということで差分リロードの際の転送バイト数および https 上の各読み込み時のヘッダに関してはヒューリスティックな謎の係数を使って圧縮後のサイズを概算しているのであった。これがだいたいの場合だいたい合ってるようなのだが合わないときは盛大に合わない。

さてどうしたものか。

文字参照というものがある。" とか、  とか、　 とかいったアレだ。赤福プラスが html ソースを DOM ツリーに変換する前に、それらを解決してしまいたい。解決というのは文字参照の表記から文字そのものに変換するということだ。

それが必要な理由は、たまに絵文字の表現としてそのコードポイントをサロゲートペアの文字参照で表記されるケースがあるからだ。これはそのコメントを送出した UA つまりブラウザか、拡張か、あるいは専ブラか……の明らかなミスで、サロゲートペアを文字参照で表記してはいけないのである。いけない表記をすると当然ペナルティがあり、それらは DOM パーサによって U+FFFD に置換されてしまう。これを、置換される前に気を利かせて解決したい。従ってそのために必要な処理は DOM パーサに渡す前段で行わなければいけないということになる。

ただし、この不正な文字参照の修復が可能なのは自前で DOM パーサにかける処理が入るフルリロード、及び内部データを JSON で取り扱う差分リロードをした場合のみである。最初にスレッドを開いたケースは構築済みの DOM ツリーから innerHTML を得るしかないため、既に書き込まれてる不正なサロゲートペアの文字参照は修復できない。この辺ふたばの鯖側で巧いことやってくれるとうれしいのだけど、しかし前述の通り原因はへんてこな UA の動作なのでふたば側がそんなことをする筋合いもないのが難しい。

続きを読む処理の高速化。まず続きを読む際に何をするかを列挙してみよう。

1. ふたばから html を読み込む
2. html のうちレス群以外を xml に変換する
3. xml を元に、スレ本文の諸々及びその他のバインディングを更新する
4. html のうちレス群を xml に変換する
5. xml を元に、読み込み済みのレス群の以下の項目を更新する:
   • 書き込んだ人による削除、スレッドを立てた人による削除、強制的なIP開示、なー
   • ID の開示
   • そうだねの増減
6. 新しく増えたレス群を html に変換し、そのフラグメントを DOM に追加する
7. 全レスに対して、ID の出現頻度をカウントし直す

この処理の内で現在ボトルネックになっているのは 5 と 7 だ。それぞれの処理をプロファイルしながら地道に高速化していく必要がある。

というわけで高速化した。1500レスくらいのスレッドで続きを読む全体の処理に 1 秒ちょいくらいかかってたのが、300msくらいになったのでだいたい 3 倍くらいか。あとは 4 も 100ms ほど時間がかかるのだがまあこれはしかたないかな。

あと関係ないけどついでに may とかで、添付された画像のファイル名を引用する習慣があるようなのでそういう形式の引用にもポップアップするようにした。

まず diff を取る対象はマークアップレベルのテキストにした。ただし a 要素の href 属性以外は全て削ぎ落とされる。

また diff ライブラリとしては jsdifflib を利用するようにした。行単位の比較だし、diff 本体とプレゼンテーションのためのコードが分離しているのも都合がいいし、10KB ちょいとコンパクト。

というわけで注意書きの変更を検知すると、window.alert() でその旨を通知したのち自動的に注意書きパネルが開き、以下のように変更点が表示される:

多分初見で意味が分かると思うけど、赤背景で打ち消し線が引いてあるのが変更後に削除された行、緑背景が追加された行だ。

ふたばの画像掲示板では送信フォームの下部に様々な注意書きを表示しているが、赤福プラスはロードした際にその注意書きの内容を覚えて保持しており、n キーを押すとパネルに注意書きが表示される。

さて、リロードした際にリロード前後の注意書きの内容を比較して、差異があったらそれを通知したい。できれば加えて、何が増えたのか減ったのかをグラフィカルに表示したい。つまり、diff の結果を表示したい。ところが、この diff のアルゴリズムというのは簡単なように見えて恐ろしく難しくて、それだけで1本論文が書けちゃうほどのものだったりする。それを真面目に実装するのも大変だし、既存のライブラリを組み込むにも、下手すると赤福プラス本体よりデカいとかありうる。

さらに、diff 自体の難しさと並行して、diff の対象をマークアップの段階にするか、人が読んで意味を取れる文章の段階にするかという問題もある。前者にすると、html マークアップ内の属性の変化も検知できるが、それがユーザが欲してる情報かどうかはやや疑わしい。例えば Chrome に ScriptSafe というエクステンションを入れると副作用としてありとあらゆる要素に ss-なんちゃらという属性を付けて回るが、この変化も検知してしまう。しかしこれはユーザにとってはどうでもいい情報だ。それを通知されても困る。

一方で後者、つまり各要素の内容だけをフィルタした結果にすると、例えば a 要素の href 属性と言った、割と重要な情報も見逃してしまう恐れがあるのである。どちらに振っても良い結果にならない。

どうするか。