1.
パッチを書いてみよう
masa
2011-07-23 Nseg 第 17 回勉強会

2. 自己紹介
はてな：http://d.hatena.ne.jp/masa141421356
(id:masa141421356)
Twitter : @masa141421356
ほぼプログラマ。仕様の打ち合わせから実装まで全部やります。

3. Firefox のパッチって
どう書くの？

4. 第１部：パッチを書くのに必要なもの
・Firefox のバイナリをビルドできる開発環境
・bugzill.mozilla.org のアカウント
・ Firefox で使用している技術(C++, JavaScript,
HTML, CSS, XUL, HTTP, etc.)の知識
・
「ある程度」の英語力

5. ・作業時間(これ重要)
・
自分が気になったバグを追いかける根気
1. 開発環境
MDN 開発者ガイド
https://developer.mozilla.org/ja/Developer_Guid
e

6. 殆どのツールは OS 付属か
無料ダウンロードで揃う。
SDK 揃えるのが面倒？
ま、ビンゴ揃えるつもりで
(By Benjamin Smedberg)
http://benjamin.smedbergs.us/blog/2008-04-16/microsoft-header-bingo/

7. 2. bugzilla.mozilla.org アカウント
メールアドレスがあれば OK
ログインしている人にはメールアドレスが見
えるので、英語 SPAM が嫌いな人は迷惑メー
ル対策の出来るアカウントでやるのがお勧め

8. 3. 技術の知識
Firefox のソースはコアの部分は C++
UI は XML/HTML + JavaScript + CSS など。
UI 系だと画像を作るだけでよいバグもある

9. （bug 414243 誰かやりませんか？）

10. そのほかには
Web に 関 わ る 各 種 の 標 準 (HTTP, HTML,
XML, ECMAScript, CSS 等)
OS の標準的なアプリケーションのガイドラ
インや API の知識

11. あと、Mozilla のコーディングスタイルガイ
ドライン。大体周辺のコードのスタイルに合
わせれば OK。
技術を全部知っていなくてもパッチは書け
る。

12. 4.
「ある程度」の英語力
bugzilla.mozilla.org のディスカッションは
基本的に英語

13. 技術的な話だけのディスカッションの
場合はそれほど難しい言葉は出てこない
（専門用語は別）。
簡単に直せるバグは説明や議論に使われ
る単語や言い回しも簡単なことが多い。

14. 仕様や設計思想に関わるディスカッション
↓
難しい話や慎重な議論が必要なものは、
必然的に使われる言葉が難しくなる

15. 結論が明らか（直したほうが良いことが明
らかなバグ）
↓
大体使われている単語も簡単

16. Typo は？
あっても大丈夫。でも、スペルチェッカーは有
効にしておくことは推奨。それだけでかなりミ
スが減る。
誤解を生むような typo はすぐに訂正を入れれ
ばよい（コメントを取り消せないことはみん
な知っているので）。

17. 今の自分の目標
１つも typo をせずにバグ登録か
ら修正完了までの処理を完了する
こと

18. 5. 作業時間
自分の場合は夜と休日の空き時間。
家庭も大事。休みの日全部をつぎ込むと理解が
得られなくなる。
実質的には土日で合計半日が限界。

19. でも、何もしないのと少しでも手を動かすのは
全然違う。

20. 6. 気になったバグを追いかける根気
興味を持った分野のバグか自分の見つけたバ
グが追いやすい。

21. 興味のある分野・主力分野を突付く。
・Windows の High Contrast で UI 部品の色が周囲と同じ
になって見えないバグ
・URL に変な文字を突っ込むとブラウザが誤動作する
・実質的に Web アプリと見なせるもののセキュリティ

22. 第 2 部：実際に直してみよう
実例(bug 660612)を参考に

23. 1.直すべき場所の見当をつける
・ 機能から想像される変数名でソース検索
MXR で検索できる（ http://mxr.mozilla.org/ ）
例：フォントの高さがウィンドウサイズより高い場合にページ
スクロールの量が極端に少ない(bug 383267)
→ fontHeight でソース検索

25. ・ 問題となる箇所に固定文字列があればそれでソースを検索する。
・ UI 系は DOM Inspector で見当をつけて、userChrome.css で試
してみる。
・ 国際化された文字列なら、リソースを検索してリソース名からあ
たりをつける
・ 自分が過去にパッチを書いたことがある部分は想像がつく
・ ディスカッション中にヒントが見つかることも

26. ・ bug660612 の場合
bug660612 : Utf8ToOneUcs4Char passes invalid UTF-8 octets '%ED%A0%80', so
decodeURIComponent('%ED%A0%80') doesn't throw
知ったきっかけは @Constellation さんのつぶやき

27. 後日バグの詳細がはてなへ
http://d.hatena.ne.jp/Constellation/20110530/1306759498

29. 問題のコード http://hg.mozilla.org/mozilla-central/file/e0ca895fde7e/js/src/jsstr.cpp#l5977

31. 何故特定できたか？
→以前パッチを書いた場所

32. http://hg.mozilla.org/mozilla-central/annotate/e0ca895fde7e/js/src/jsstr.cpp#l5977

33. 2.
直してビルド
手元のソースを修正してビルドする。
元の改行コードと文字コードを維持できる
エディタが必要(LF 改行対応必須)

34. 3.意図どおりに直ったかテスト
どうやってテストする？
↓
バグに添付されたテストケースで試す。
↓
良質なテストケースが無いと検証不能
↓
良いテストケースを書ける人は高評価

35. 4.リグレッションのチェック
他の機能へ影響が大きそうな場合は慎重に。
自動テストがある機能はテストを走らせて見る

36. 5.可能なら自動テストも書く
・自動テストが書いてあると話が早い
・リグレッションがあった時に Tinderbox が
炎上してすぐにわかる
↓
テストを書いて通るのを確認！！

37. 6.パッチをアップロード
・自動テストの配置するべき場所に自身が無
い
・なぜか hg diff で追加ファイルのパッチが出
ない
↓
jsstr.cpp は修正パッチとして登録

38. テストは単独ファイルで添付

40. テストは長いので省略

41. 7.レビュー
レビュワーは誰にするか
・ガイドラインは MDN に書いてある
・ CVS Blame や Hg Blame で自分が直した
場所にその前に手を入れたバグを探して、パ

42. ッチのレビュワーを探す

43. 今回は、前にパッチを書いたときと同じ
Jeff Walden さんにした

44. 8.指摘事項のある r+とコメント

46. 9.指摘対応その１
指摘事項
・自分なら２つの if を１つにまとめるね
・テストは decodeURIComponent("%ED%A0%80") が
URIError を投げることのチェックだけにして、余計なもの
を削って、js/src/tests/ecma_5/Global に置いてください。

47. 相変わらず hg diff で追加ファイルがパッチに
出ないので、仕方なくテストは手作業でパッチ
に変換。
パッチは変換ミスがあったので後で差異アッ
プロード

50. 10.指摘対応その２と 3
だいたいそのままなので日本語訳省略

51. ここでようやく
hg add ファイル名
をしないとパッチに新規ファイルが乗らないことに気づく
（MDN に書いて欲しい）

52. 書き直した部分

53. ここで 1 つミスをした。
指摘内容と比べてみよう

54. ( )の数がコメント内容と違ってます…orz
この指摘と修正を経てようやくコメントなし

55. r+がつきました。

56. 11.チェックインへ
コミッタじゃない人はチェックインできない
ので誰かにチェックインしてもらう

57. このコメントと一緒に
checkin? をセット
この間で checkin+ になった

58. 12.フォロー
・セキュリティホールなど、現行バージョンの
修正を検討するべきバグだった場合
↓
フラグやコメントで現行バージョンへの投入
が必要かどうか相談する
同じパッチが使えない場合は、各ブランチ用に
パッチを書く。

59. ・Seamonkey も気にする。
ブラウザ固有機能のバグなどでは、Firefox と
ほぼ同じコードが Seamonkey にも存在す
ることも多いので、そちらのケアもする。
・Rhino も気にする

60. JavaScript エンジンの場合は Rhino もチェ
ックしておく
Question?