Latest topics 近況報告

JavaScriptのスタックトレース - Jul 26, 2010

先日のブラウザー勉強会で吾郷さんにお会いした際に、JavaScriptには言語の仕様として「例外がどこから投げられたのか」を知る為の仕組みが無いので独自のフレームワークを作る時に困ったという話を伺った。オレ標準JavaScript勉強会で何話せばいいか困ってた所だったので、それをネタに発表させてもらう事にした。

改めてECMAScriptの仕様書を確認してみたけど、確かに3rd Editionと5th Editionでは、例外オブジェクトの機能としてはError.prototype.nameとError.prototype.messageしか定義されていなかった（あとはconstructorとかtoString()とかその程度）。Wikipedia（英語の方）のECMAScriptの記事によるとECMAScript 3rd EditionはJavaScript 1.5とJScript 5.5の共通部分を抜き出す形で策定されたようで、実装してない方のIEに合わせてこうなったのか？とも思ったけど、調べてみたらJavaScript 1.5の頃はMozillaもError.prototype.stackはサポートしてなかった。それ以降にMozillaが独自に拡張した箇所ということのようだ。でも今回調べた限りではOperaもChromeもError.prototype.stackをサポートしていた（Operaの場合はこれに加えて、少しフォーマットが違うスタックトレースをError.prototype.stacktraceでも取得できる、ということをedvakfさんに教えていただいた）。メジャーなJavaScript実行環境でこれに対応してないのはIE（IE9PP3を含む）くらいのようだ……と思ったらSafari（Windows版）もサポートしていなかった。

吾郷さんのそれやUxUのようにデバッグを支援するためのフレームワークでは、スタックトレースは欠かせない要素だ。将来のECMAScriptの仕様に取り込まれてくれればいいのになあ、と思う。

勉強会ではせがわようすけさんに突っ込まれたけど、セキュリティのためにはなるべくこういう情報は出さない方がいいものらしい。しかし自分はスタックトレースの何がまずいのかがよく分かっていない。会場では「例えばスタックトレースでスクリプトのURLの中にセッションIDが含まれていたらセッションハイジャックされてしまう危険性がある」という例を教えていただいたけれども、それでもまだピンと来ていなかった。

さらにツッコミを受けたことで「なるほど、クロスドメインの制約を突破されてしまう」という事が問題なのだと分かった。ただ、実際にそれが問題になるケースってほんとにあるのかな？　という疑問はまだ残っている。

分かりやすい話として、通常のXMLHttpRequestやiframeでは、別ドメインのドキュメントを読み込む事ができない・読み込んだとしてもその内容にスクリプトからアクセスすることはできない。

var iframe = document.createElement('iframe');
iframe.setAttribute('src', 'http://www.google.co.jp');
document.body.appendChild(iframe);
window.setTimeout(function() {
  try{
    alert(iframe.contentDocument.body);
  }
  catch(e){
    alert(e);
  }
}, 3000);

例えばこういうのは、Error: Permission denied for <http://piro.sakura.ne.jp> to get property HTMLDocument.body from <http://www.google.co.jp>.と言われてエラーになる。しかしスタックトレースにエラー行の詳細な情報が含まれていると、

try {
  document.write('<script type="text/javascript" src="http://www.google.co.jp/" async="false" defer="false"></script>');
}
catch(e) {
  var contentsFragment = e.stack;
}

とか

try {
  var script = document.createElement('script');
  script.setAttribute('type', 'text/javascript');
  script.setAttribute('src', 'http://www.google.co.jp/');
  script.setAttribute('async', 'false');
  script.setAttribute('defer', 'false');
  document.body.appendChild(script);
}
catch(e) {
  var contentsFragment = e.stack;
}

とか

// window.onerrorはECMAScriptの仕様にはない独自拡張
window.onerror = function(aMessage, aSource, aLineNumber) {
  // ここでaMessage, aSourceから情報を取れる可能性がある
}
var script = document.createElement('script');
script.setAttribute('type', 'text/javascript');
script.setAttribute('src', 'http://www.google.co.jp/');
script.setAttribute('async', 'false');
script.setAttribute('defer', 'false');
document.body.appendChild(script);

という風にして、別ドメインのドキュメントの内容を部分的にとはいえ読み取れてしまう可能性がある、というわけだ。特に3番目のwindow.onerrorを使う例はMFSA 2010-47: エラーメッセージのスクリプトファイル名からのクロスサイトデータ漏えいで実際に脆弱性になっていたことが確認されていて、既に修正されている。

なお、実際に現行バージョンのFirefox・Opera・Chromeで試してみたところ、1番目・2番目のtry-catchを使った例ではそもそも例外を例外として（そもそも、エラーが発生したのかどうかすら）捕捉できなかったので、今の所問題にはならない。ただ、今は問題にならなくても、今後登場するJavaScriptの実装ではこういう場合でも情報を取れるようになっている可能性はあるので、将来的に脆弱性の原因になるかもしれないという警告は確かにアリだとは思う。という所までは何とか理解できた。

ブラウザのレベルでは、クロスドメインやクロスオリジンになる時だけは例外を出さないとか詳細な情報を出さないとか、そういう対応の仕方はあるだろうけれども、「ECMAScript」の仕様でそこに言及するのは変だろうなあ。というややこしい事情を勘案すると、もう丸ごと全部仕様からドロップしてしまえという判断になるんかなあ。

カード配り問題 - Dec 16, 2009

10分プログラミング - hogehogeを見て、10分でコーディング｜プログラミングに自信があるやつこい！！に挑戦してみました。

結果。コーディング（と検証）だけで6分くらいかかりました。しかもエレガントでもなんでもありません。

function Cards() {
}
Cards.prototype = {
  deal : function(aPlayers, aDeck)
  {
    var result = [];
    for (var i = 0; i < aPlayers; i++)
      result.push('');
    aDeck
      .split('')
      .slice(0, aDeck.length - (aDeck.length % aPlayers))
      .forEach(function(aCard, aIndex) {
        result[aIndex % aPlayers] += aCard;
      });
    return result;
  }
};

var c = new Cards();
alert(c.deal(4, "123123123"));

クラス名がどうとか書いてあったから馬鹿正直にそれに従ってしまったし。

追記。いかん、人数よりカード枚数が少ないときの考慮が足りてなかった。修正した。

parseTemplate() の引数で渡すオブジェクトのプロパティをテンプレート内のコード片で普通の変数として参照したい - May 20, 2009

前書き

PHPとかerbのようなテンプレートをJavaScriptで。という話に書いたやつの続き。

大切な事なので3回言います。
<% for (var i = 0; i < 3; i++) { %>
  今日は<%= today %>です。
<% } %>
オーケー？

こういう文字列をテンプレートとして解釈したい場面は多分よくあると思う。この例だと、todayという変数をどっか外部から与えて値を埋め込むことになる。で、この変数をどうやって渡したらええねん、と。

解1：グローバル変数を使う

グローバル変数をがんがんに使って構わないのであれば、先にグローバル変数としてtodayを定義しておけばいい。eval()で実行されるコードの中からも普通に参照できる。

しかしアドオンのコードのように、個々のグローバル関数やグローバル変数の寿命が長い事が予想されるスクリプトでは、この手は使えない。

解2：テンプレート内に書くコード片にthis.を付ける

parseTemplate()の仕様としてはあくまで「書かれたコード片は第2引数で渡されたオブジェクトをthisとして実行されます」という風にしておいて、テンプレート風に書かれている方の文字列内のJavaScriptコード片では必ずthis.todayという風に書くようにする、という方法もある。

しかしいちいちthis.を付けるのは面倒だし、そもそも僕がこのような記法を知ったきっかけであるERBでは、self.なんて書く必要がなかった。同じような物は同じように使えた方がいい。なのでこの方法も使いたくない。

解3：varで宣言し直す

先のエントリに当初書いていたコードでは、parseTemplate()の第2引数で渡したオブジェクト（ハッシュ）のプロパティを走査してそれをvarで変数として宣言し直す、ということをしてた。外の名前空間をなるべく汚さないための苦肉の策だ。

  if (aContext && typeof aContext == 'object') {
    for (var prop in aContext) {
      if (!aContext.hasOwnProperty(prop)) continue;
      __parseTemplate__codes.unshift('var '+prop+' = aContext.'+prop+';');
    }
  }

こんな感じ。

でも、これだとエラーになりそうな場合がけっこう考えられる。例えばハッシュのキーが01234という文字列だと、実行されるJavaScriptのコードはvar 01234 = aContext.01234;となってしまい、eval()にかけた時点でSyntaxError: missing variable nameと怒られてしまう。

なので、こういうエラーの元になる名前のプロパティを除外して、安全な物だけをvarで宣言する、ということをやりたかった。言い換えると、そのプロパティの名前を構成している文字列がJavaScriptの識別子として妥当かどうかを判別したかった。

ということでやっと、このエントリの本題に入る。

続きを表示する ...

PHPとかerbのようなテンプレートをJavaScriptで。 - May 19, 2009

UxU 0.5.11に入れ損ねた。次版で標準のヘルパーメソッドに入れるけど、割といいかげんな実装で、たいした規模じゃないから、テストケースの中に直接書いて使ってもいいと思う。

function parseTemplate(aCode, aContext) {
  var __parseTemplate__codes = [];
  aCode.split('%>').forEach(function(aPart) {
    var strPart, codePart;
    [strPart, codePart] = aPart.split('<%');
    __parseTemplate__codes.push('__parseTemplate__results.push('+
                                strPart.toSource()+
                                ');');
    if (!codePart) return;
    if (codePart.charAt(0) == '=') {
      __parseTemplate__codes.push('__parseTemplate__results.push(('+
                                  codePart.substring(1)+
                                  ') || "");');
    }
    else {
      __parseTemplate__codes.push(codePart);
    }
  });
  var __parseTemplate__results = [];
  with(aContext|| {}) {
    eval('(function() { '+__parseTemplate__codes.join('\n')+' }).call(aContext|| {})');
  }
  return __parseTemplate__results.join('');
}

var source = <![CDATA[
      大切な事なので3回言います。
      <% for (var i = 0; i < 3; i++) { %>
        今日は<%= today %>です。
      <% } %>
      オーケー？
    ]]>.toString();
var params = {
      today : (new Date()).toString()
    };
var result = parseTemplate(source, params);

レガシーだけどクロスブラウザな書き方だったら、こうか。

function parseTemplate(aCode, aContext) {
  var __parseTemplate__codes = [];
  aCode = aCode.split('%>');
  var strPart, codePart;
  for (var i in aCode) {
    aCode[i] = aCode[i].split('<%');
    strPart = aCode[i][0];
    codePart = aCode[i].length == 1 ? null : aCode[i][1] ;
    __parseTemplate__codes.push('__parseTemplate__results.push(unescape("'+
                                escape(strPart)+
                                '"));');
    if (!codePart) continue;
    if (codePart.charAt(0) == '=') {
      __parseTemplate__codes.push('__parseTemplate__results.push(('+
                                  codePart.substring(1)+
                                  ') || "");');
    }
    else {
      __parseTemplate__codes.push(codePart);
    }
  }
  var __parseTemplate__results = [];
  with(aContext|| {}) {
    eval('(function() { '+__parseTemplate__codes.join('\n')+' }).call(aContext|| {})');
  }
  return __parseTemplate__results.join('');
}

var source = '大切な事なので3回言います。\n'+
             '<% for (var i = 0; i < 3; i++) { %>\n'+
             '  今日は<%= today %>です。\n'+
             '<% } %>\n'+
             'オーケー？';
var params = {
      today : (new Date()).toString()
    };
var result = parseTemplate(source, params);

Adobe AIRでMigemo - Nov 25, 2008

AIRMigemoというライブラリがあることをリファラで知った。AIRアプリにMigemo検索機能を組み込むのに使えるということだろうか。でもライセンスが分からない……

肝心の正規表現の生成処理は、かなり真面目にやってるような印象。XUL/Migemoの現在の実装は長い文字列の一括置換と分割とソートによる擬似的な物なので、「短い入力で長い単語にマッチさせる」という元のMigemoの特徴の一つを損なうことなく持っていると考えられる。

MochiKitのテスト機能 - Jul 15, 2008

MochiKit見てみた。

これも基本はやっぱりユニットテストに特化した感じかなあ。少なくともGUIのテストは意識してないか……

仕事でFirefoxの拡張機能をやるという事になったときに最初に須藤さんに「拡張機能のテスト用フレームワークってあるの？」みたいな事を聞かれて、それでMozUnitに辿り着いたんだけど、その時の僕にはまだ自動テストとかテスト駆動開発という物がどういうものかよく分かってなかった（今もまだよく分かってないかもだけど）。今思うと、その時僕が思ってた「自動テストって、こういう事をしなきゃいけないのかな？」というのは、開発者世界の常識的には相当ワガママな要求をイメージしていたようで、普通は「自動テスト」「ユニットテスト」というともっと低レベルの、あくまで部品単位の品質を高める物という認識でよかったみたいだ。それを知らずに僕はSeleniumのGUIアプリ用版みたいなのをイメージしてたから、「そんなの無理ッスよ……」と勝手に諦めムードになってた。とはいえ、その勘違いが無ければここまで意地になってUxUに手を入れまくる事もなかっただろうしなあ。

JsUnit - Jul 15, 2008

JsUnit見てみた。

オンラインの例はFirefox 3で普通に動いたんだけど、ダウンロードしたやつは何故か動かなかった……パスに日本語が含まれてるとダメとかそういうやつ？

見た感じではWebページ用のJavaScript一般のユニットテスト用という感じで、Chrome特権であれこれするやつを、しかもGUI上の動作をテストするという前提では……ないよねえ、やっぱり。

script.aculo.usのユニットテスト機能 - Jul 15, 2008

script.aculo.usのユニットテスト機能を見てみた。

昔、Firefox上でprototype.jsを試してみたことがあるけど、少なくとも当時のバージョンではprototype.jsはObjectのプロトタイプとかにプロパティを追加する仕様だったような気がする。なんか全般的にfor-inループを多用してる部分で影響が出すぎてて、Firefoxの動作自体がぶっ壊れてしまって使い物にならなかった記憶がある。少なくとも今のscript.aculo.usが使ってるバージョンについてはObjectのプロトタイプは触らないようになってるみたいだけど、FunctionやRegExpなどのプロトタイプには変更を加えてるみたいで、ちょっと怖い……気にしすぎだろうか。

肝心のユニットテスト機能について。

• アサーションが色々ある。アニメーション効果を扱うライブラリってことで、要素が見える状態かどうかとかのためのアサーションもある。
• ベンチマークを取る機能がある。これパクろうかな。
• BDD風の記述もできるみたい。
• 処理待ちについては、setTimeoutを使って一定時間後に渡した関数に処理を移すという機能がある。

Firefox上でも問題なく動くと仮定しても、これを使って拡張機能のテストをやろうとすると結局は「どうやってテストを走らせるのか」「テストの結果をどうやって見るのか」といったあたりは自分で解決しなきゃいけないか……粒度を高めて本当にユニットテストのために使うぶんには十分使えそうなんだけど、いわゆる結合テスト的な所になってくると面倒さが跳ね上がりそう。XULに特化した便利なユーティリティを沢山用意しておくだけでもそれなりにUxU意義はあるのかな。

自分自身が基本的にGUIアプリしか使えない人間なので、script.aculo.usのテスト機能のように「これ使ったらテストができるよ」って機能群をぽんと渡されても、「え？　え？」って感じで戸惑ってしまう。何かしら型にはめて「あなたはここだけやればいいですよ」って感じでやるべき事を絞り込んで貰えないと、どうしていいか分からなくなってしまう。そのあたりが、UxUでMozRepl由来の部分を全然使わずにMozUnitの部分ばかり拡張し続けている最大の理由なんだな。

本気でやるならprototype.jsやjQueryやYUIは避けてonclickを使うべき - May 18, 2008

タイトルは釣り。

• 本気でやるならonclick属性は避けてライブラリを活用すべき - id:HolyGrailとid:HoryGrailの区別がつかない日記
• 本気でやるならクロスプラットフォームは避けてMozillaアプリを作るべき - hogehoge
• onclick 属性問題について - IT戦記

僕自身はなんだかんだで仕様原理主義者な所が今も強いわけで、その考えに則れば、onclick等のイベントハンドラは一応W3Cの仕様に含まれてるから（HTML4、XHTML 1.0、XHTML 1.1）OKだけど、ライブラリは業界団体の作る標準仕様になってないからNG、と言える。というのはまあ半分冗談だし、そもそもHolyGrailさんの指摘とは次元が違う話なのですが。

しかしこの考えも、権威主義だけじゃなくて、実利的に考えて「そうあるべき」と僕は割と真面目に思っていたりもする。

1. いつでも詳細な取り決めを確認できて、不安無く使える。
2. 特定のベンダの意向や、世間の流行り廃りに振り回されずに、安心して使える。
3. 学んだことが無駄にならず、他の場面でも使える。

この三つの点について、満たしている物が多ければ多いほど、満たしているレベルが高ければ高いほど、それは良い物で学ぶ意義も大きいと僕は思う。

今でこそ僕はFirefox一辺倒だけど、これも「1」と「3」がそれなりに満たされているからという所が大きい。仕様は無いにしても実装がソースコードレベルで公開されているから、必要とあらば「こういう時にどうなるのか」をどこまでも追いかけられる。また、少なくともWindowsとMacとLinuxというマルチプラットフォームで使えて、どれか一つの環境で作り込んでおけば、他の環境でもそのまま使える（最悪でも、それほど大きな労力を掛けずにポーティングできる）。

そして上記三条件それぞれを最も突き詰めた物が、オープンスタンダードであり、デジュールスタンダードであり、デファクトスタンダードだ。

一昔前までは、ことWebについてはデファクトスタンダードとデジュールスタンダードが激しく乖離しているのが当たり前で、GeckoくらいしかまともにW3Cの仕様を実装している物が無い頃には「W3Cの仕様はWeb標準だからこれに則ってればいいことあるよ」と言っても「でもそれって夢物語じゃん」と返されるのが世の風潮だったと思う。でも今は時代が変わった。OperaもSafariも高いレベルでWeb標準に対応してきたし、IEも少しずつだけどWeb標準に合わせてきてる。今だったらはっきりとこう言える。「Web標準の技術を使っていれば、FirefoxでもOperaでもSafariでも動作するし、AirでもGoogleガジェットでもFirefoxの拡張機能でも使えるし、いいことだらけだよ」と。

不遇の時代を乗り越えて、「Web標準」は今、上記三つの条件を兼ね備えた物にようやくなりつつある。W3CやWHATWGやISOやECMAに仕様があって、仕様が公開されていて、しかもそれをほとんどのベンダがサポートしている。これって凄い事だと思わんかねぇ？（誰ともなく）

selector.js改 - Jul 31, 2007

selector.js改（ミラー）

にゃるら、さんのselector.jsをベースに色々やってたらそれっぽい物ができたので、氏に敬意を表しselector.js相当の部分をMITライセンスで公開しときます。冒頭のコメントを見ての通りですが、元のselector.jsで対応されていなかったCSS3のセレクタをだいぶサポートしてます。正しく動かない事があるかもしれないのでその時はフィードバックください。

改造版の一番の特徴は、document.convertSelectorToXPath()ですね。CSSのセレクタを文字列で渡すと、対応するXPath式を生成できる場合はそれを返します。ダイナミック疑似クラス等、XPath式では表現できない内容の時は空文字を返します。

var nodes = document.getElementsBySelector('li:nth-child(even)');
for (var i in nodes)
{
  nodes[i].style.backgroundColor = 'gray';
}

var expression = document.convertSelectorToXPath('p:not(li > *)');
// → /descendant::*[local-name() = "p" or local-name() = "P"][not(self::*/parent::*[local-name() = "li" or local-name() = "LI"])]

• メソッド内の変数のsilhouettePseudElementsAndClassesがtrueの時は、:first-line疑似要素や:first-letter疑似要素など、無茶すればどうにか再現可能な物については、勝手に要素を生成したりclassを設定したりしてそれを使ったXPath式を返します。
• 上記の例を見ても分かるとおり、まあ、無駄が多いです。XPathの勉強用か、内部処理用と割り切って使う事をお勧めします。
• 内部でdocument.evaluate()を多用してるので、DOM3 XPathを実装したブラウザでしか動かんです。というか多分Gecko専用？　他のブラウザでも動いたら教えてください。
• Geckoの仕様上、スタイルシートに記述してあっても、内部のテーブルに存在しないセレクタは無視されるようです。:nth-child()とかは、カンマ区切りのセレクタのリストにそれがあるだけで、その宣言ブロックが丸ごと無視される模様です。（豆知識）