Mozilla勉強会@東京6thでLTしたfork版Secure Loginの話

Firefox

先日行われた Mozilla 勉強会＠東京 6th に参加し、LTもさせていただきました。そこで話したfork版Secure LoginについてのLTで話せなかったことを含めたお話。

Forking Secure Login
View more presentations from saneyuki_s

リポジトリは こちら。

本家のメンテナンスリリース具合

直近の数バージョンだと、install.rdfの変更がされる以外に実質的なコードへの修正は無い状態。
Firefox対応バージョンを変更するだけならAMOの機能で十分対応できると思うのですけどね……
そんな状況だけれども別に本家に不具合があるというわけでもないので、特に問題を感じない場合は本家を使った方が無難です。

fork版で削除した機能

LTでは時間が足りなかったために十分に話せなかったが、本家と比較して、fork版で削除した機能は大まかに以下のよとおり。

  • ページ内コンテクストメニュー項目の削除
  • ステータスバーアイコンの削除
  • Autofill Formsとの連携機能の破棄
  • ログイン時の通知音再生機能の削除

また、ログイン機能自体への変更として

  • frameset を使用したページの子フレーム内のログインフォーム探索を行わないように変更
  • iframe 内のログインフォーム探索を行わないように変更
  • JavaScript プロテクション機能をデフォルトで有効にする（隠し設定としてオンオフの切り替えは可能）

といった変更を施した。

特に上2つの変更については、大きな問題が発生しない限りは例外リスト機能等の実装も考えていない。そもそもフレーム内にログインページを読み込むようなページは根本的に行儀が悪いので、"Secure Login"という機能のコンセプトと合致しないと判断したため。

レガシーコードの破棄とメンテナンス性の向上

「レガシーコードの破棄」については、大別すると「古いFirefoxのAPIに依存するコード」と「古いHTML仕様・慣習に従ったコード」の2つに分けられると思う。（他には「メソッドの大部分をtry~catch文で囲む」などの、エラー発生を許容するための苦肉の策とも取れるコードなどもあります）
メンテナンス性向上のための修正も然りだけど、まだまだ手を加えられていない箇所がたくさんあるので道のりは遠いかなｗ
（余談ながら、結構古くから存在するアドオンの中には、有名なものに限ってレガシーコードが使われているものをいくつか確認していたりするので、なんとかならないかなーと思っていたりはする）

新機能

余計な処理を減らしたり設定値をキャッシュしたりといった修正が主なので特に新機能というほどのものはないのだけれども、最近 doorhanger 形式の通知への対応を進めている。進捗状況としては、とりあえずログインだけならば可能な状態。masterブランチへのマージは行っていないけれども頻繁にmasterの変更内容を反映しているし、リポジトリでは「doorhanger」という名前でブランチを公開しているので、試したい場合は簡単に試せるようにしている。
このdoorhanger対応についてはイロイロと話したいことがあるので、もう少し調べてみて、いずれどこかで話すつもり。とりあえず現時点では、doorhangerをアドオンで使うには結構苦労するとだけ言っておく。

基本方針

「できるだけ最新の技術・状況を反映してSecure Loginを動かす」
幸いにしてFirefox本体がRapid Releaseされているためにこの方針を取りやすくなってはいる。今後FirefoxもLTS版が登場するらしいけれども、たぶんそっちは考慮しないと思う。なので実験プロジェクトの域を抜ける日はまだまだ先になると思う……

それならばforkよりも1から再実装すべきだったのかもしれないが、経緯的な問題と何よりも動くコードがそこにあってライセンス的にも一応GPLで使える状況だったんだから仕方ない。ライセンス上の問題が出てきたらフルスクラッチすることになるかも。

今後やりたいこと

現時点の設計では、ページを移動する時だけでなくタブを切り替える時にも同様にページ内のログインフォームの探索を行うようになっている。なるべく処理の早い段階で探索を打ち切るようにはなっているけれども、どうせなら結果をタブ毎にキャッシュしたいので、どうしたものか考えているのが一点。id:moozさんがLTで発表されたWeakMapをうまく使えないか検討しているけれども結構難航している。

HTML5 formsへの対応も行いたい。とはいえ、form属性などの複雑な仕様に速度を維持しつつ対応する方法が現段階では思いつかないのでかなり放置気味。現在のnsILoginManagerとnsILoginInfoに保存されてる情報だとformAction属性などはかなりキツい（もしかしたらそのあたり含めてBrowserIDでどうにかしようとしてるんだろうか）。そもそもログイン用のフォームであの複雑性って使うことがあるのか疑問が無いわけではない。input要素のtype属性に限っては簡単に対応が可能なので特に問題はないと思ってる。

できればテストコードも書くようには、したい……

だいたいこんな感じ

  • 実験的プロジェクトです。
  • フィードバック歓迎です。
  • AMOに登録するにも道のりは長いです。その前に僕が飽きるかもしれない。