initial commit

1 files changed, 515 insertions, 0 deletions

diff --git a/files/ja/gecko_hacking_tutorial/index.html b/files/ja/gecko_hacking_tutorial/index.html
new file mode 100644
index 0000000000..9f629d8b26
--- /dev/null
+++ b/files/ja/gecko_hacking_tutorial/index.html
@@ -0,0 +1,515 @@
+---
+title: Gecko hacking tutorial
+slug: Gecko_hacking_tutorial
+---
+<div class="note">
+<p>現在、このページは <a>Gyuque</a> により執筆途中です。内容が頻繁に変わりますのでご注意ください。
+</p>
+</div>
+<h2 id=".E3.81.AF.E3.81.98.E3.82.81.E3.81.AB" name=".E3.81.AF.E3.81.98.E3.82.81.E3.81.AB"> はじめに </h2>
+<p>この文書は、Mozilla の心臓部である <a href="ja/Gecko">Gecko</a> を Hack するための手順を紹介します。
+</p>
+<h2 id=".E6.BA.96.E5.82.99" name=".E6.BA.96.E5.82.99"> 準備 </h2>
+<h3 id=".E7.92.B0.E5.A2.83" name=".E7.92.B0.E5.A2.83"> 環境 </h3>
+<p>この文書は、以下の環境を想定しています。
+</p>
+<table class="standard-table"> <tbody><tr>
+<th>OS
+</th><td>Microsoft Windows
+</td></tr> <tr>
+<th>コンパイラ
+</th><td>Microsoft Visual Studio.NET 2003
+</td></tr> <tr>
+<th>対象となるMozilla
+</th><td>Mozilla Firefox 2.0.0.2 (Gecko 1.8.1.2)
+</td></tr>
+</tbody></table>
+<h3 id=".E3.82.BD.E3.83.BC.E3.82.B9.E3.82.B3.E3.83.BC.E3.83.89.E3.81.AE.E5.8F.96.E5.BE.97" name=".E3.82.BD.E3.83.BC.E3.82.B9.E3.82.B3.E3.83.BC.E3.83.89.E3.81.AE.E5.8F.96.E5.BE.97"> ソースコードの取得 </h3>
+<p>何よりもまず、Mozilla のソースコードが必要です。この記事では、（この記事の執筆時点で）Firefoxの最新リリースである Firefox 2.0.0.2 を使用します。Firefox 2.0.0.2 のソースコードは、以下から入手可能です。
+</p><p><a class=" external" href="http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.2/source/" rel="freelink">http://ftp.mozilla.org/pub/mozilla.o....0.0.2/source/</a>
+</p><p>ソースコードはbzipアーカイブです。後で展開作業を行いますので、適当な場所に保存しておいてください。
+</p>
+<h3 id=".E3.82.B3.E3.83.B3.E3.83.91.E3.82.A4.E3.83.A9.E3.81.AE.E6.BA.96.E5.82.99" name=".E3.82.B3.E3.83.B3.E3.83.91.E3.82.A4.E3.83.A9.E3.81.AE.E6.BA.96.E5.82.99"> コンパイラの準備 </h3>
+<p><a href="ja/Windows_Build_Prerequisites">Windows Build Prerequisites</a>によると、この記事が対象としている Firefox 2.0.x をビルドするためには、Visual Studio 6 か .NET 2002 (7.0)、もしくは .NET 2003 (7.1) が必要です。これらはすべて旧バージョンです。最新版である Visual Studio 2005 (8.0) は無償で配布されていますが、これでビルドを試みても、どこかで失敗するでしょう。
+</p><p>旧バージョンの Visual Studio を入手する手順は少々面倒です。最新版 (2005) のライセンスを購入した上で、Microsoft からインストール用のディスクを購入する必要があります。
+もしあなたが、学生や研究者ならば、ソフトウェアの管理者に相談してみてください。あなたの研究室（等）が <abbr title="MSDN Academic Alliance">MSDNAA</abbr> を契約していれば、旧バージョンの Visual Studio のインストールディスクがあるかもしれません。
+</p><p>無事ライセンスとインストールディスクを入手したら、通常通りの手順でインストールしてください。もちろん、Visual C++ をインストールするのを忘れずに！
+</p>
+<h3 id="MASM32.E3.81.AE.E6.BA.96.E5.82.99" name="MASM32.E3.81.AE.E6.BA.96.E5.82.99"> MASM32の準備 </h3>
+<p><a href="ja/Windows_Build_Prerequisites">Windows Build Prerequisites</a>にはなぜか記述がありませんが、Mozilla のコードにはアセンブリも含まれているので、ビルドの過程でアセンブラが必要となります。この記事では、 MASM32 というアセンブラを使用します。MASM32 は、以下から入手可能です。
+</p><p><a class=" external" href="http://www.masm32.com/" rel="freelink">http://www.masm32.com/</a>
+</p><p>MASM32 をどこにインストールしても構いませんが、環境変数の設定の際に <code>PATH</code> を通すことを忘れないでください。
+</p>
+<h3 id=".E3.81.9D.E3.81.AE.E4.BB.96.E3.81.AE.E6.BA.96.E5.82.99" name=".E3.81.9D.E3.81.AE.E4.BB.96.E3.81.AE.E6.BA.96.E5.82.99"> その他の準備 </h3>
+<p>引き続き、<a href="ja/Windows_Build_Prerequisites">Windows Build Prerequisites</a>を参照しながら Cygwin と moztools のインストールと環境変数の設定を行ってください。Cygwin のインストールに際しては、make のバージョンに気をつけてください。
+</p>
+<h3 id=".E8.A8.AD.E5.AE.9A.E4.BE.8B" name=".E8.A8.AD.E5.AE.9A.E4.BE.8B"> 設定例 </h3>
+<p>以下は、筆者の Cygwin.bat です。
+</p>
+<pre>set HOME=C:\cygwin\home\satoshi_ueyama
+set VCVARS=C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat
+set MSSDK=C:\Program Files\Microsoft Platform SDK
+set MOZ_TOOLS=C:\moztools
+set CYGWINBASE=C:\cygwin
+set CYGWIN=nodosfilewarning
+set PATH=%PATH%;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin
+
+call "%VCVARS%"
+set PATH=%PATH%;%MOZ_TOOLS%\bin;C:\masm32\bin
+
+@echo off
+
+C:
+chdir C:\cygwin\bin
+
+bash --login -i
+</pre>
+<p>ここまで準備したもの—Visual Studio、MASM32、moztools—が到達可能になっていますね？ もしビルドの途中で何かが見つからないと文句を言われたら、ここを見直してください。
+</p>
+<h2 id=".E6.9C.80.E5.88.9D.E3.81.AE.E3.83.93.E3.83.AB.E3.83.89" name=".E6.9C.80.E5.88.9D.E3.81.AE.E3.83.93.E3.83.AB.E3.83.89"> 最初のビルド </h2>
+<h3 id=".E3.82.A2.E3.83.BC.E3.82.AB.E3.82.A4.E3.83.96.E3.81.AE.E5.B1.95.E9.96.8B" name=".E3.82.A2.E3.83.BC.E3.82.AB.E3.82.A4.E3.83.96.E3.81.AE.E5.B1.95.E9.96.8B"> アーカイブの展開 </h3>
+<p>まず、前章で取得した firefox-2.0.0.2-source.tar.bz2 をどこかに配置しましょう。この記事では、C:\ 直下に mozhackというディレクトリを作成し、そこに firefox-2.0.0.2-source.tar.bz2 をコピーしました。Explorer で見ると以下のような状態です:
+</p><p><img alt="画像:Mh_001.png">
+</p><p>さて、Cygwinのコンソールを起動し、このディレクトリに移動します。C: ドライブは、 /cygdrive/c 以下にマウントされていますので、mozhack ディレクトリに移動するためには:
+</p>
+<pre>cd /cygdrive/c/mozhack/
+</pre>
+<p>と入力します。移動したらlsしてみてください。firefox-2.0.0.2-source.tar.bz2 がありましたか？
+では、アーカイブを展開しましょう。展開のためのコマンドは以下のとおりです:
+</p>
+<pre>tar xjfv firefox-2.0.0.2-source.tar.bz2
+</pre>
+<p>これは少し時間がかかります。この間にちょっと別の作業をしましょう。
+</p>
+<h3 id=".28.E3.82.AA.E3.83.97.E3.82.B7.E3.83.A7.E3.83.B3.29cygwin.E3.81.AE.E8.BF.BD.E5.8A.A0.E8.A8.AD.E5.AE.9A" name=".28.E3.82.AA.E3.83.97.E3.82.B7.E3.83.A7.E3.83.B3.29cygwin.E3.81.AE.E8.BF.BD.E5.8A.A0.E8.A8.AD.E5.AE.9A"> (オプション)cygwinの追加設定 </h3>
+<p>毎回、Cygwin を起動するたびにディレクトリを移動するのは煩わしいことです。そこで、自動的に移動を行うように設定しましょう。C:\cygwin\home\_YOUR_NAME_ に .bashrc というファイルがありますね？ その末尾に以下の行を追加してください:
+</p>
+<pre>cd /cygdrive/c/mozhack/mozilla
+</pre>
+<p>mozilla というディレクトリは、前節での展開作業で生成される（筈の）ディレクトリです。ここが make を行う場所になります。
+</p><p>あとついでに、cygwin.batへのショートカットをスタートメニューに追加して、Cygwin の冴えないアイコンを Pop なものに変えておきましょう。
+</p><p><img alt="画像:Mh_002.png">
+</p>
+<h3 id=".E5.B1.95.E9.96.8B.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.81.AE.E7.A2.BA.E8.AA.8D" name=".E5.B1.95.E9.96.8B.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.81.AE.E7.A2.BA.E8.AA.8D"> 展開ファイルの確認 </h3>
+<p>さて、そろそろ展開作業が終わりましたか？
+正しく展開されていれば、mozilla というディレクトリが作成され、その中にいろいろなファイルやディレクトリがある筈です。Explorer のフォルダツリーで見ると以下のような状態です:
+</p><p><img alt="画像:Mh_003.png">
+</p><p>元のアーカイブ firefox-2.0.0.2-source.tar.bz2 は必要ないので削除しましょう。
+</p>
+<h3 id=".E3.83.93.E3.83.AB.E3.83.89.E3.81.AE.E8.A8.AD.E5.AE.9A" name=".E3.83.93.E3.83.AB.E3.83.89.E3.81.AE.E8.A8.AD.E5.AE.9A"> ビルドの設定 </h3>
+<p>いよいよビルド！ —の前に、少しばかり設定をする必要があります。mozilla ディレクトリ内に、.mozconfig というファイルを作成してください。 Explorer は、ピリオドで始まるファイルを作成しようとすると失敗しますので、Cygwin のコンソールから <code>touch</code> コマンドを利用するのがよいでしょう。.mozconfig には、何をどのようにビルドするかを記述します。
+</p><p>我々が普段使用している Firefox と同じものをビルドするための設定は以下の通りです:
+</p>
+<pre>mk_add_options MOZ_CO_PROJECT=browser
+mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
+ac_add_options --enable-application=browser
+ac_add_options --enable-optimize
+ac_add_options --disable-tests
+ac_add_options --disable-debug
+ac_add_options --enable-svg
+ac_add_options --enable-svg-renderer-gdiplus
+ac_add_options --disable-activex
+ac_add_options --disable-activex-scripting
+ac_add_options --disable-shared
+ac_add_options --enable-static
+</pre>
+<p>適当なエディタで .mozconfig に以上の内容を記述し、保存してください。
+</p>
+<h3 id=".E3.83.93.E3.83.AB.E3.83.89" name=".E3.83.93.E3.83.AB.E3.83.89"> ビルド </h3>
+<p>今度こそビルドです。まずは configure をしましょう:
+</p>
+<pre>./configure --disable-installer
+</pre>
+<p>ここで重要なのは <code>--disable-installer</code> オプションです。読んで字の如く、インストーラの生成を無効にするオプションです。インストーラを生成するためには、さらにいろいろと必要なものがあります。手順を簡略化するために、インストーラの生成を行わないことにします。
+</p><p>さあ、configure は無事に終わりましたか？ 初挑戦でこれが一発で終われば大したものです。
+</p><p>続いて make です。ここでは単に make と入力しましょう:
+</p>
+<pre>make
+</pre>
+<p>これはとても時間がかかります！ （なるべく薄い）コーヒーでも飲みながら待ちましょう。
+</p>
+<h3 id=".E5.AE.9F.E8.A1.8C" name=".E5.AE.9F.E8.A1.8C"> 実行 </h3>
+<p>何もエラーが出ずに make が終了しましたか？ では、いよいよ出来たての Firefox を実行しましょう。完成したバイナリは、mozilla/dist/bin 以下にあります。お馴染みの Firefox.exe がありますね？ 早速起動しましょう。見慣れた画面が表示されるでしょう:
+</p><p><img alt="画像:Mh_004.png">
+</p>
+<h2 id=".E3.83.87.E3.83.90.E3.83.83.E3.82.B0.E7.89.88.E3.81.AE.E3.83.93.E3.83.AB.E3.83.89" name=".E3.83.87.E3.83.90.E3.83.83.E3.82.B0.E7.89.88.E3.81.AE.E3.83.93.E3.83.AB.E3.83.89"> デバッグ版のビルド </h2>
+<p>さて、最初に皆様に謝らなくてはいけません。前章で作成したビルドはリリース版で、Hack に向いていません。気持ちよく Hack するためには、デバッグ版のビルドが必要ですので、もう一度ビルドをやり直します。どうかもう小一時間お付き合いを！
+</p>
+<h3 id=".E3.83.93.E3.83.AB.E3.83.89.E8.A8.AD.E5.AE.9A.E3.81.AE.E5.A4.89.E6.9B.B4" name=".E3.83.93.E3.83.AB.E3.83.89.E8.A8.AD.E5.AE.9A.E3.81.AE.E5.A4.89.E6.9B.B4"> ビルド設定の変更 </h3>
+<p>先ほど作成した .mozconfig を以下のように変更してください。
+</p>
+<pre>mk_add_options MOZ_CO_PROJECT=browser
+mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
+ac_add_options --enable-application=browser
+ac_add_options --disable-optimize
+ac_add_options --disable-tests
+ac_add_options --enable-debug
+ac_add_options --enable-svg
+ac_add_options --enable-svg-renderer-gdiplus
+ac_add_options --disable-activex
+ac_add_options --disable-activex-scripting
+</pre>
+<p>debug 用のコードが有効になり、最適化が無効になりました。また、実行時に共有ライブラリを使用するようになりました。共有ライブラリの使用は、コード変更後の再ビルドを劇的に速くします。
+</p><p>さらに、Cygwin のコンソールから以下のように入力してください:
+</p>
+<pre>export MOZ_DEBUG_SYMBOLS=1
+</pre>
+<p>この指定により、make は、デバッグ用のシンボルデータベース (pdb) を作成します（というより、作成したものを破棄しなくなります）。これにより、デバッガからソースコードを参照することができます。
+</p>
+<h3 id=".E3.83.93.E3.83.AB.E3.83.89_2" name=".E3.83.93.E3.83.AB.E3.83.89_2"> ビルド </h3>
+<p>では、もう一度ビルドを行います。まず、リリースビルドのファイルを消しておきましょう:
+</p>
+<pre>make clean
+</pre>
+<p>続いて configure と make です:
+</p>
+<pre>./configure --disable-installer
+make
+</pre>
+<h3 id=".E5.AE.9F.E8.A1.8C_2" name=".E5.AE.9F.E8.A1.8C_2"> 実行 </h3>
+<p>前回と同様に、mozilla/dist/bin/Firefox.exe を実行します。今回は、見慣れているものとは少し違う Firefox が起動する筈です。Debug 版のスクリーンショットを以下に示します:
+</p><p><img alt="画像:Mh_005.png">
+</p><p>通常のウィンドウのほかに、コンソールが表示されています。また、通常の Firefox より少し動作が遅いことにも気づくでしょう。これらは、あなたが Debug 版のビルドに成功したことを示しています。
+</p>
+<h2 id=".E3.83.87.E3.83.90.E3.83.83.E3.82.AC.E3.81.AE.E4.BD.BF.E7.94.A8" name=".E3.83.87.E3.83.90.E3.83.83.E3.82.AC.E3.81.AE.E4.BD.BF.E7.94.A8"> デバッガの使用 </h2>
+<p>デバッガは、プログラムの動作を追跡し、解析するためのツールです。デバッガを使用して Firefox を解析することは、この巨大なシステムの構造を理解する大きな手助けとなるでしょう。
+</p>
+<h3 id=".E3.83.87.E3.83.90.E3.83.83.E3.82.AC.E3.81.AE.E8.A8.AD.E5.AE.9A" name=".E3.83.87.E3.83.90.E3.83.83.E3.82.AC.E3.81.AE.E8.A8.AD.E5.AE.9A"> デバッガの設定 </h3>
+<p>この記事では、デバッガとして Visual Studio を使用します。通常、Visual Studio を使用した開発では、コーディングとビルド、およびデバッグをすべて Visual Studio 上で行い、この場合はデバッガの設定は自動的に行われます。しかし我々は、Visual Studio の外でビルドされたプログラムを Visual Studio でデバッグするという変則的な事を行おうとしています。よって、少々設定を行う必要があります。
+</p>
+<h4 id=".E3.83.97.E3.83.AD.E3.82.B8.E3.82.A7.E3.82.AF.E3.83.88.E3.81.AE.E4.BD.9C.E6.88.90" name=".E3.83.97.E3.83.AD.E3.82.B8.E3.82.A7.E3.82.AF.E3.83.88.E3.81.AE.E4.BD.9C.E6.88.90"> プロジェクトの作成 </h4>
+<p>まず、空のソリューションとプロジェクトを作成します。「ファイル」メニューから「新規作成」→「プロジェクト...」を選択するか、<kbd>Ctrl+Shift+N</kbd> を押下してください。ウィザード形式のウィンドウが表示されますので、次図のように設定してください:
+</p><p><img alt="画像:Mh_006.png">
+</p><p>まず、適当なプロジェクト名を入力してください。この例では「tutorial1」としました。そして、プロジェクトを生成する場所を指定してください。この例では、C:\mozhack としました（実際は、この下にさらにディレクトリが生成され、そこに格納されます）。
+</p><p>次に、プロジェクトの詳細設定を行います。少しわかりにくいですが、ウィンドウの左側にタブがあります。そこから「アプリケーションの設定」タブを選択し、「空のプロジェクト」にチェックを入れてください。チェックを入れたら「完了」ボタンを選択してください。
+</p>
+<h4 id=".E3.83.97.E3.83.AD.E3.82.B8.E3.82.A7.E3.82.AF.E3.83.88.E3.81.AE.E8.A8.AD.E5.AE.9A" name=".E3.83.97.E3.83.AD.E3.82.B8.E3.82.A7.E3.82.AF.E3.83.88.E3.81.AE.E8.A8.AD.E5.AE.9A"> プロジェクトの設定 </h4>
+<p>前項で作成したプロジェクトの設定を行います。「ソリューションエクスプローラ」の中から、プロジェクト（ソリューションではなく！）のアイコンを右クリックし、コンテキストメニューから「プロパティ」を選択してください。次図のようなプロジェクトのプロパティダイアログが表示されます:
+</p><p><img alt="画像:Mh_007_VSProject.png">
+</p><p>左側のリストから「デバッグ」セクションを選択し、「コマンド」の欄にFirefoxの実行ファイルを指定してください。続いて、「OK」ボタンを選択してください。
+</p>
+<h3 id=".E3.83.87.E3.83.90.E3.83.83.E3.82.B0.E9.96.8B.E5.A7.8B" name=".E3.83.87.E3.83.90.E3.83.83.E3.82.B0.E9.96.8B.E5.A7.8B"> デバッグ開始 </h3>
+<p>いよいよデバッガを起動します。ツールバーの開始ボタン（青い三角のアイコン）を選択するか、F5キーを押下してください。Firefox が起動する筈です。
+</p><p>Firefox の起動途中にデバッガが終了してしまう（Visual Studio の画面のレイアウトが元に戻ります）場合があります。この場合は、一度 Firefox を終了してからやり直してください。
+</p>
+<h3 id=".E3.83.96.E3.83.AC.E3.83.BC.E3.82.AF.E3.83.9D.E3.82.A4.E3.83.B3.E3.83.88.E3.81.AE.E8.A8.AD.E5.AE.9A" name=".E3.83.96.E3.83.AC.E3.83.BC.E3.82.AF.E3.83.9D.E3.82.A4.E3.83.B3.E3.83.88.E3.81.AE.E8.A8.AD.E5.AE.9A"> ブレークポイントの設定 </h3>
+<p>ブレーク機能は、デバッガの強力な機能の一つです。ブレーク機能を使用すると、プログラム上の任意の場所で実行を中断し、プログラム内部の状態を観察することができます。
+</p><p>早速、適当な場所にブレークポイント（ブレークを行う場所）を設定します。Mozilla のソースツリーの中から、 mozilla/content/html/content/src/nsHTMLDivElement.cpp を Visual Studio で開いてください。ファイルを開いたら、コンストラクタ <code>nsHTMLDivElement::nsHTMLDivElement(nsINodeInfo *aNodeInfo)</code> にブレークポイントを設定します。83行目の左端の欄をクリックしてください。赤い印がつきましたか？ では、Firefox で適当なページを開いてください。<a class=" external" href="http://www.mozilla.org/" rel="freelink">http://www.mozilla.org/</a> がよいでしょう。
+</p><p>ここまでの手順が正しければ、Firefox の実行が中断され、Visual Studio のウィンドウが表示されるでしょう。今、あなたは、変数の内容やコールスタック（関数の呼び出しの経路）を覗いたり、一行ずつプログラムを実行するといったことができます。
+</p>
+<h3 id=".E3.82.BD.E3.83.BC.E3.82.B9.E3.82.B3.E3.83.BC.E3.83.89.E3.82.92.E8.BF.BD.E3.81.86" name=".E3.82.BD.E3.83.BC.E3.82.B9.E3.82.B3.E3.83.BC.E3.83.89.E3.82.92.E8.BF.BD.E3.81.86"> ソースコードを追う </h3>
+<p>Mozilla は巨大なプログラムです。手練のプログラマであっても、コードを見ただけで全体の構造を理解することは難しいでしょう。しかし今、デバッガを使用し、実際にプログラムを動作させながらコードを追うことが可能になりました。少しずつコードを追いながら、Mozilla の構造を見ていくとよいでしょう。本節では、デバッガを使用してソースコードを追う手順を紹介します。
+</p>
+<h4 id=".E3.82.B3.E3.83.BC.E3.83.AB.E3.82.B9.E3.82.BF.E3.83.83.E3.82.AF" name=".E3.82.B3.E3.83.BC.E3.83.AB.E3.82.B9.E3.82.BF.E3.83.83.E3.82.AF"> コールスタック </h4>
+<p>前節でブレークした状態を維持してありますか？ 終了してしまった場合は、もう一度実行して同じ場所でブレークしてください。あなたが Visual Studio の設定を特に変更していなければ、Visual Studio のウィンドウの右下に「呼び出し履歴」というペインがあるでしょう。次図に「呼び出し履歴」ペインを示します:
+</p><p><img alt="画像:Mh_008_callstack.png">
+</p><p>「呼び出し履歴」は、コールスタックとも呼ばれます。コールスタックは、ブレークを設定した処理がどこから呼ばれたのかを記録しています。いま、<code>nsHTMLDivElement</code> 関数（コンストラクタ）が最上段に表示されています。その下には <code>NS_NewHTMLDivElement</code> 関数が表示されています。これは、<code>NS_NewHTMLDivElement</code> 関数が <code>nsHTMLDivElement</code> 関数を呼び出したことを示しています。<code>NS_NewHTMLDivElement</code> 関数のある段をダブルクリックすると、その関数の定義にジャンプします。<code>NS_NewHTMLDivElement</code> 関数の定義は以下のようなものです:
+</p>
+<pre>NS_IMPL_NS_NEW_HTML_ELEMENT(Div)
+</pre>
+<p><code>NS_NewHTMLDivElement</code> 関数は、マクロで実装されているようです。このマクロの内容を追ってもよいのですが、この関数の機能は、名前から自明です。これ以上調べても、あまり面白い事実はないでしょう。
+</p><p>さらにコールスタックを辿りましょう。3段目の <code>MakeContentObject</code> 関数にジャンプしてください。ジャンプ先のコードの一部を次に示します:
+</p>
+<pre class="eval"> if (aNodeType == eHTMLTag_form) {
+   if (aForm) {
+     // the form was already created
+     NS_ADDREF(aForm);
+     return aForm;
+   }
+   nsGenericHTMLElement* result = NS_NewHTMLFormElement(aNodeInfo);
+   NS_IF_ADDREF(result);
+   return result;
+ }
+
+ contentCreatorCallback cb = sContentCreatorCallbacks[aNodeType];
+
+ NS_ASSERTION(cb != NS_NewHTMLNOTUSEDElement,
+              "Don't know how to construct tag element!");
+
+ <span class="highlightred">nsGenericHTMLElement* result = cb(aNodeInfo, aFromParser);</span>
+</pre>
+<p>上に掲載したコードの最後の行（ハイライトしてあります）でブレークしている筈です。しかし、<code>NS_NewHTMLDivElement</code> という関数名が見当たりません。コードを注意深く見ると、どうやら <code>sContentCreatorCallbacks</code> という配列（のように見えるもの）に、要素を生成する関数の一覧が格納されているようです。<code>NS_NewHTMLDivElement</code> 関数もその中にあるのでしょう。
+</p><p><code>sContentCreatorCallbacks</code> の正体は何でしょうか。プレフィックスから、これが static なグローバル変数であると推測できます。つまり、現在見ているファイル (nsHTMLContentSink.cpp) の中で宣言されている可能性が高いということです。<kbd>Ctrl+F</kbd> を押下し、「sContentCreatorCallbacks」を検索してみましょう。すると192行目の辺りに以下のようなコードがあります:
+</p>
+<pre>#define HTML_TAG(_tag, _classname) NS_NewHTML##_classname##Element,
+#define HTML_OTHER(_tag) NS_NewHTMLNOTUSEDElement,
+static const contentCreatorCallback sContentCreatorCallbacks[] = {
+  NS_NewHTMLUnknownElement,
+#include "nsHTMLTagList.h"
+#undef HTML_TAG
+#undef HTML_OTHER
+  NS_NewHTMLUnknownElement
+};
+</pre>
+<p>どうやら、<code>sContentCreatorCallbacks</code> の正体は単純な配列のようです。しかし、配列の要素の宣言は少々トリッキーです。とりあえず、<code>#include</code> ディレクティブで参照されている <code>nsHTMLTagList.h</code> を開きましょう。nsHTMLTagList.h は、mozilla/parser/htmlparser/public にあります。<code>nsHTMLTagList.h</code> の内容の一部を次に示します:
+</p>
+<pre>HTML_TAG(a, Anchor)
+HTML_TAG(abbr, Span)
+HTML_TAG(acronym, Span)
+HTML_TAG(address, Span)
+HTML_TAG(applet, Applet)
+
+...(中略)...
+
+HTML_TAG(tr, TableRow)
+HTML_TAG(tt, Span)
+HTML_TAG(u, Span)
+HTML_TAG(ul, SharedList)
+HTML_TAG(var, Span)
+HTML_TAG(wbr, Shared)
+HTML_TAG(xmp, Span)
+
+
+/* These are not for tags. But they will be included in the nsHTMLTag
+   enum anyway */
+
+HTML_OTHER(text)
+HTML_OTHER(whitespace)
+HTML_OTHER(newline)
+HTML_OTHER(comment)
+HTML_OTHER(entity)
+HTML_OTHER(doctypeDecl)
+HTML_OTHER(markupDecl)
+HTML_OTHER(instruction)
+</pre>
+<p>nsHTMLContentSink.cpp のコードと併せて読むと、このコードのからくりが解ります。nsHTMLContentSink.cpp では、 nsHTMLTagList.h を include する直前で <code>HTML_TAG</code> と <code>HTML_OTHER</code> という2つのマクロを定義しています。どうやら、nsHTMLTagList.h の内容をマクロで書き換えることにより、<code>NS_NewHTML**Element</code> 関数へのポインタを動的に生成し、配列に追加しているようです。このように、C や C++ のコードでは、しばしばマクロを使ったトリックが使われています。
+</p>
+<h4 id=".E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E5.86.85.E3.81.AE.E6.A4.9C.E7.B4.A2" name=".E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E5.86.85.E3.81.AE.E6.A4.9C.E7.B4.A2"> ファイル内の検索 </h4>
+<p>ここまでで、<code>sContentCreatorCallbacks</code> の正体はわかりました。続いて、配列の添字として指定されていた <code>aNodeType</code> の正体を探してみます。<code>MakeContentObject</code> 関数の宣言より、変数 <code>aNodeType</code> の型は <code>nsHTMLTag</code> であることがすぐに判ります。では、型 <code>nsHTMLTag</code> の宣言はどこでしょうか。今度は、nsHTMLContentSink.cpp の中には無いようです。このような場合、<kbd>Ctrl+Shift+F</kbd> を押下して「ファイル内の検索」を行うことが良い選択です。「ファイル内の検索」機能は、複数のファイルを横断的に検索する機能です（find/grep と言えば通じる人もいるでしょう）。「ファイル内の検索」機能のダイアログボックスを次図に示します:
+</p><p><img alt="画像:Mh_009_findgrep.png">
+</p><p>まず、検索のオプションを設定します。「検索対象」の項目には、ソースツリーのトップ（mozillaディレクトリ）を指定しておきましょう。「ファイルの種類」は、「*.cpp;*.h」でよいでしょう。「サブフォルダを探す」にチェックが入っていない場合は、チェックを入れてください。最後に、「検索する文字列」に「nsHTMLTag」を指定し、検索を実行しましょう。
+</p><p>何件ヒットしましたか？ 私が試したところ216件でした。明らかに余計なものが混ざっています。そこで、もう一度「ファイル内の検索」ダイアログボックスを開き、「単語単位」というチェックボックスにチェックを入れてください。このオプションを指定すると、単語単位の完全一致のみがヒットします。つまり、「HTML」というクエリに対し、「<em>HTML</em> is a...」はヒットしますが、「<em>XHTML</em> is a...」はヒットしません。
+</p><p>今度は134件ヒットしました。期待したほど減りませんでしたか？ しかし、先程よりは幾分ましです。この中から <code>nsHTMLTag</code> の宣言を探してみます。
+</p><p>mozilla/dist/include/htmlparser/nsHTMLTags.h の54行目に、それらしい列挙型の宣言があります。この付近のコードを次に示します:
+</p>
+<pre>#define HTML_TAG(_tag, _classname) eHTMLTag_##_tag,
+#define HTML_OTHER(_tag) eHTMLTag_##_tag,
+enum nsHTMLTag {
+  /* this enum must be first and must be zero */
+  eHTMLTag_unknown = 0,
+#include "nsHTMLTagList.h"
+
+  /* can't be moved into nsHTMLTagList since gcc3.4 doesn't like a
+     comma at the end of enum list*/
+  eHTMLTag_userdefined
+};
+#undef HTML_TAG
+#undef HTML_OTHER
+</pre>
+<p>前項の nsHTMLContentSink.cpp と同じトリックを使っています。nsHTMLTagList.h の内容をマクロによって書き換え、eHTMLTag_**_tag という列挙子の宣言を生成しています。
+</p>
+<h4 id=".E3.82.A6.E3.82.A9.E3.83.83.E3.83.81" name=".E3.82.A6.E3.82.A9.E3.83.83.E3.83.81"> ウォッチ </h4>
+<p>ここで今一度、nsHTMLContentSink.cpp の976行目（<code>NS_NewHTMLDivElement</code> 関数を呼び出していた場所）に戻ってください。そして、コールスタックのペインの左にあるペインを見てください。あなたが Visual Studio の初期設定を変えていなければ、「ローカル」というタブがある筈ですので、そのタブを開いてください。ない場合は、「デバッグ」メニューから「ウィンドウ」→「ローカル」を選択してください。次図に示すウィンドウが表示されます:
+</p><p><img alt="画像:Mh_010_localwatch.png">
+</p><p>ウィンドウには、ローカル変数の名前と値が表示されています。変数の内容を見てみましょう。変数 <code>aNodeType</code> の値は、<code>eHTMLTag_div</code> です。これは、我々が <code>div</code> 要素生成の瞬間にブレークしていることから考えて妥当です。次に、変数 <code>cb</code> を見てみます。変数 <code>cb</code> の値は <code>0x02160760 NS_NewHTMLDivElement(nsINodeInfo *, int)</code> です。971行目を見ると、<code>cb</code> は <code>sContentCreatorCallbacks</code> から取り出した要素であることがわかります。つまり、
+</p>
+<ol><li> <code>aNodeType</code> の値 <code>eHTMLTag_div</code> によって <code>sContentCreatorCallbacks</code> から関数ポインタが抽出され、変数 <code>cb</code> に格納された(971行目)
+</li><li> 変数 <code>cb</code> は <code>NS_NewHTMLDivElement</code> 関数を指していた
+</li><li> <code>cb</code>&gt; が指す処理をコールした(976行目)
+</li><li> <code>NS_NewHTMLDivElement</code> 関数が呼び出され、そこからさらに <code>nsHTMLDivElement::nsHTMLDivElement</code> 関数が呼び出された(nsHTMLDivElement.cppの83行目、最初のブレーク地点)
+</li></ol>
+<p>という処理の流れが読み取れます。
+</p><p>このように、ウォッチ機能は、プログラムの動作の結果を確認し、コードの内容を理解する大きな手助けとなります。
+</p>
+<h4 id=".E3.82.B9.E3.83.86.E3.83.83.E3.83.97.E5.AE.9F.E8.A1.8C" name=".E3.82.B9.E3.83.86.E3.83.83.E3.83.97.E5.AE.9F.E8.A1.8C"> ステップ実行 </h4>
+<p>いま我々は、新たに <code>div</code> 要素が生成された瞬間を見ました。この生成された <code>div</code> 要素は、この先どこへ行くのでしょうか。HTML 文書がツリー構造のデータであることから推察すると、どこかで親要素と結び付けられる筈です（そうでなければ、このDIV要素は迷子になってしまいます）。この推察は正しいのでしょうか？ 確かめてみましょう。
+</p><p>まず、最初にブレークした場所—<code>nsHTMLDivElement::nsHTMLDivElement</code>—に戻りましょう。もっとも簡単な方法は、コールスタックの最上段をダブルクリックすることです。続いて、<kbd>Shift+F11</kbd> キーを押下してください。何が起きましたか？ 先程まで、ブレークポイントにあった黄色い矢印のアイコンが、78行目まで移動しました。もう一つ変化があります。コールスタックに注目してください。先程まで最上段にあった「nsHTMLDivElement::nsHTMLDivElement」が消え、2段目にあった「NS_NewHTMLDivElement」が繰り上がりました。つまり、<code>nsHTMLDivElement::nsHTMLDivElement</code> 関数が終了し、<code>NS_NewHTMLDivElement</code> 関数に処理が返されたということです。
+</p><p>今あなたが使った機能は「ステップアウト」と呼ばれます。ステップアウトは、ブレーク行を含む関数が終了するまで実行を続け、上位の（呼び出し元の）関数に処理が返ったところで実行を停止する機能です。さらにステップアウトを繰り返し、<code>SinkContext::OpenContainer</code> という関数がコールスタックの最上段に来たら、そこで停止してください。次に示すコードの場所で停止しています:
+</p>
+<pre class="eval"> nsGenericHTMLElement* content =
+   mSink-&gt;CreateContentObject(aNode, nodeType, mSink-&gt;mCurrentForm,
+                              docshell).get();
+</pre>
+<p>ウォッチ機能を利用し、変数 <code>content</code> の内容を確認してください。現在、変数 <code>content</code> は <code>NULL</code> ポインタです。ここで <kbd>F10</kbd> キーを押下してください。黄色い矢印のアイコンが次の行に移動しました。ここでもう一度、変数 <code>content</code> の内容を確認してください。変数 <code>content</code> への代入が完了し、変数 <code>content</code> は、まさに今生成された <code>nsHTMLDivElement</code> 型のオブジェクトを指しています。この変数 <code>content</code> を追えば、<code>div</code> 要素の行方を確認できそうです。
+</p><p>今あなたは、「ステップオーバー」という機能を使いました、「ステップオーバー」は、ブレーク行にある処理を実行し、次の処理を行う直前で停止します。ステップオーバーを繰り返し、1217行目まで進んでください。興味深いコードが現れました。1217行目付近のコードを次に示します:
+</p>
+<pre class="eval"> nsGenericHTMLElement* parent = mStack[mStackPos - 2].mContent;
+
+ if (mStack[mStackPos - 2].mInsertionPoint != -1) {
+   parent-&gt;InsertChildAt(content,
+                         mStack[mStackPos - 2].mInsertionPoint++,
+                         PR_FALSE);
+ } else {
+   parent-&gt;AppendChildTo(content, PR_FALSE);
+ }
+</pre>
+<p>まず、メンバ変数 <code>mStack</code> から親要素を取得しています（<code>mStack</code> の詳細については、気にしないでおきましょう）。次に処理が分岐していますが、見たところ、どちらに進んでも <code>parent</code> の子要素として <code>content</code> を追加するという大意は変わらないでしょう。それでは、分岐の中に進むまでステップオーバーして下さい。おそらく1224行目（<code>else</code> 側）に進むでしょう。<code>AppendChildTo</code> という関数名から処理の内容は自明ですが、練習として関数の内容を追ってみます。今度は <kbd>F11</kbd> を押下してください。<code>AppendChildTo</code> 関数の中に入ることができました。今あなたが使った機能は「ステップイン」です。「ステップイン」は、ブレーク行にある処理にジャンプし、ジャンプ先の処理を開始する前に停止します。ジャンプ先にもまだまだ多くのコードがあります。デバッガの機能を活用し、さらにコードを追ってみてください。
+</p><p>本項では、「ステップイン」と「ステップオーバー」、「ステップアウト」の3つの機能を使用してコードを追いました。これらの機能は、コードが実際に何を行っているのか調べる際にとても役に立つでしょう。
+</p>
+<h2 id="content_.E3.83.A2.E3.82.B8.E3.83.A5.E3.83.BC.E3.83.AB" name="content_.E3.83.A2.E3.82.B8.E3.83.A5.E3.83.BC.E3.83.AB"> content モジュール </h2>
+<p>前章で我々は、Mozilla のコードのごく一部を理解しました。しかし、Mozilla は、本当に巨大なプログラムです。すべてのコードを一行ずつ読んで理解することは、現実的ではありません。そこで、ここからは少し粒度の大きい解説をしましょう。
+</p><p>mozilla ディレクトリにあるファイルやディレクトリ群をもう一度確認してください。content と layout というディレクトリがあります。これらのディレクトリはそれぞれ、content モジュールと layout モジュールのコードを含んでいます。content と layout はそれぞれ、Document-View アーキテクチャで言うところの Document と View に相当します。この2つのモジュールは、Gecko の心臓部ですから、時間をかけて解析するだけの価値があるでしょう。本章でまず content モジュールの解説をし、次章で layout モジュールの解説をします。
+</p>
+<h3 id="Content_Tree" name="Content_Tree"> Content Tree </h3>
+<p>Gecko の動作についての貴重な資料の一つは、「<a class="external" href="http://www.mozilla-japan.org/docs/url_load.html">HTTP リクエストの一生</a>」です。リンク先のページにある図の中央下、(6)という番号が振られている箇所を見てください。「Creates」というラベルの付いた矢印の先で、「IContent」と書かれた箱がツリーを形成しています。「IContent」と書かれた箱のツリーを便宜的に Content Tree と呼びましょう。Content Tree の正体は、我々が普段 JavaScript で扱っている、お馴染みの DOM ツリーです。前章で我々が追ったコードはこの、Content Tree を構築する処理—「Creates」というラベルの付いた矢印で示されています—の一部でした。
+</p><p>何か釈然としませんか？ それは、あなたが（DOM に詳しいにもかかわらず）「IContent」などという名前を聞いたことがないからでしょう。その理由は、content モジュールに含まれるクラスの継承関係を見れば解ります:
+</p><p><img alt="画像:Mh_011_content_classes_inheritance.png">
+</p><p>図の最下段（青くハイライトされています）には、お馴染みの HTML 要素を表すクラスがあります。それらのクラスは、<code>nsGenericHTMLElement</code> クラスを継承しています（他にもあるかもしれませんが、省略しました）。さらに基底クラスを辿っていくと、<code>nsIContent</code> インターフェイスに行き当たりました（黄色でハイライトされています）。これで疑問が解決しました。「<a class="external" href="http://www.mozilla-japan.org/docs/url_load.html">HTTP リクエストの一生</a>」の図は、「IContent のツリー」ではなく「IContent を継承したクラスのオブジェクトのツリー」を意味していたのです。もちろん、前章の nsHTMLDivElement もこのツリーのどこかに組み込まれます。この図は非常に抽象的ですが、具体例を考えながら見ることで、理解しやすくなるでしょう。
+</p>
+<h3 id="Parser.E3.81.A8ContentSink" name="Parser.E3.81.A8ContentSink"> ParserとContentSink </h3>
+<p>引き続き、「<a class="external" href="http://www.mozilla-japan.org/docs/url_load.html">HTTP リクエストの一生</a>」の図を見ながら考えましょう。前節で、我々は、Content Tree についてはよく理解しました。本節では、Content Tree の元となる文書を解析し、ツリーを構築する処理—つまり、パースの過程を理解することにします。
+</p><p>Gecko のパース処理において重要なものは、Parser と ContentSink です。Parser はともかく、ContentSink とは実に抽象的で分かりにくい名前です。ContentSink が何をしているのか探るために、少しコードを追ってみることにします。
+</p>
+<h4 id=".E5.AD.97.E5.8F.A5.E8.A7.A3.E6.9E.90" name=".E5.AD.97.E5.8F.A5.E8.A7.A3.E6.9E.90"> 字句解析 </h4>
+<p>mozilla/parser/htmlparser/src/nsParser.cpp を開いてください（content ディレクトリの外側にありますが、気にせず！）。そして、2030行付近を見てください。次のようなコードがあります:
+</p>
+<pre class="eval">       nsresult theTokenizerResult = mFlags &amp; NS_PARSER_FLAG_CAN_TOKENIZE ? Tokenize(aIsFinalChunk) : NS_OK;   // kEOF==2152596456
+       result=BuildModel();
+</pre>
+<p>たった2行ですが、とても重要なコードです。このコードを詳しく解析するために、2030行にブレークポイントを設定してください。
+ブレークポイントを設定したら再び <a class=" external" href="http://www.mozilla.org/" rel="freelink">http://www.mozilla.org/</a> を開いてください。ブレークポイントにヒットし、nsParser.cpp の2030行で停止するでしょう。停止したら、2030行にステップインしてください。2831行の <code>nsParser::Tokenize</code> 関数にジャンプする筈です。<code>nsParser::Tokenize</code> 関数内の2862行に次のようなコードがあります:
+</p>
+<pre class="eval">result=theTokenizer-&gt;ConsumeToken(*mParserContext-&gt;mScanner, flushTokens);
+</pre>
+<p>この行に新たにブレークポイントを設定し、続行（F5 キー）してください。2862行で再び停止したら、さらにステップインしてください。nsHTMLTokenizer.cpp の549行、<code>nsHTMLTokenizer::ConsumeToken</code> 関数にジャンプします。さて、ここからは自力で、<code>nsHTMLTokenizer::ConsumeToken</code> 関数の内容や、そこからコールされている関数の内容を追ってみてください。何が行われているか理解できましたか？
+</p><p>いま我々が追っているコードは、字句解析と呼ばれる処理です。字句解析とは、テキストで記述されている言語—この場合はHTML—を解析し、字句の区切りを認識する処理です。'<code>&lt;</code>' が見つかればタグであると判断し、その次の文字が '<code>/</code>' であれば終了タグと判断し—などと、実に泥臭いコードが記述されています。
+</p>
+<h4 id=".E6.A7.8B.E6.96.87.E8.A7.A3.E6.9E.90" name=".E6.A7.8B.E6.96.87.E8.A7.A3.E6.9E.90"> 構文解析 </h4>
+<p>次にnsParser.cpp の2031行の内部を追いたいところですが、コードの量が多いため、駆け足で解説します。2031行の処理は構文解析です。構文解析は、（非構造的なデータ列にすぎない）字句解析結果を構造化する処理です。
+</p><p>前項で設定したブレークポイントを解除し、mozilla/parser/htmlparser/src/CNavDTD.cpp の 3263行に新たにブレークポイントを設定してください。再び続行して3263行で停止したら、ステップインしてください。さらにその先でmozilla/content/html/document/src/nsHTMLContentSink.cpp の 2941行にステップインしてください。いま、あなたは <code>SinkContext::OpenContainer</code> 関数のコードを見ている筈です。そして、このコードに見覚えがある筈です。前章を思い出してください。このコードは、<code>nsHTML*Element</code> を生成し、さらに DOM ツリーに追加するコードでした。
+</p><p>コールスタックを確認してください。確かに nsParser.cpp の2031行から呼び出されています。つまり、nsParser.cpp の2031行の内部の処理の結果、DOM ツリーに新たな要素が追加されたということです。
+</p><p>nsParser.cpp の 2030行と2031行の関係をよく考察してください。2030行は、「文字」の流れ（Stream）を「字句」の流れに変換します。2031行は、流れてくる「字句」の意味を認識して要素を生成し、さらに DOM ツリーという構造（Structure）に変換します。工場の流れ作業のように、少しずつデータが加工され、最終的に DOM ツリーという製品になり、そこで流れが停止します。流れてくるデータを洗面台（Sink）のように溜める場所こそ ContentSink です。Parser と ContentSink の関係を次の図に示します:
+</p><p><img alt="画像:Mh 012 HTMLParser.png">
+</p><p>さて、あなたが余程の物好きでもない限り、DOM Inspector で DOM ツリーを眺めながら Web サーフィンをしたりはしないでしょう。あなたが見たいものは、DOM ツリーではなく、美しくレンダリングされた結果です。レンダリングの過程については次章で解説します。
+</p>
+<h2 id="layout_.E3.83.A2.E3.82.B8.E3.83.A5.E3.83.BC.E3.83.AB" name="layout_.E3.83.A2.E3.82.B8.E3.83.A5.E3.83.BC.E3.83.AB"> layout モジュール </h2>
+<p>layout モジュールは、content モジュールが解析した文書の内容を視覚的にレンダリングします。Gecko がしばしば「レンダリングエンジン」と呼ばれることからも分かるように、レンダリングは、Gecko のもっとも重要な機能です。あなたが Gecko ベースのブラウザを利用している理由も、Gecko の優秀なレンダリング能力を見込んでのことでしょう。
+</p>
+<h3 id="frame" name="frame"> frame </h3>
+<p>再び、「<a class="external" href="http://www.mozilla-japan.org/docs/url_load.html">HTTP リクエストの一生</a>」の図を参照してください。右下に「Frame」と書かれた箱がツリーを形成している部分があります。frame の各ノードは、content tree の各ノードと（基本的には）対応しており、1つの frame が 1つの content のレンダリングを管理します。この frame は、HTMLの <code>frame</code> 要素とは全く関係ありません。
+</p><p>あなたは、ここまで読んで、ある推測をするかもしれません。つまり、<code>h1</code> 要素には <code>H1Frame</code> というクラスが対応し、<code>div</code> 要素には <code>DivFrame</code> というクラスが対応し、<code>em</code> 要素には <code>EMFrame</code> クラスが対応し、frame の tree を構成する—この推測は一見妥当なように思えます。
+</p><p>この推測が妥当なものか確かめるために、実際に frame が構築される過程を追ってみます。mozilla/layout/base/nsCSSFrameConstructor.cpp の7768行にブレークポイントを設定してください。今回はさらに、ブレークポイントの条件を以下のように設定してください。
+</p>
+<pre class="eval">aTag == nsHTMLAtoms::div
+</pre>
+<p>この条件式により、<code>div</code> 要素に対応する frame が構築される瞬間にのみブレークが行われます。
+</p><p>では、適当な（<code>div</code> 要素を含む）ページを開いてください。ブレークしたら7865行までステップオーバーし、次の行の <code>ConstructHTMLFrame</code> 関数にステップインしてください。<code>ConstructHTMLFrame</code> 関数の動作は実に単純です。要素の種類を <code>if-else</code> で選別し、要素に対応した frame を構築します。<code>if</code> 文の条件がヒットするまでステップオーバーしてください。どうなりましたか？なんと、結局 <code>div</code> 要素に対応した frame が構築されないまま <code>return</code> してしまいました。
+</p><p>結論を述べると、<code>div</code> 要素に「特有の」*Frame クラスは存在しませんし、必要ありません。何故でしょうか。以下のような HTML 文書がどのようにレンダリングされるか考えてみてください:
+</p>
+<pre>&lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"&gt;
+&lt;html lang="ja"&gt;
+ &lt;head&gt;
+  &lt;title&gt;test&lt;/title&gt;
+  &lt;style type="text/css"&gt;&lt;!--
+   h1,h2,div,p{
+    margin: 0.3em;
+    padding: 0.3em;
+    font-size: 100%;
+    border: 1px solid #000;
+    font-weight: 100;
+   }
+  --&gt;&lt;/style&gt;
+ &lt;/head&gt;
+ &lt;body&gt;
+  &lt;h1&gt;mozilla&lt;/h1&gt;
+  &lt;h2&gt;mozilla&lt;/h2&gt;
+  &lt;div&gt;mozilla&lt;/div&gt;
+  &lt;p&gt;mozilla&lt;/p&gt;
+ &lt;/body&gt;
+&lt;/html&gt;
+</pre>
+<p>特別なユーザースタイルシートが設定されていない限り、Firefox によるレンダリング結果は以下のようなものになります:
+</p><p><img alt="画像:Mh_012_css_box.png">
+</p><p>全ての要素が同じようにレンダリングされました。理由は、全ての要素に同じスタイルが指定されているからです。—重要な事実に気付きましたか？ レンダリングを行う際に重要な事は、要素の種類ではなく、要素にどのようなスタイルが指定されているかです。何もスタイルを指定していない状態で <code>h1</code> 要素が「大きな文字」でレンダリングされるのは、デフォルトスタイルシートでそう指定されているからに過ぎません。要素の種類が関係ないということは、要素の種類にかかわらず共通のコードを（レンダリングに）使用できるということです。ブロック要素をレンダリングする共通のコードは <code>nsBlockFrame</code> クラス、インライン要素をレンダリングする共通のコードは <code>nsInlineFrame</code> クラスにあります。この節の冒頭で追った <code>div</code> 要素には、最終的に <code>nsBlockFrame</code> クラスのオブジェクトが割り当てられている筈です。
+</p><p>ただし、HTML の全ての要素が共通のコードでレンダリング可能というわけではありません。<code>img</code> 要素などの置換要素には、専用の <code>*Frame</code> クラスが割り当てられます。
+</p>
+<h3 id="Reflow_.E3.81.A8_Paint" name="Reflow_.E3.81.A8_Paint"> Reflow と Paint </h3>
+<p>frame によるレンダリング処理は、大きく2段階に分けられます。1つ目は、スタイルシートの指定や隣接する要素との関連を考慮し、要素をレンダリングする位置と大きさを決定する処理です。これを Reflow と呼びます。2つ目は、Reflow の結果決定された位置に、枠線や背景、文字などを描画する処理です。これを Paint と呼びます。Reflow と Paint は完全に分離されており、一つの関数の中に、配置に関する処理と描画に関する処理が同居するようなことはありません。
+</p>
+<h4 id="Reflow" name="Reflow"> Reflow </h4>
+<p>Reflow処理は、tree 上で最上位の frame から順に再帰的に行われます。まず、各 frame は、自身の望まれる大きさ（desired size）を親 frame に報告します。次に、親 frame は、子 frameを適切な位置に配置します。全ての frame の位置と大きさが確定すると、Reflow は終了し、Paint できる状態になります。
+</p><p>次の画像は、Reflow の過程をアニメーションにしたものです:
+</p><p><img alt="画像:Reflow_trace_small.gif">
+</p><p>配置に関する挙動に注目してください。各 frame の初期位置は、常に (x,y)=(0,0)、つまり親 frame の左上です。自身より下位の frame の配置が終わり、自身の大きさが決定した時点で、親 frame 中での自身の位置が決定し、適切な位置に移動しています。
+</p>
+<h4 id="Paint" name="Paint"> Paint </h4>
+<p>Paint もまた、最上位の frame から順に再帰的に行われます。各 frame が実装している Paint 関数は、その名の通り Paint 処理を行うためのものですが、実際の処理は <code>nsCSSRendering</code> というクラスの静的関数に記述されており、各 frame が <code>nsCSSRendering</code> に移譲する形をとっています。
+<code>nsCSSRendering</code> に処理を移譲している様子は、<code>nsFrame::PaintSelf</code> 関数に見られます。<code>nsFrame::PaintSelf</code> 関数は、<code>nsFrame</code> のサブクラスの <code>Paint</code> 関数から呼び出されるサブルーチンです。以下に <code>nsFrame::PaintSelf</code> 関数のコードを掲載します:
+</p>
+<pre class="eval">void
+nsFrame::PaintSelf(nsPresContext*      aPresContext,
+                   nsIRenderingContext&amp; aRenderingContext,
+                   const nsRect&amp;        aDirtyRect,
+                   PRIntn               aSkipSides,
+                   PRBool               aUsePrintBackgroundSettings)
+{
+  // The visibility check belongs here since child elements have the
+  // opportunity to override the visibility property and display even if
+  // their parent is hidden.
+
+  PRBool isVisible;
+  if (mRect.height == 0 || mRect.width == 0 ||
+      NS_FAILED(IsVisibleForPainting(aPresContext, aRenderingContext,
+                                     PR_TRUE, &amp;isVisible)) ||
+      !isVisible) {
+    return;
+  }
+
+  // Paint our background and border
+  const nsStyleBorder* border = GetStyleBorder();
+  const nsStylePadding* padding = GetStylePadding();
+  const nsStyleOutline* outline = GetStyleOutline();
+
+  nsRect rect(0, 0, mRect.width, mRect.height);
+  nsCSSRendering::PaintBackground(aPresContext, aRenderingContext, this,
+                                  aDirtyRect, rect, *border, *padding,
+                                  aUsePrintBackgroundSettings);
+  nsCSSRendering::PaintBorder(aPresContext, aRenderingContext, this,
+                              aDirtyRect, rect, *border, mStyleContext,
+                              aSkipSides);
+  nsCSSRendering::PaintOutline(aPresContext, aRenderingContext, this,
+                               aDirtyRect, rect, *border, *outline,
+                               mStyleContext, 0);
+}
+</pre>
+<p>後半のコードは、実にわかりやすいコードです。まず背景を描画し、<code>border</code> を描画し、<code>outline</code> を描画します。先に描かれたものが背後に回るため、必ずこの順番で描画される必要があります。
+</p><p>ここから、背景の描画（<code>nsCSSRendering::PaintBackground</code> 関数）を例に、具体的な描画処理を追います。背景の種類（単色塗りつぶしか、画像か）や <code>border</code> の形態（丸みがあるかどうか）により処理が分岐しますが、もっとも単純な「丸みなし、単色の乗りつぶし」の場合、mozilla/layout/base/nsCSSRendering.cpp の 3303行目付近にある次のコードに到達します:
+</p>
+<pre class="eval">  aRenderingContext.SetColor(color);
+  aRenderingContext.FillRect(bgClipArea);
+</pre>
+<p>実に単純なコードですが、指摘すべき重要な点があります。それは、ここから先がプラットフォーム依存のコードであるという事です。Windows の場合、<code>aRenderingContext</code> は <code>nsRenderingContextWin</code> クラスのインスタンスです。Linux+Gtk の場合、OS/2 の場合、Mac OS X の場合はそれぞれ、別のクラスのインスタンスが <code>aRenderingContext</code> に設定されます。
+</p><p><code>nsRenderingContextWin::FillRect</code> 関数の実装は以下のようなコードです:
+</p>
+<pre class="eval">NS_IMETHODIMP nsRenderingContextWin :: FillRect(const nsRect&amp; aRect)
+{
+  RECT nr;
+	nsRect tr;
+
+	tr = aRect;
+	mTranMatrix-&gt;TransformCoord(&amp;tr.x,&amp;tr.y,&amp;tr.width,&amp;tr.height);
+  ConditionRect(tr, nr);
+  ::FillRect(mDC, &amp;nr, SetupSolidBrush());
+
+  return NS_OK;
+}
+</pre>
+<p><code>return</code> 直前の <code>FillRect</code> 関数は、Win32 GDIのAPIです。ここから先は Windows 内部の話であり、我々には関係ない事です。つまり、ここが Mozilla における描画処理の末端ということになります。
+</p>
+<h3 id="DisplayList" name="DisplayList"> DisplayList </h3>
+<p>HTMLをレンダリングする最も単純なアルゴリズムは、文書の先頭から、文書中に現れる順に要素を描画するものです。frame オブジェクトのツリーを再帰的に辿って描画処理を行った場合、このアルゴリズムを使用したことになります。このアルゴリズムは、文書中で後に現れる要素が、前に現れたものを必ず上書きします。スタイルシートによる特別な指定がない場合、この動作は妥当なものです。逆にいえば、スタイルシートによる特別な指定がある場合—つまり、<code>z-index</code> プロパティにより要素の前後関係が逆転する場合—このアルゴリズムは破綻します。
+</p><p>この問題を解決するための機構が <code>DisplayList</code> です。DisplayList は、バッチ処理システムのようなものです。各要素の描画処理をバッチジョブとして DisplayList に投入し、スタイルシートで指定された前後関係に基いてジョブを並べ替えてから各ジョブを実行します。この機構により、描画の順序は、文書中の要素の順序から解放されます。
+</p>
+<h2 id="content.E3.83.A2.E3.82.B8.E3.83.A5.E3.83.BC.E3.83.AB.E3.81.AEhack" name="content.E3.83.A2.E3.82.B8.E3.83.A5.E3.83.BC.E3.83.AB.E3.81.AEhack"> contentモジュールのhack </h2>
+<p>そろそろコードを読むことに飽きてきましたか？ 本章では、Mozilla に新たにコードを追加する方法を解説します。本章では、独自に（勝手に）定義した XML 要素を我々の書いたコードでハンドリングすることを目標とします。
+</p>
+<h3 id="IDL.E3.81.AE.E8.A8.98.E8.BF.B0" name="IDL.E3.81.AE.E8.A8.98.E8.BF.B0"> IDLの記述 </h3>
+<p>XML の要素をハンドリングするためのコードは、content モジュールの *Element クラスとして実装されます。このクラスは、XPCOM コンポーネントである必要があります。XPCOM という用語を始めて見たという人は、MDC 内の他の記事を参照してください。XPCOM コンポーネントは ISupports から派生したインターフェイスを最低でも1つ実装する必要があります。いま、我々が実装すべきインターフェイスは、我々が独自に定義する XML 要素を表現する必要があります。当然ながら、このインターフェイスも我々が独自に定義する必要があります。よって、最初に我々がすべきことは、“独自の XML 要素を表現するインターフェイス”の IDL を記述することです。
+</p><p>ところで、“独自の XML 要素”の名前をまだ決めていませんでしたので決めておきましょう。名前空間のURIは、このページのURL（ <a class=" external" href="http://developer.mozilla.org/ja/docs/Gecko_hacking_tutorial" rel="freelink">http://developer.mozilla.org/ja/docs...cking_tutorial</a> ）でよいでしょう。この名前空間の略称として tutorial を用います。要素の名前は、“tutorial”の頭文字をとって t とします。turotial:t 要素です。覚えましたか？
+</p><p>XML要素の名前が決定しました。Mozilla の命名規約に則ると、この要素に対応するインターフェイスの名前は nsIDOMTutorialTElement となります。
+</p>
+<h4 id="IID" name="IID"> IID </h4>
+<p>XPCOM のインターフェイスは、それぞれ固有の UUID、IID(Interface ID) を持ちます。UUID は、重複が起こらないように生成された 128bit の数値による ID です。IID が利用される典型的な場面は、インターフェイスの QueryInterface（問い合わせ）です。QueryInterface は、オブジェクトに対し、あるインターフェイスを実装しているか尋ねる操作であり、このときオブジェクトが実装しているインターフェイスの IID の一覧と、問い合わせられたインターフェイスの IID をマッチさせます。
+Visual C++ には、UUID を生成するためのプログラムである uuidgen.exe が付属しています。Mozilla のビルド環境を整備した後であれば、単に Cygwin のシェルから
+</p><p>uuidgen
+</p><p>と入力すれば、新たに生成された UUID が出力されます。
+</p>
+<h4 id="IDL.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.81.A8Makefile.in.E3.81.AE.E4.BD.9C.E6.88.90" name="IDL.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.81.A8Makefile.in.E3.81.AE.E4.BD.9C.E6.88.90"> IDLファイルとMakefile.inの作成 </h4>
+<p>まず、新しいIDLファイルを配置すべき場所を決める必要があります。我々が普段利用している HTML 要素や XMLHttpRequest などのインターフェイス記述は、/mozilla/dom/public/idl 以下のサブディレクトリに配置されています。このルールに従い、/mozilla/dom/public/idl に新しいサブディレクトリ、“tutorial”を作成し、そこに新しいファイル nsIDOMTutorialTElement.idl を作成することにします。
+</p>
+<pre class="eval">mkdir tutorial
+cd tutorial
+touch nsIDOMTutorialTElement.idl
+</pre>
+<p>これで新しいファイルが作成されましたが、Mozilla のビルドシステムは、この新しいファイルの存在を知りません。Mozilla のビルドシステムにファイルの存在を知らせるためには、Makefile.in というファイルを編集する必要があります。いま我々は、２つのMakefile.in を編集しなければなりません。１つ目は、/mozilla/dom/public/idl/tutorial に作成する新しい Makefile.in です。２つ目は、一つ上のディレクトリ /mozilla/dom/public/idl にある既存の Makefile.in です。
+</p>