2014 年やったこと - Chromium 編

Chromium 関係，コードはあまり書いていない一年でした．数字としてはコミット 17 回，コードレビュー 13 回となります．一方 Issue Tracker 上での活動はまあそれなりにで，Issue 登録 19 回，コメントを書き込んだり状態を変更したりといった Issue の数は 173 件となりました．

自分でやったこと

Windows 版 Chromium の Aura 移行完了後不要になった IME 関連コードの削除

2014 年 1 月から 2 月にかけて，Aura + Ash 移行に伴い不要になった IME 関連コードの削除をやっていました．既にチームを移っていたこともあり，最後の後片付けという感じです．書くだけ書いて後片付けを次の人に任せるのは気が引けたというのもありますし，Chromium に関わり始めた 2012 年ごろ，おっかなびっくり書いたやっつけコードを自らの手で消し去る良い機会だったというのもあります．

Windows 版 Chromium で HiDPI 有効化時に IME の候補ウィンドウの位置がずれる問題の修正

f:id:NyaRuRu:20150104153618p:plain
2013 年に自分が登録したバグですが，普段使っている Windows ノート PC がこの影響を受けていてあまりにも不便だったので，土日の空き時間を使って自分で直してみたものです．

Android 5.0 の新 IME API への対応 (未完)

後で改めて書くかと思いますが，2014 年のメインプロジェクトの仕事のひとつで Android 5.0 にいくつか IME API を追加，というのをやっておりました．追加した API は InputMethodManager.html#updateCursor API の置き換えを狙ったもので，変換中の文字列のスクリーン座標を IME に伝えられるようにするものです．さて，この種の新 API の宿命として，IME だけでなくテキスト入力 widget 側にも新 API 対応が必要になります．Android の標準 TextView を使っているアプリケーションであれば何もしなくてよいのですが，独自にテキスト描画を行っているアプリケーションではそうはいきません．Chromium も当然ながらこのカテゴリに属し，Android 5.0 の SDK を使用して割と面倒なコードを追加する必要がありました．この仕事，当初は Chromium Android 版チームの人に頼もうかと漠然と考えていたのですが，Android 5.0 の開発期間中にとりあえず動く検証用コードを書き上げてしまったこともあり，なし崩し的に自分で対応コードを追加することになったという感じです．
とはいえコードレビューでのリクエストに色々応えていたらだいぶ規模が大きくなり，そのまま年末休暇シーズンに突入してしまったため，実現は 2015 年に持ち越しとなりました．

Issue Tracker 上で情報提供しつつ直してもらったものからいくつか

base::SHA1HashBytes に 4 GB 以上のデータを渡すと誤ったハッシュ値を返す

別件で SHA1 Hash の計算式を調べていたときに，参考に見てみた Chromium の内部関数に問題を見つけてしまったというものです．ざっと見てみた範囲では問題になるケースは見つけられませんでしたが，念のためセキュリティバグとして報告，修正してもらいました．

Chrome Remote Desktop (Chromoting) のウィンドウ上ではクライアント環境の IME は常にオフにすべき

仕事で Chrome Remote Desktop (内部コードネーム Chromoting) を使うことが良くあるのですが，IME 関係で不満があったので変更を提案して対応してもらったというものです．
Windows 環境から Linux 環境に Chrome Remote Desktop で接続するケースを考えてみます．このとき，Chrome Remote Desktop のウィンドウ上でクライアント側 (Windows 側) の IME を有効にすることができてしまっていました．しかし，確定した文字列は単に捨てられてしまうという状況でした．
f:id:NyaRuRu:20150427054704p:plain
これは，特に機能として役立っていないだけではなく，パスワードを意図せず IME に学習させてしまうなど望ましくない動作でした．そこで，クライアント側の IME を完全にオフにするという提案をしてみた次第です．
以前 Pepper SDK の IME 周りを担当されていた kinaba@ さんの的確なアドバイスのおかげで，数日のうちに対応していただくことができました．

Time::EnableHighResolutionTimer(false) が無視されることがある






2014 年 7 月頃，ネットメディアを中心に Windows 版 Chrome の電力消費量が話題になったことがありました．報道に関して色々言いたいことはあったものの，実際うまく動作しないケースが存在することも知っていたので，念のため知っていることを Issue Tracker にコメントしておきました．実際には他にも色々問題があったらしく，しばらくしてまとめて修正していただきました．マルチスレッド絡みバグがたくさん見つかったそうです．

base::PowerMonitor::AddObserver と base::PowerMonitor::RemoveObserver が同じスレッドで呼ばれないことによる use-after-free

たまたま自分の目の前で Google Chrome Canary がクラッシュしたので，クラッシュダンプを頼りに Issue Tracker 上で原因究明に協力したものです．Issue としては以下のものになります．(Chromium ではクラッシュバグは原則セキュリティバグ扱いのため，特定アカウントでログインしていない限り以下のページは表示されません．面倒な仕組みですみません)

仮想関数呼び出しで EXCEPTION_ACCESS_VIOLATION_EXEC という一見不可思議なクラッシュだったのですが，イベントリスナーとして使われている仮想関数だったことから use-after-free を疑って関連コードを読んでいくと，以下のようなコードを発見．これ，AddObserver と RemoveObserver が同じスレッドで呼ばれないと，RemoveObserver はサイレントに何もしないという実装だったという．
http://src.chromium.org/viewvc/chrome/trunk/src/base/observer_list_threadsafe.h?revision=212281#l125

  // Remove an observer from the list if it is in the list.
  // If there are pending notifications in-transit to the observer, they will
  // be aborted.
  // If the observer to be removed is in the list, RemoveObserver MUST
  // be called from the same thread which called AddObserver.
  void RemoveObserver(ObserverType* obs) {

「このせいじゃね?」とコメントしておいたところ，直前にコミットされていた Issue 482333003: Reland r290125: Close all active PeerConnections upon OS suspend - Code Review がまさにこの問題を踏んでいたことを特定していただきました．これにコードレビューで気付けというのはちょっと無理ですかね．ライブラリの設計ミスとでも言うべきか．

Google Cloud Messaging クライアントの exponential backoff が約 7 日でオーバーフローする

利用者からバグ報告に担当者が割り当てられていなかったので，関係しそうな人々を CC しただけ仕事です．Chrome が特定条件で (Google のサーバーの?) port 5228 に大量のパケットを送信する，という問題．原因だけは気になっていたのでその後もやりとりをウォッチしていたのですが，exponential backoff の計算方法に問題があって，約 7 日送信失敗し続けると double の精度を超えてしまっていたというオチでした．

Windows 10 Technical Preview 上で動く Chromium の User Agent が "Windows NT 6.3" と返す

Windows 8.1 のときにもあった，GetVersionEx 嘘つき問題です．マニフェストファイルに GUID を追加すれば解決する話ではあるのですが，実際手を出してみたら大量の yak shaving に付き合わされたのが前回．今回は Issue として登録して直してもらいました．

感想

何となくそうではないかと予想していましたが，Issue Tracker で人に作業を振ったりあれこれ意見を述べるだけってのはだいぶ楽ですねこれ．チームを移ったこともあり，基本的に休日や通勤中の空き時間でできる作業に専念していたのですが，これぐらいの作業なら空き時間との相談で続けてもいいかなというところです．
一方で Chromium のコードを書く人の負担が半端なく大きいという問題は未解決のままと言えます．かなり厳しいコードレビュー，法外に高いクロスプラットフォーム対応コスト，不安定なテスト，コミット後忘れた頃にやってくる regression とクラッシュの報告．実際に問題を修正してくれている人たちは何故そんな面倒な仕事をしてくれているのか，そこをうまくシステム化していかないとブラウザ開発というプロジェクト自体の持続可能性が危ういんではないかなと．Issue Tracker であれこれ意見を言うだけの人が 100 人いても，大変めんどくさいコード変更作業に立ち上がってくれる人が 1 人現れない限り問題は解決しないという構造をプロジェクト運営にどう反映させていくのか．思うことは色々あるのですが，この辺についてはまた改めて別のエントリで書いてみたいと思います．
2015 年ですが，Android 5.0 の新 IME API 対応はさっさと終わせないとですね．その先はあんまり考えていないです．まあなるようになる感じで．

過去のエントリ

References

コミット一覧

レビューした CL 一覧

報告した Issue 一覧

コメントした Issue 一覧