パッチを書いてみよう

masa

2011-07-23 Nseg 第 17 回勉強会

自己紹介

はてな：http://d.hatena.ne.jp/masa141421356

(id:masa141421356)

Twitter : @masa141421356

ほぼプログラマ。仕様の打ち合わせから実装まで全部やります。

Firefox のパッチって

どう書くの？

第１部：パッチを書くのに必要なもの

・Firefox のバイナリをビルドできる開発環境

・bugzill.mozilla.org のアカウント

・ Firefox で使用している技術(C++, JavaScript,

HTML, CSS, XUL, HTTP, etc.)の知識

・ 「ある程度」の英語力

・作業時間(これ重要)

・ 自分が気になったバグを追いかける根気

1. 開発環境

MDN 開発者ガイド　　 https://developer.mozilla.org/ja/Developer_Guide

殆どのツールは OS 付属か

無料ダウンロードで揃う。

SDK 揃えるのが面倒？

ま、ビンゴ揃えるつもりで

　(By Benjamin Smedberg)

http://benjamin.smedbergs.us/blog/2008-04-16/microsoft-header-bingo/

2. bugzilla.mozilla.org アカウント

メールアドレスがあれば OK

ログインしている人にはメールアドレスが見

えるので、英語 SPAM が嫌いな人は迷惑メー

ル対策の出来るアカウントでやるのがお勧め

3. 技術の知識

Firefox のソースはコアの部分は C++

UI は XML/HTML + JavaScript + CSS など。

UI 系だと画像を作るだけでよいバグもある

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

そのほかには

Web に関わる各種の標準 (HTTP, HTML,

XML, ECMAScript, CSS 等)

OS の標準的なアプリケーションのガイドラ

インや API の知識

あと、Mozilla のコーディングスタイルガイ

ドライン。大体周辺のコードのスタイルに合

わせれば OK。

技術を全部知っていなくてもパッチは書け

る。

4. 「ある程度」の英語力

　bugzilla.mozilla.org のディスカッションは

基本的に英語

技術的な話だけのディスカッションの

場合はそれほど難しい言葉は出てこない

（専門用語は別）。

簡単に直せるバグは説明や議論に使われ

る単語や言い回しも簡単なことが多い。

仕様や設計思想に関わるディスカッション

　　↓難しい話や慎重な議論が必要なものは、

必然的に使われる言葉が難しくなる

結論が明らか（直したほうが良いことが明

らかなバグ）

　　　↓

大体使われている単語も簡単

Typo は？

あっても大丈夫。でも、スペルチェッカーは有

効にしておくことは推奨。それだけでかなりミ

スが減る。

誤解を生むような typo はすぐに訂正を入れれ

ばよい（コメントを取り消せないことはみん

な知っているので）。

今の自分の目標

　１つも typo をせずにバグ登録か

ら修正完了までの処理を完了する

こと

5. 作業時間

自分の場合は夜と休日の空き時間。

家庭も大事。休みの日全部をつぎ込むと理解が

得られなくなる。

実質的には土日で合計半日が限界。

でも、何もしないのと少しでも手を動かすのは

全然違う。

6. 気になったバグを追いかける根気

興味を持った分野のバグか自分の見つけたバ

グが追いやすい。

興味のある分野・主力分野を突付く。

・Windows の High Contrast で UI 部品の色が周囲と同じ

になって見えないバグ

・URL に変な文字を突っ込むとブラウザが誤動作する

・実質的に Web アプリと見なせるもののセキュリティ

第 2 部：実際に直してみよう

　実例(bug 660612)を参考に

1.直すべき場所の見当をつける

・ 機能から想像される変数名でソース検索

MXR で検索できる（ http://mxr.mozilla.org/ ）

　　例：フォントの高さがウィンドウサイズより高い場合にページ

スクロールの量が極端に少ない(bug 383267)

　　　　→ fontHeight でソース検索

・ 問題となる箇所に固定文字列があればそれでソースを検索する。

・ UI 系は DOM Inspector で見当をつけて、userChrome.css で試

してみる。

・ 国際化された文字列なら、リソースを検索してリソース名からあ

たりをつける

・ 自分が過去にパッチを書いたことがある部分は想像がつく

・ ディスカッション中にヒントが見つかることも

・ bug660612 の場合

bug660612 : Utf8ToOneUcs4Char passes invalid UTF-8 octets '%ED%A0%80', so decodeURIComponent('%ED%A0%80') doesn't throw

知ったきっかけは @Constellation さんのつぶやき

後日バグの詳細がはてなへ

http://d.hatena.ne.jp/Constellation/20110530/1306759498

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

何故特定できたか？

　→以前パッチを書いた場所

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

2. 直してビルド

　　手元のソースを修正してビルドする。

　　

元の改行コードと文字コードを維持できる

エディタが必要(LF改行対応必須)

3.意図どおりに直ったかテスト

　どうやってテストする？↓

バグに添付されたテストケースで試す。

　　↓

良質なテストケースが無いと検証不能

　　↓

良いテストケースを書ける人は高評価

4.リグレッションのチェック

他の機能へ影響が大きそうな場合は慎重に。

　

自動テストがある機能はテストを走らせて見る

5.可能なら自動テストも書く

・自動テストが書いてあると話が早い

・リグレッションがあった時に Tinderbox が

炎上してすぐにわかる

　　　↓

　テストを書いて通るのを確認！！

6.パッチをアップロード

・自動テストの配置するべき場所に自身が無

い

・なぜか hg diff で追加ファイルのパッチが出

ない

　　　　↓

jsstr.cpp は修正パッチとして登録

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

テストは長いので省略

7.レビュー

レビュワーは誰にするか

・ガイドラインは MDN に書いてある

・CVS Blame や Hg Blame で自分が直した

場所にその前に手を入れたバグを探して、パ

ッチのレビュワーを探す

　今回は、前にパッチを書いたときと同じ

Jeff Waldenさんにした

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

9.指摘対応その１

指摘事項

・自分なら２つの if を１つにまとめるね

・テス ト は decodeURIComponent("%ED%A0%80") が

URIError を投げることのチェックだけにして、余計なもの

を削って、js/src/tests/ecma_5/Global に置いてください。

　相変わらず hg diff で追加ファイルがパッチに

出ないので、仕方なくテストは手作業でパッチ

に変換。

　パッチは変換ミスがあったので後で差異アッ

プロード

10.指摘対応その２と 3

　だいたいそのままなので日本語訳省略

ここでようやく

をしないとパッチに新規ファイルが乗らないことに気づく

（MDN に書いて欲しい）

hg add ファイル名

書き直した部分

ここで 1 つミスをした。

指摘内容と比べてみよう

(　)の数がコメント内容と違ってます…orz

この指摘と修正を経てようやくコメントなし

r+がつきました。

11.チェックインへ

コミッタじゃない人はチェックインできない

ので誰かにチェックインしてもらう

このコメントと一緒に

checkin? をセット

この間で checkin+ になった

12.フォロー・セキュリティホールなど、現行バージョンの

修正を検討するべきバグだった場合

　　　　↓

フラグやコメントで現行バージョンへの投入

が必要かどうか相談する

同じパッチが使えない場合は、各ブランチ用に

パッチを書く。

・Seamonkey も気にする。

　ブラウザ固有機能のバグなどでは、Firefox と

ほぼ同じコードが Seamonkey にも存在す

ることも多いので、そちらのケアもする。

　　　

・Rhino も気にする

JavaScriptエンジンの場合は Rhino もチェ

ックしておく

　　Question?