主要ブラウザのツールで document.write した JavaScript をデバッグできるか確認してみた

おはようございます。なかじまんです。

主要ブラウザのツールで eval した JavaScript をデバッグできるか に続いて document.write した JavaScript をデバッグできるか確認してみました。もとネタとした JavaScript は、次のとおりです。

<script type="text/javascript">
document.write(
' <script> ',
' function d2() { \n',
' var foo = 1; \n',
' var bar = 2; \n',
' foo += bar; \n',
' console.log(foo, bar); \n',
' }; ',
' <\/script> '
);
</script>
<input type="button" value="d2" onclick="d2();" />

IE8

標準の開発ツールでデバッグできませんでした。何か方法をご存知でしたら教えてください。

IE7 以前

調べていません。ご存知でしたら教えてください。

Firefox 3

Firebug を使ってデバッグできますが、実用レベルではありませんでした。JavaScript 中から debugger; を使ってデバッガを起動し、ステップ実行できるのですが、ソースコードと実行中の行がチグハグで、どの箇所をデバッグしているか判断できません。何か方法をご存知でしたら教えてください。

Firefox 2 以前

Firefox 3 と同じです。

Chrome

次のとおり、標準の JavaScript Debugger を使って、デバッグできませんでした。関数単位でブレークポイントは指定できましたが、行単位はできませんでした。具体的なファイル名が分かれば、行単位でデバッグできるのですが、document.write で生成した無名リソースは、関数が最小単位のようです。何か方法をご存知でしたら教えてください。



Safari 4

標準の Web Inspector を使ってデバッグできませんでした。何か方法をご存知でしたら教えてください。

Safari 3 以前

Safari 4 と同じです。

Opera 9.5, 9.6

次のとおり、標準の Dragonfly を使ってデバッグできました。



Opera 9.2 以前

調べていません。ご存知でしたら教えてください。

以上です。document.write した JavaScript をデバッグするときは Opera 9.5, 9.6 を使うとよさそうです。本当に困り果てたときは Firebug でガンバルという選択もありそうです。

主要ブラウザのツールで eval した JavaScript をデバッグできるか確認してみた

こんにちは。なかじまんです。Twitter での言いだしっぺということもあり、少し泥臭いことしました。

主要ブラウザのツールで eval した JavaScript をデバッグできるか確認してみました。もとネタとした JavaScript は、次のとおりです。

<script type="text/javascript">
eval(
' function d1() { \n' +
' var foo = 1; \n' +
' var bar = 2; \n' +
' foo += bar; \n' +
' console.log(foo, bar); \n' +
' }; '
);
</script>
<input type="button" value="d1" onclick="d1();" />

IE8

次のとおり、標準の開発者ツールを使って、デバッグできました。



IE7 以前

デバッグできませんでした。アドインが存在するかもしれませんが、調べていません。ご存知でしたら教えてください。

Firefox 3

次のとおり、Firebug を使って、デバッグできました。ただ、タイミングなどによって、うまく動作しないことがあります。何かコツがあるのかもしれません。



Firefox 2 以前

Firebug を使っても、デバッグできませんでした。JavaScript 中から debugger; を使って、デバッガを起動できるのですが、eval した JavaScript を行単位でデバッグできませんでした。また、他のアドオンが存在するかもしれませんが、調べていません。ご存知でしたら教えてください。

Chrome

次のとおり、標準の JavaScript Debugger を使って、デバッグできませんでした。関数単位でブレークポイントは指定できましたが、行単位はできませんでした。具体的なファイル名が分かれば、行単位でデバッグできるのですが、無名リソースは、関数が最小単位のようです。無名リソースで、行単位にデバッグする方法をご存知でしたら教えてください。



Safari 4

次のとおり、標準の Web Inspector を使って、デバッグできました。



Safari 3 以前

デバッグできませんでした。アドオンが存在するかもしれませんが、調べていません。ご存知でしたら教えてください。

Opera 9.5, 9.6

次のとおり、標準の Dragonfly を使って、デバッグできました。



Opera 9.2 以前

調べていません。ご存知でしたら教えてください。

以上です。最新か次世代のブラウザであれば、おおむねデバッグできるようですね。

Postal Search Ajax API 1.1.1 アップデート! タイマの扱いを見直しました。

Postal Search APIs & Solutions team のなかじまんです。

Postal Search Ajax API をアップデートしました。バージョンは 1.1.1 です。アップデートの内容は、次のとおりです。必要に応じて差し替えてください。

(1) 個々に JavaScript の setTimeout と setInterval を使うのをやめ、1つの setInterval で複数のタイマを擬似的に扱うようにしました。

次の Firefox2 のバグに対応することが目的でした。ただ1つの setInterval タイマしか使わないようにしたため、Postal Search Ajax API 単独では、このバグは再現しなくなりました。

FirefoxのsetIntervalに不具合？

FirefoxのsetIntervalは複数を一度に登録して実行するとまとめて処理してしまいます。次のコードは１秒間隔で３回、テキストエリアに実行回数と時間（秒.ミリ秒）を出力する関数を定義して、それを１０回呼び出しています。

ただ、聞いたところによると、Firefox2 のセキュリティ更新の提供は、2008年12月中旬をもって終了するそうです。あと1ヶ月ちょいです。無駄なことしたかなぁという感じもありますが、

1つの setInterval を使って複数のタイマを擬似的に実現するようにしたため、同時に多数の API を呼び出すケースで、ツマッた感じがなくなって、滑らかに処理が進むようになったはずです。

(2) 最新の jQuery 1.2.6 に差し替えました。

Postal Search Ajax API に同封の jQuery 1.2.3 を 1.2.6 に差し替えました。

(3) Google Chrome にも対応しました。

Google Chrome の動作確認をし、不都合がないことを確認できました。

CSS Browser Selector を使って Google Chrome を個別対応する。textarea のフォントサイズの相対値がおかしな件。

Google Chrome だけ textarea の font-size がひとまわり小さくなってしまう

Google Chrome を使って Golazo MA4 の動作確認をして気が付いたのですが、Google Chrome だけ、次のように textarea の font-size がひとまわり小さく表示されてしまうのです。em 単位で指定してるのが良くないのかなぁ。ネットで調べてみたのですが、それらしき話題は見つかりませんでした。時間があるときに原因を調べてみます。

引き続き、調べてみました。Google Chrome の textarea は、気になるところが2点ほどあります。

1つ目は、textarea のフォントサイズが、他のブラウザに比べて、ひとまわり小さいことです。他のブラウザに比べて 80% くらいの大きさでしょうか。Styling even more form controls を使うと、様々なフォームのスタイルを手軽に確認できます。

2つ目は、次のように textarea のフォントサイズに相対値を指定すると、元々の textarea のフォントサイズに対して .8em 分、小さく表示されるということです。CSS の仕様は、あまり詳しく把握できていないのですが、.8em と指定したときは、1em に対する .8em のフォントサイズになると理解しているのですが、どうもそうじゃないようです。Safari 3.1 だと期待どおりなのですが...。

#content form input,
#content form textarea {
font-size: .8em;
}

次のとおり、フォントサイズに絶対値を指定すると、Google Chrome も含め、すべてのブラウザで、期待どおりのフォントサイズで表示できます。ただし、フォントサイズを固定すると、文字サイズの拡大と縮小で、ブラウザ間で差異が出てしまう(特にIE)ため、対処としては不完全といえます。

#content form input,
#content form textarea {
font-size: 13px;
}

Google Chrome だけ個別に対応する手法(いわゆる CSS Hack)がないか探してみましたが、Google Chrome は Safari 3 の CSS Hack を適用できるが、Google Chrome だけ適用できる CSS Hack はなさそうでした。Google Chrome を調整すると Safari 3 に影響が出ちゃうということですね。う～む。

ということで CSS だけでの対応はあきらめ、CSS Browser Selector という JavaScript を使って、User-Agent ごとに CSS を切り替える仕組みを使って対応することにしました。

CSS Browser Selector の導入はとても簡単です。次のように JavaScript をロードして、

<script type="text/javascript" src="css_browser_selector.js"></script>

次のように、ブラウザごとに CSS を記述するだけです。Google Chrome だけ textarea のフォントサイズを 1em にしています。これで、すべてのブラウザで、ちょうど 80% の大きさになります。

#content form input,
#content form textarea {
font-size: .8em;
}

.chrome #content form textarea {
font-size: 1em;
}

CSS Browser Selector が何をするかというと、navigator.userAgent を見分けて、HTML 要素にブラウザの種類を表すクラス名を動的に追加するというだけです。ブラウザのエンジン、オペレーティングシステムの区別もできます。なかなかシンプルなアイディアに感心します。

<html class="gecko ff2 win js">

JavaScript が無効だと使えないという欠点がありますが、JavaScript の有無による CSS の区別も備えるため、JavaScript が無効なときの妥協的な CSS を用意するといった対応もできます。

Google Chrome だけ textarea の font-size がひとまわり小さくなってしまう

Google Chrome を使って Golazo MA4 の動作確認をして気が付いたのですが、Google Chrome だけ、次のように textarea の font-size がひとまわり小さく表示されてしまうのです。



次のように、その他のブラウザ (画像は Firefox2) では、だいたい同じ大きさで表示されます。



font-size を指定するスタイルシートは、次のとおりです。

#content form input,
#content form textarea {
font-size: .8em;
}

em 単位で指定してるのが良くないのかなぁ。ネットで調べてみたのですが、それらしき話題は見つかりませんでした。時間があるときに原因を調べてみます。ひとまず、デザインに方針に影響を与えそうなので、事象だけお伝えしときます。