March 26, 2007 1:31 PM by ooi1

大井宏友です。

AJAXがずいぶんと広まってきてもう特別なことではなくなってきました。たたみラボでもいくつかのAJAXやJavaScriptリッチUIのサイトを公開してきましたが、作る側にとっては昔も今も結構大変、特にデバッグに悩みます。

Windows環境の場合、以前山本研究員が紹介した方法が有用だったり、Firefoxの場合はFirebugが使えますが、MacOSXのSafariに対応するときは、UTF-8の処理が他のブラウザと違うのにデバッグ環境がなかったため、開発には苦労してきたと思います。

そんな中最近（といっても半年以上前）、「Drosera」という、Safari（正確にはWebKit）のデバッガが登場しました。Droseraの情報は英語しかなく、日本語の情報も軽く検索した限りでは見つからなかったので、自分が使ってみた範囲でメモを残してみました。

SafariとWebKitの関係

WebKitというのはMacOSXのHTMLやJavaScriptを扱うフレームワークで、SafariはこのWebKitをエンジンとして、それにGUI等をかぶせてアプリケーションに仕立てられています。ですので、JavaScriptの挙動という点ではSafariとWebKitはまったく同じ挙動になります。

Droseraの入手・インストール

DroseraはWebKitのビルド（nightly build）に含まれています。ソースコードからも入手できるのですが、Webサイト開発者が使うにはこのnightly buildからコンパイル済みのものをダウンロードするのがお手軽かと。WebKitページの「Download Nightly」 というバッジからダウンロードできます。

dmgファイルがダウンロードされるので、ダブルクリックしてマウントします。あるいはダウンロード後自動的にマウントされます。

マウントされたディスクを開くと、DroseraとWebKitというSafariのアイコンそっくりなものの二つがある(上)と思いますので、それをローカルHDの適当な場所にDrag&Dropしてコピーします。

なお、サイトには実行環境については特に記載されていないようなのですが、MacOSX10.3.9では Nightly Buildのdmgのマウントができませんでしたので、MacOSX10.4 Tiger以降が必要、と考えていいと思います。

Droseraの起動

Droseraの起動の前に、 WebKit.appを起動します。起動すると、メニューからブックマークから何から何までSafariと同じ画面が開きます。このWebKit.appはSafariのデバッグバージョンだという位置づけなのかなと思います。

WebKit.appを起動すると、WebKitの初期画面が開きます。ここでWebKitが最新版かどうかのチェックも行われます。

その後、Droseraを起動します。すると、以下のような小さな画面が表示されます。

この画面で、Droseraでデバッグ対象とするWebブラウザをひも付けます。今起動しているアプリの中でDroseraがひも付けることができるアプリだけがリストアップされます。通常はWebKit以外でDroseraがデバッグできるアプリはないので、 このような画面が表示されると思います。

WebKitが選択されている状態で「Attach」をクリックします。

なんか表示されました。この画面で、breakpointの設定と操作、変数の表示などを行っていきます。

breakpointでbreakしてみる。

breakpointの設定。

デバッグを実行する前に各種設定をします。まずWebKit.appに切り替えて、これからデバッグしたいページのURLを入力して表示させます。表示後Droseraに切り替えると、Droseraの画面は以下のように変わっています。

↑全体像

 

↑左のカラムには、表示したページとその中でリンクしているJavaScriptファイルがリストアップされる。

↑右下の大きな面積の場所に、左のリストで選択したソースコードが表示される。左側の数字は行番号。

ここで、breakpoint（処理を止めたい場所）を定義していきます。処理を止めたいソースを開き、その場所（変数の状態を見たい場所とかループの先頭とかが一般的）の行の行番号部分をダブルクリックすると、その場所にボックス矢印みたいなのが付き、breakpointが設定されます。

 

設定したbreakpointを消すときは、ボックス矢印をドラッグアウトすればOK。この辺はMacOSXのDockからアイコンを削除するようなUIと同じです。

処理の実行～breakpointで停止

breakpointの設定が終わったら、WebKitに戻ってページを実行してみます。イベント処理にbreakpointを設定した場合は通常通りイベントを発生させ、onload処理に設定した場合はページをリドローすれば実行されます。

実行すると、breakpointの箇所で処理が止まり、画面がDroseraに切り替わると思います。

 

ソースコードで現在処理が止まっている行が選択状態+赤い矢印で示されています。またその上･ 画面の中央には現在処理しているfunctionスタックが、その右に現在アクティブな変数とその値が表示されます。

処理を続けるには、ウィンドウ左上の「Continue」「Step Into」「Step Out」「Step Over」ボタンを駆使します。この辺は他の開発言語のデバッガを使った経験があれば説明不要だと思いますが、

• Continue:次のbreakpointまで処理を続ける。
• Step Into:そのfunctionの中に入って処理を一行実行する。
• Step Out:そのfunctionを抜けて、functionが呼ばれている箇所に戻る。
• Step Over:次の1行を処理して止まる。

こんな感じです。これらを組み合わせて、デバッグ作業を続けていきます。

↑Step Overしていっている状態。

breakpointで一時停止しないこともできる。

Droseraはbreakpointで一時停止せずに、その箇所で任意の値をコンソールに書き出すこともできます。

breakpointのボックス矢印をダブルクリックすると、次のような小さなツールが表示されます。

この画面では次のことが設定できます。

• このbreakpointを有効にするか、(一時的に)無効にするか。
• breakpointで処理を一時停止するか、ログ(コンソール)に書き出すか。
• コンソールに何を書き出すか。

上記の例では、breakpointでコンソールに"じゃらん："という文字列と、obj.NumberOfResultsの値を出力する設定。

コンソールに書き出すようにすると、処理は止めずに通常通り続行しつつも要所要所で変数などの値を記録しておく、といった使い方ができます（下）。

 

まとめ。もっと早くほしかった。

上記の画面は「すぐbiz-出張時のホテル･グルメ検索」を例にしてキャプチャしたのですが、すぐbizの開発時はSafariのデバッガがなくてデバッグに非常に難儀しました。特に、UTF-8周りで、Safariだけ文字化けするとか、BOMの問題だとか、AJAXのレスポンスだけ文字化けするとかという問題に遭遇していたのですが、そのときにDroseraを使っていれば、すぐに原因特定と解決ができたよなあと思い出にふけってしまいました。

自分がプログラマー出身だからかもしれませんが、VisualStudioやXcodeやCodeWarriorといったIDEの使用経験のある場合はスムーズにデバッグ作業が行えると思います。

AJAXサイトをつくっていて同じような問題に遭遇している人や、そもそもSafariは良くわかんないからサポートブラウザから外そうとしている方はDroseraを使ってみてはいかがでしょう。

tags：JavaScript  Tips