Firefox/Geckoの開発環境 —20年続いているOSSプロジェクトの現在—

Firefox/Gecko
の開発環境
20年続いているOSSプロジェクト
の現在—

喋る人
✓なまえ: 中野雅之
✓株式会社 Birchill 所属
✓ Mozillaからの業務の委託を受けてFirefoxのGeckoエンジンを開発
✓担当モジュール
✓ Event Handling (共同モジュールオーナー)
✓ Editor (モジュールオーナー)
✓ Global Key Bindings (モジュールオーナー)
✓ 他、キーボード絡みのトラブル全般、デスクトップ版のIME関連バグ全
般
✓2000年頃からボランティアでバグ報告や報告内容の検証 (この
頃は大阪市内の会社でSIer)
✓2004年よりMozilla Japanでフルタイマとしてパッチを書き始める
✓2017年よりMozillaのcontractorとしてパッチを書き続ける
✓2019年より現職
Mozillaの方から来ただけなのでオフィシャルな内容で
はありません

Mozillaのブラウザ
◆Firefox
◆デスクトップ向け
◆Windows版、macOS版、Linux (GTK3)版
◆Geckoエンジン
◆UIもXUL/CSS/JSによるWebアプリケーションの一種
◆Firefox for Android (Fennec)
◆Android端末向け
◆開発終了
◆Geckoエンジン
◆UIはAndroidネイティブ
◆来年までGecko 68.0.xでセキュリティの修正は行われる
◆Firefox Preview (Fenix)
◆Android端末向け
◆Fennecをリプレースするために鋭意開発中
◆GeckoView
◆UIはKotlinで開発
◆GeckoViewはWebViewライクなAndroidコンポーネントでアプリがテスト済みの
バージョンを取り込んで配布できる
◆マルチプロセス化されてびっくりするほど高速化

◆Firefox for iOS
◆iPhone/iPad用
◆App Storeの制約によりGeckoではなくWebKit
◆拡張機能が使えない
◆Firefox Focus
◆Android版、iOS版
◆Android版はGeckoView、iOS版はWebKit
◆プライバシー保護を主目的に開発されたブラウザ
Mozillaのブラウザ

Mozillaの
ソースコード管理
⚫Geckoエンジンと、Firefox(Fennec含む)
⚫ Mercurialで管理されている
⚫ mozilla-central (開発用trunk、Nightlyチャンネル)
⚫ mozilla-beta (Betaチャンネル)
⚫ mozilla-release (Releaseチャンネル)
⚫ mozilla-esrNN (ESRブランチ、mozilla-esr68)
⚫ これら以外にもcomm-central等、ThunderbirdやSeaMonkey用のツリーも存在している
⚫ Gitでもアクセスできるようにクローンされ続けている
⚫ 詳細はMDN参照
⚫ GitでMercurialプロトコルを使えるgit-cinnabarを使って、gitで開発している
人も多い
⚫ Mozillaのglandiumさん作
⚫ Gitではなく、Mercurialを使っている理由
⚫ MozillaがCVSから移行を検討している段階ではGitがWindowsをサポートしていなかったらし
い
⚫Firefox Preview(Fenix)、Firefox for iOS、Firefox Focus
⚫ Gitで管理されている
⚫ Firefox Preview (Fenix)
⚫ Firefox for iOS
⚫ Firefox Focus for Android
⚫ Firefox Focus for iOS
⚫ 他にも新しいプロジェクトはだいたいGit
⚫ そしてこれらのプロジェクトではGitHubを中心に開発が行われている

このスライドでは、
GitHubを利用していない
GeckoエンジンとFirefoxの開発環境を
説明していきます。

Mozillaの
修正の流れ
1. Bugzillaにバグを報告する
2. ローカルにcloneした”mozilla-central”上でパッチを
書く
3. パッチをPhabricatorに提出
4. レビュアがDifferentialを使ってレビュー
5. Landoからパッチを”autoland”リポジトリにコミットす
る
6. 各修正ごとに自動テストが全て実行される
7. 日に二回、”mozilla-central”にマージされ、Nightlyビ
ルドが作成される
8. Bugzillaの”バグ”が”RESOLVED FIXED”とマークされ、
閉じられる

Mozilla製品のBTS
⚫Bugzilla
⚫Netscape社が社内で使っていたシステムが元になってい
る
⚫mozilla.orgが1998年に登場する際にオープンソースで公
開したBTS
⚫現在でも全てのMozilla製品のバグ報告を受け付けるため
のツールとして開発・改良が続いている

Bugzillaのホーム
とてもシンプルなホーム画面。
「とりあえず検索」というUI。

Bugzillaの”バグ”
Webが一般に広がりだしたころの
BBS(掲示板)にバグのステータスを
追加したようなUI。
複雑なステータス部分(上半分)は
普段は隠されていてユーザへの圧
迫感をできるだけ減らしている。

Bugzillaの
バグのステータス
ステータスを編集するために展開
すると非常に多項目(これでもまだ
一部は隠れている)。
開発者自身やマネージメントに都
合が良いようにフィールドが多数存
在している。

Bugzillaの
バグの依存関係
このスクリーンショットは、
”beforeinput”イベントを新規で追
加するためにどれだけのバグがこ
れまでに修正されたのか、どのよう
なバグをさらに修正していかないと
いけないのかを把握しやすい。

Bugzillaの
”Advanced Search”
バグのステータスが複雑な分、検
索項目も膨大だが、日常的に全て
を使うわけではない。
この例では2019年8月1日以降に
報告された標準以上の重要度を持
つ”DOM Events”に関わるバグを検
索できる。
プラットフォームや、報告者、担当
者といった項目でも検索可能。

Bugzillaの
検索結果
検索結果はこのようなリスト形式で
表示される。
表示される項目はユーザアカウン
トごとにカスタマイズ可能なので、
開発者にもマネージャにも使いや
すい。

Bugzillaの
バグ報告画面
まずはプロダクトを選択することで
入力フォームを簡素化している。

Bugzillaの
バグ報告時の
詳細入力画面
開発者自身がより細かいステータ
ス情報を入力するための”Show
Advanced Fields”ボタンも画面上部
に見られる。
コメントは最近、マークダウンに対
応。
単にBugzillaのアカウントを登録し
ただけだとより簡単なウィザード形
式の画面を利用することになる。

Bugzillaのまとめ
✓開発者、マネージャ等、それぞれの作業に対応するた
めに必要なステータス情報が多数存在している
✓各人の作業に関係ない情報はできるだけ隠してしまう
ことで可能な限りUIをシンプルにしている
✓さらに新規Bugzillaユーザのためにより簡素なUIも用
意されている
✓ダッシュボードとemail、どちらでも自分の進捗をマ
ネージメント可能(emailの場合、各項目の情報が独自
ヘッダで追加されているのでMUAによるフィルタリング
が容易)

Mozillaの
ソースコードを読む
1. 修正しないといけない場所を探さなくてはいけない
2. もちろん、ローカルにコピーしたソースコードを開い
て読んでいくこともありますが……
3. Searchfoxというツールでmozilla-central等、一部の
Gitでも提供されているソースコードをブラウザから
参照可能
1. インスタンスはsearchfox.org
2. アプリ自体はGitHubで公開

Searchfox.orgで
mozilla-central
フォルダやファイルの一覧が表示
される。
上部のフィールドから検索可能。

Searchfox.orgで
dom::KeyboardEvent
を検索
部分一致するクラスやメソッドをイ
ンデックスから探してきてくれる。
インデックスに存在しないものであ
ればプレーンテキストとして探して
きてくれる。

KeyboardEvent.
keyCodeの実装を
調べたい場合
ソースコード内のメソッド名をクリッ
クするとコンテキストメニューに”Go
to definition of …”と出てきて、ワン
クリックでジャンプできる。

KeyboardEvent.
keyCodeの実装を
調べたい場合
複数の行をハイライトしておい
て、”Permalink”から、そのリビジョ
ンへの永続URLが得られるので
Bugzilla等でのディスカッションにも
便利(何年後にそのURLを参照して
も、リビジョンが指定されているの
でディスカッション当時のソース
コードが参照できる)

KeyboardEvent::
KeyCodeの
callerを調べたい
ソースコード内のメソッド名をクリッ
クするとコンテキストメニュー
に”Search for function …”と出てき
て、ワンクリックで検索できる。
変数(クラスのメンバ変数含む)につ
いても参照箇所、設定箇所を検索
できる。

KeyboardEvent::
KeyCodeのcaller
を調べたい場合
インデックスを元に検索してくれるので、
別のクラスに`KeyCode`という名前のメソッ
ドがあっても検索結果には出ない(例えば
`Init`というメソッドを調べる時とかに便利)。
呼び出し元それぞれのメソッド名をクリッ
クするとその呼び出し元が検索できる(呼
び出されるスタックの一覧は得られないも
のの全ての呼び出し元を手軽に追いかけ
られる)。
ただし、JavaScriptでは(`this.`以外では)残
念ながら同名のfunctionが全て検索結果
に出てしまう。

ある行が何故、
いつ、追加された
のか
行頭にマウスカーソルを移動させ
ると直近のバグへのリンク、その際
のdiff、それが変更された際のリビ
ジョン、それが変更される直前のリ
ビジョンを表示させるポップアップ
が表示される。

Searchfoxの
仕組み
公式サイトの図が分かりやすい。
言語ごとにコンパイル・分析を行っ
てリンクを生成していくので単純な
テキスト検索では検索が難しい場
合には特に便利。

Mozillaのソース
コードをビルドす
る
⚫ビルド環境の構築方法はMDNで詳しく書かれている
⚫LinuxとmacOSではbootstrap.pyというファイルをダウンロー
ドして実行するだけ(macOSではXcodeのインストールが先
に必要)
⚫WindowsではVisual StudioとWindows 10 SDKのインストー
ルが必要
⚫ MSYS、Python等、ビルドに必要なツールを一式そろえたパッケージを
MozillaBuildとして用意しており、GUIでインストールできる
⚫ソースコードをMercurialでcloneした後に`./mach
bootstrap`コマンドを走らせるだけで、最新のclangやrust等
をセットアップしてくれる
⚫ FirefoxはWindowsでもclangでビルドされている
⚫ これらのアップデートが必要になった場合にもこのコマンドで行える
⚫ これにより、各開発者が同じバージョンのコンパイラを使って開発が行え
る体制になっている
⚫あとは`./mach build`するだけ

Mozillaの
自動テストを
走らせる
✓コマンドで自動テストを走らせることも可能
➢全てのテストを走らせるには何十時間も必要
➢全てのプラットフォームで長時間テストを走らせるのは事
実上不可能
➢そもそもテスト環境依存の微妙なテストも多い
➢ OSのバージョン依存
➢ DPI依存
➢ インストールされている何か依存
➢ インストールされていない何か依存
➢ランダムに失敗するテストもあってさらに大変
➢パフォーマンステストなんてさらに環境作りが無理
✓そうだ、クラウドにあるリファレンス環境で走らせよう
➢Try Server

MozillaのTry Server
1. コマンドで簡単にchooserを起動できる
➢ ./mach try chooser → ブラウザにUIが表示される

Try Server上の
ジョブの管理
treeherderというツールでブラウザから管
理できる。
失敗したら、オレンジ、もしくは赤で表示さ
れ、その詳細やデバッグビルドであればコ
ンソールへの出力結果もログファイルで
確認できる。
ランダムな失敗としてBugzillaに登録され
ているものが失敗の候補として表示もさ
れる。
この例では取り消し線が引かれた解決済
みのバグしか出てこないので自分のバグ
だと分かる。

Try Serverの構成
⚫各環境はDockerのイメージ
⚫Taskclusterというツールでジョブ管理
⚫これもMozillaのOSSプロダクト
⚫Treeherder
⚫これもMozillaのOSSプロダクト
⚫もちろん、TryServer上の成果物は順次削除されていく
➢ビルドされたバイナリはWebサーバに14日間だけ
➢Treeherderの情報は4ヵ月

Phabricator
Git/Mercurial/SVN対応のレビュー
ツール
PhacilityのOSSプロダクト。
Archanistというコマンドラインツー
ルからパッチをポストできる。
ただし、Arcanistは使いにくいので、
moz-phabやphalayというツールを
使ってより手軽にアクセスできるよ
うにもしている。

Phabricatorから
Bugzillaへ
自動ポスト
Phabricatorにポストする際に
BugzillaのバグIDを入力すると、そ
のバグへ”attachment”として自動
的にコミットメッセージと共にポスト
される。
これにより、バグ報告をトラッキン
グしておけばパッチの完成を知る
ことができる。

Differentialで
コードレビュー
インデントレベルの変更等も意識し
た、インラインレベルの変化を視覚
化してくれるDiffビューア。
インラインでコメントを追加すること
も、パッチ全体に対してコメントを
追加することも可能。

Landoで
自動チェックイン
複数の依存関係にあるパッチを同
時にチェックイン可能。
LandoもMozillaのOSSプロダクト。

“autoland”に
入ったパッチの
自動テスト
自動的に全てのプラットフォームでビ
ルドが行われ、自動テストも全て走る。
ランダムな失敗を除き、全てのテスト
に合格できなかったものはバックア
ウトされる。
パフォーマンステストも走るので、そ
のregressionが検知された場合には
バグとして報告される。
使われているインフラはTry Serverと
同じもの。

Mozillaの
修正の流れ
1. Bugzillaにバグを報告する
2. ローカルにcloneした”mozilla-central”上でパッチを
書く
3. パッチをPhabricatorに提出
4. レビュアがDifferentialを使ってレビュー
5. Landoからパッチを”autoland”リポジトリにコミットす
る
6. 各修正ごとに自動テストが全て実行される
7. 日に二回、”mozilla-central”にマージされ、Nightly
ビルドが作成される
8. Bugzillaの”バグ”が”RESOLVED FIXED”とマークされ、
閉じられる

Nightly Buildの
リリース
Landoからコミットされる”autoland”リポジトリはmozilla-
centralを安定化させるためのワンクッション。
”autoland”で全てのテストにパスすることを確認したも
のだけが一日に二回、”mozilla-central”にマージされ、
Nightly Buildの作成が始まる。
これが無かった時はmozilla-centralからpull/cloneしたリ
ビジョンがたまたまビルドすらできないものだったりする
ことがあり、数十分ビルドした後にがっかりすることが
多々あった。

Bugzillaのバグが
閉じられて終わり
“mozilla-central”にマージされると、
そのマージされた修正へのリンク
がバグに登録され、各種ステータ
スが更新される。

Mozillaの
開発環境の特徴
✓全てWebアプリとして提供されている
➢世界中の開発者がリモートで利用可能
➢自宅からでも開発可能
✓ツールで簡単に操作できるようにし、多くの開発者の時
間を無駄にしないようにしている
➢諸々の事情でサーバ側の仕様が変わっても教育コストを最小
限に抑えている
➢マニュアルをしっかりと用意しておくことにより、世界中のボラ
ンティア開発者が調べやすくなる
✓多くのツールを内製し、オープンソースプロダクトとして公
開している
➢多くの開発現場が同等の環境を作れる(かも?)
➢Mozillaのツールをうまく使えば働き方改革になる
かも?
➢ちなみに、私は先日、脊椎を骨折しましたが、これらのツールの
おかげでたったの一週間休むだけで仕事が再開できました
ヽ(´▽｀)ノ

Q&A?
※ただし、Geckoの開発者なので
サーバサイドの細かいことは全く
答えられません🙇

Firefox/Geckoの開発環境 —20年続いているOSSプロジェクトの現在—

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Firefox/Geckoの開発環境 —20年続いているOSSプロジェクトの現在—

Similar to Firefox/Geckoの開発環境 —20年続いているOSSプロジェクトの現在— (20)

Firefox/Geckoの開発環境 —20年続いているOSSプロジェクトの現在—