Latest topics 近況報告

外部のスクリプトを読み込む - Mar 19, 2008

各地既報ですが、セキュリティ上の仕様変更によってmozIJSSubScriptLoaderで読み込めるスクリプトの置き場所がChrome内に限定されるようになった（File URLなどの読み込みは拒否されるようになった）そうで。まあ自分が作ってる拡張機能には外部のスクリプトを動的に読み込んでどうこうするものがあんまり無いのでそれほど影響は無いんですが、せっかくなので手持ちの情報を晒しときます。

実は僕、割と最近まで、mozIJSSuScriptLoaderで実行コンテキストを指定できるってことに気付いてなかったんですよね。だから、外部スクリプトは実行できてもその実行結果を取り出すとかはできないと思い込んでまして。Firefox 1.5以前から作ってたやつでデフォルト設定をdefault.jsとしてcontent内に置いてた物で、default.jsの内容を読み込ませるために、わざわざmozIJSSubScriptLoaderと同じ働きをするコードを書いてたんです。ああ車輪の再発明。そんなわけで以下の情報がもしかしたら参考になるかもしれません。

• テキストファイルの入出力：任意のURIで示されたファイルの内容をテキストとして読み込む方法。httpとかftpとかだと、うまくやらないとファイルの頭の方だけしか取れてないのに処理が先に進んでしまうとかそんなことになりかねないので、要注意。面倒な事を考えたくなければnsIXMLHttpRequestでやった方が早いかも。
• nsIXMLHttpRequestの利用例（Rewind/Fastforward Buttons）
• 実行コンテキストを指定して任意のスクリプトを実行する方法：Firefox 3の仕様変更を乗り越えるための試行錯誤の痕跡。実際のコード

……あ。今気付いたけど（ぉぃ）、Chrome URL限定ってことはdata: URLもダメになったってことか。んじゃUXUもやっぱ影響受けるなぁ。さてどうしたものか。

とりあえずスクリプトを実行するだけだったら上記の方法で読み込んだファイルの内容をeval()するだけでいいので、その点では話は簡単なんですけどね。

20日追記。最終的に、格好悪いやっつけの方法ではあるんだけど、こういう風な所に落ち着いた。UxU 0.2.6で採用した方法は以下の通り。

1. 上記の方法でJavaScriptファイルの内容を文字列として取得。
2. それをmozIJSSubScriptLoaderに渡すコンテキストオブジェクトのプロパティとして格納。
3. そのコンテキストのプロパティとして格納されているスクリプトをeval()するだけのスクリプトをパッケージに含めておき、mozIJSSubScriptLoaderで読み込んで実行。

実際のコードはこんな感じ。

var loader = Components
     .classes['@mozilla.org/moz/jssubscript-loader;1']
     .getService(Components.interfaces.mozIJSSubScriptLoader);

this.include = function(aSource, aEnvironment, aEncoding) {
    var encoding = aEncoding || this.getPref('extensions.uxu.defaultEncoding')
    var script = this.readFrom(aSource, encoding) || '';
    var env = aEnvironment || this.environment;
    env._subScript = script;
    loader.loadSubScript(
        'chrome://uxu/content/test/helper/subScriptRunner.js?includeSource='+
            encodeURIComponent(aSource)+
            ';encoding='+encoding,
        env
    );
};

subScriptRunner.jsというファイルの内容は、たったこれだけ。

if (_subScript) eval(_subScript);

これで、mozIJSSubScriptLoaderで普通にスクリプトを読み込ませるのと同じような結果になる。

さらに追記。仕様が変更されて、file:とresource:は使えるようになったそうだ。でもdata:は相変わらずダメなので、今までdata:でやってたものはここに書いたような何らかの方法で代替するしかないと思う。

さらにさらに追記。evalInSandboxを使う方法もあるそうだ。

さらにさらにさらに追記。evalの機能についてFirefox 3.1でまた変更があったようだ。

CSS3 Ruby Module - Mar 16, 2008

ruby-align、ruby-overhang、line-stacking-ruby（これはRuby ModuleではなくてLine Module）の仕様書を読みながらこれらを実装してみている。line-stacking-rubyはruby要素上下のマージンの動的設定でも使わないと再現できないので、display:inline-tableが使えるGecko 1.9（Minefield）でなければline-stacking-ruby:include-rubyで固定になる。

まぁ、どれだけ意味があるかは甚だしく疑問で、ほとんど意地（と現実逃避）ですね。

ということでその成果をXHTMLルビサポート 2.1.2008031701として公開した。設定項目とその効果は基本的に上記の仕様通り（各設定項目の初期値も仕様の初期値）なので、何がどう変わるのか分からんという人はそちらを見てください。

XHTMLルビサポートで文字の均等割り付けに対応したよ - Mar 13, 2008

XHTML Ruby Supportで、ルビベースよりルビテキストが短い時や、ルビテキストよりルビベースが短い時などに、均等割り付けを行うようにしました。 このスクリーンショットはW3Cのテストケースの物ですが、下のルビの「言語」が今までなら中央寄せになっていたところ、ちゃんとルビベースに合わせて字間が広がってます。すぐ上にある「こうあるべき」という表示結果の例と比べても遜色ないことが分かってもらえるかと思います。このテストケースは複雑ルビも使っているので、ルビ実装の本家本元のIEでも表示できないですよ（多分）。

てか、W3Cのテストケースのテスト結果のページ見たら、このアドオンを使った場合の結果が妙に優秀でワロタ（テスト自体は昨年9月の物のようで、注釈で文字の均等割り付けに非対応であると指摘されてる）。

「均等割り付けなんてtext-align:justifyでやりゃいいじゃん、何を今更……」と思う人もいるかもですが、text-justifyのような均等割り付けのアルゴリズム変更の手段がないGeckoでは、段落の最終行は常に左寄せになってしまうので、こういう場面では使えないんですよ。なので、今回は自前で地道に字間を計算して調整してます。計算の仕方は、ずっと昔に中野さんがブログで書いてた本物のtext-align:justifyの実装の解説を参考にしてるつもりです。詳しく知りたい人はjustifyTextメソッドのコードを見てください。

@JOJOとかも、これで心おきなく楽しめます。

あー、しかし北村さんがCSSでルビを擬似的に表示する方法を発表されてから、もう7年も経つのか……その頃生まれた子が今じゃ小学生ですよ？　僕は相変わらず独りでこんな事ばっかやってるというのにねぇ。

タブバーを自動で隠す時の透過の様子のデモ - Mar 11, 2008

ツリー型タブでタブバーを自動で隠す設定の時に、うそっこ透過タブバーで下の物が見えるようにした、と書いたけど、その様子のデモを作ってみた。

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="300" height="283" codebase="http://active.macromedia.com/flash5/cabs/swflash.cab#version=5,0,0,0"> <param name="movie" value="/xul/_video/treestyletab_autohide.swf"></param> <param name="roop" value="false"></param> <param name="quality" value="low"></param> <embed src="/xul/_video/treestyletab_autohide.swf" width="300" height="283" quality="low" loop="false" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"> </embed> </object>

こうして見てみるとスタック型タブとあんま変わらんように見えるな……

そういや昨日これのためのコード書いてたら、Minefieldでタブバーの幅が300ピクセル以下にならなくて、おっかしーなーと思って色々詳しく調べてみたら、HTML Canvasの幅を0にしようとすると問答無用で300ピクセル幅（canvasの初期状態の幅）になってしまうようだった。さらに検証してみたらFirefox 2ではその逆に高さを0にできないという現象も……Bugzillaを検索してみてもクエリが「canvas width」だとやたらたくさん引っかかって同じバグがすでにあるかどうか分からなかったので、とりあえずバグを立ててみた。ガイシュツだったらすんません。ちなみに幅も高さも、最小値は1ピクセルまでだったらちゃんと指定通りに動くようです。というバッドノウハウ。

追記。しばらく使ってみたら、タブの下の何もないスペースを、タブバーがあることを忘れてうっかりクリックしてしまうということが頻発したので、タブバー部分はそうと分かるように色を変えるようにした。

ウィンドウ全体を覆い隠してゴニョゴニョするためのライブラリを作った - Mar 10, 2008

ツリー型タブでタブバーの表示・非表示を切り替える時の画面のちらつきがUZEEEEEEEEEE！！というのは前々から把握してたんだけど、一時的に画面描画を止めるとかそういうのはJavaScriptのレイヤからは手が出せないっぽいので放置してた。AutoHideではC++あたりでXPCOMコンポーネントを作ってどうにかしてるようだけど、そんなん僕には作れないし。

でもよく考えたらHTML Canvas使って解決できるんじゃね？　と思って、そういう物を作ってライブラリ化してみた。fullScreenCanvas.show()を呼ぶと、今のウィンドウの表示内容のスクリーンショットを貼り付けたような状態のCanvasがウィンドウ内の要素の最前面に表示されます。画面がチラつくような処理をその下でやって、終わったらfullScreenCanvas.hide()でCanvasを消す、という風にすると、ユーザにイヤンな思いをさせないでいろんな事ができるかも知れない。ブラウズ領域のスクロールバーの部分が描画されないのはどうにもならなかった。

以下、工夫した所。

• Minefield 3.0b5preではposition:fixedにしてもCanvasがブラウズ領域の描画内用の下に潜り込んでしまう。フレーム（iframe, browser, tabbrowser）があるとそっちの方が上に描画されてしまうようだ。というわけでGecko 1.9の時だけbrowser要素を動的に生成してその中にcanvasを置くようにした。
• Firefox 2でも、position:fixedを指定したcanvasがブラウズ領域の下に潜り込んでしまう。これは毎回positionプロパティの値を指定し直してやる事でうまく動くようになった。
• drawWindowは、フレームを含むwindowを指定した場合はサブフレームの中身まで描画するけど、Chrome Windowを指定した場合はbrowser要素やtabbrowser要素で形成されるサブフレームの中身が描画されない。しょうがないので、browser要素やtabbrowser要素を全部収集してループで一つずつ描画するようにした。

XULとCSSのポジショニングの組み合わせは、Gecko 1.9でもバッドノウハウの塊ですね。

Firefox 3のタブにFirefox 2と同じプレースホルダーを復元するライブラリと併せて、MITライセンスでの公開とします。

追記。canvasついでに（意味不明）、タブバーの後ろにcanvasを置いてうそっこ透過タブバーを実現してみた（描画内容が微妙にズレることがあるのは勘弁してください）。これで、ページの閲覧を邪魔されずにタブバーを使えるようになるだろうか？

予知 - Mar 06, 2008

こないだのcbeardを放置する会囲む会で「Betaは4で最終だって言うけど、Minefield追っかけてたらバージョンのb4preがいつの間にかb5preになってたりするんじゃね（＝Beta5が出る）」と言ってたら、ほんとに決定しちゃいましたねBeta5。

今度から僕の事を予知能力者と思っていただいて問題ないかもしれません。

ちなみにMozilla界隈のウォッチャーには、リリース時期とかロードマップとかついてこういう予知ができる人が異常に多いので、あんまり珍しくない能力と言えます。キミにもできる未来予知、みんなでレッツチャレンジ。

なぜOperaはオープンソースでないのか - Feb 29, 2008

OperaのTetzchner CEOへのインタビュー記事（英語）について、冒頭の Opera をオープンソースにしない理由などだけでも目を通すと良いかもとあったので、頑張って読んでみたよ。誤読してたらすんません。

（質問）Operaをオープンソースでリリースするのに何が必要ですか？　私はあなたが過去すでに、オープンソース化はあなたに何の利益ももたらさないと述べたことを知っていますが、その考えに変化があったかどうかに関係なく、私はただ確認をしたいのです。私は、オープンソース化がLinuxとBSDでのすべてのユーザを幸せにするだろうと確信しています。

（回答）本当の質問は、なぜそう考えるのか、そして、それは本当に重要なのかということです。私たちの世界観では、オープンスタンダードこそが重要な物と考えます。オープンスタンダードとオープンソースとを選べるのなら、私達は必ずオープンスタンダードの方を選びます。幸いにも、多くの場合オープンソースの企業は実際にはオープンスタンダードによってうまくいっていますので、それ自体は問題ではありませんが、しかし、私達が重要だと信じているのはあくまでオープンスタンダードです。なぜなら、その時あなたは選択肢を持てるからです。あなた自身の考える優先順位に基づいて、使う製品を切り替えることができるという事ですね。

そして、オープンなコミュニティの問題があります。私達はとてもオープンなコミュニティを持っていて、非常に多くの人達と働いています。私達が企業として歩む道は色々な意味で、オープンソースの企業のそれに似ていると、私は考えています。今現在、コミュニティの人達は私達の製品のソースコードにアクセスする事ができませんが、しかし、彼らは私達とコミュニケーションを取り、フィードバックをしてくれて、私達の製品を試してくれています。私達はとてもオープンな仕事のやり方を、コミュニティの人達としているのです。そこでの疑問は、なぜ私達がその上でさらにオープンソースの活動をやらないといけないのか、それが私達にどんな利益をもたらすのか、という事です。

ちなみに、私は自分自身でオープンソースの活動をしたことがあり、Telenor Researchであるプロジェクトを作りました。私はFrameMakerのコンテンツを読み込んでHTMLに完全に変換するプログラムを作りました。そして、私はそれをオープンソースでやりました。また、それは実に見事に動作しました。しかし、同時に、私がそのプロジェクトの仕事をやめた（関わらなくなった）途端、プロジェクトは死んでしまいました。みんながそれを使っていたのにも関わらずです。それはFrameMakerの文書をHTMLに変換するための、最もポピュラーな方法でした。それは非常に強力なツールで、FrameMakerブックの全体を、章や複数の文書を、画像、文書間のリンク、索引も含めて、何もかもを完全にHTMLに変換することができました。しかし、私がそのプロジェクトに関わらなくなった途端に、状況は変わってしまいました。

私の考えでは、もし私達がOperaをオープンソース化していたら、ある種の人たちは私達のソースコードを見ることができて、私達をもしかしたら助けることができたかもしれませんが、依然として大部分の作業は私達自身がやることになっていただろうと思います。これは実際の所、他の有名なオープンソースプロジェクトと全く同じです。もしあなたがオープンソースプロジェクトの一つに参加しようとしても、実際にはそれはそんなに簡単な話ではありません。なぜなら、そこにはプロジェクトの主導権を握っている門番のような誰かがいるからです。ですから私は、オープンソース化していたらそれによって多くの物を得られただろうという考えには確信を持てませんし、人々が私達のコードを見るだけ見ておいしい所だけ持っていってしまう危険性もあっただろうと思っています。

まあOperaはプロダクトや技術それ自体を売ることでお金を得るビジネスモデルだから、Operaがそういう営利企業である以上は、オープンソース化しても大して嬉しい結果にはならないだろうなあ。Mozilla Corporationなんて、非営利団体が唯一の株主で、営利目的では活動しませんって明言しちゃってるし。あそこの目的は金を稼ぐことではなく社会貢献することの方が優先順位が高いと見て間違いは無かろう。そんな所とOperaを一緒くたにして語られても、テッちゃん困っちゃうよね（←なぜ馴れ馴れしい）

ツリー型タブの最近 - Feb 28, 2008

ここ最近のツリー型タブの状況まとめ。

先週末くらいから現実逃避度合いが加速して、それがそのまま頻繁なバージョンアップに繋がっています。この1週間くらいでやったことのうち大きなトピックは以下のような感じか。

• 公開申請が通って、晴れてサンドボックスから出た。
• Firefox 3 Beta3（正確にはb4pre）対応。
• タブバーの固定、表示位置変更をコンテキストメニューから可能にした。
• マルチプルタブハンドラでの複数タブドラッグに対応。
• Highlander、PermaTabs、ColorfulTabs、Super DragAndGo、Drag de Goとの競合の解消・連携を強化。

他、細々とした改善が多数。だいたいAMOの配布ページのディスカッションに寄せられてた障害報告や要望への対応が多い。

以前TBEをやってた頃は、あまりに規模がでかかったこともあって、とてもじゃないけど他の拡張機能のために配慮するなんて事はできなかった。その点ツリー型タブとかの最近作った物は、なるべく機能を絞り込むように・見通しがよくなるように気をつけている（つもり）ので、あの頃よりもずっと楽にコードを書けてると思う。具体的に名前が挙がったアドオンについて、わりと片っ端から対応用のコードを書いていけてるのも、そういう事情があってこそだ。

しかしいくらサンドボックスから出られたからとはいえやたらたくさんコメントが付いて、正直追いかけるのだけで大変だ。何でだ？と思ってたら、数日前にlifehackerで紹介されてた。コメント欄を見てみると、おおむね好評なようで嬉しい。Firefoxのユーザ全体のうちこの拡張機能を使ってくれてる人の割合は物凄く小さいものだとは思うけど、英語圏はなにぶん人の数が桁違いに多い。英語でリリースしておくと日本語だけでリリースするより多くの人に誉めて貰える&喜んで貰えるので、僕のような構ってちゃんで誉めてもらえないとロクに動けない人間にとっては、その点では都合がいいと言えるかもしれない。

複数のタブのドラッグ＆ドロップを受け付けるAPI - Feb 27, 2008

マルチプルタブハンドラによる複数タブのドラッグ＆ドロップに対応するためのAPIの説明を書いた。拡張機能作者の人は、なんかおもしろい使い方を考えてください。

なお、このAPIはバージョン0.2.2008022701以降で利用可能です。

goo辞書 1.0.1の裏技（？） - Feb 27, 2008

goo辞書 1.0.1から、about:configあたりでextensions.goodictionary.context.shortcut.enabledをtrueにすると、キーボードショートカットが使える。ページ中の文字列を選択した状態でCtrl-Shift-Eで英和、Ctrl-Shift-Jで和英、Ctrl-Shift-Nで国語・新語辞書の検索を実行。

という、小ネタ。

自分はセカンドサーチを入れた状態で選択語句を検索バーまでドラッグ→ポップアップから検索エンジンを選択してドロップ、という操作の方をよく使うので、キーボードショートカットはあまり使わないんですけどね。文字列のドラッグ＆ドロップを「検索を実行する」という用途にだけ使うんだったら、ブラウズ領域全体を使って検索エンジンを選べるWeb Search Proの方が便利かもだけど、僕はテキストエリア内で文字列のドラッグ＆ドロップで移動するという編集の仕方も時々やるので、それができなくなってしまうのは嫌だった。敢えて検索バーまでドラッグすることで明示的に「これからこの言葉を検索したいです」って指示してやるというスタイルの方が性に合ってる。自己主張しすぎない控えめなのが好きなんですよ。