たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
ローカルプロキシっぽいことをローカルプロキシを立てずにやろうとして挫折したことのまとめを書いたら、thorikawaさんが別のアプローチを提示してくださったので、その方向で頑張ってみた。
結論から言うと、URIの置き換え(特定のURIにアクセスしようとした時に、別のURIのリソースの内容を返す)についてはできるようになった。成果はUxU 0.6.0に組み込んである。ただし、他のアドオンとの競合の可能性があるので、初期状態では機能を無効にしてある。
実装がどうなっているかはGlobalService.jsの中のProtocolHandlerProxy
、HttpProtocolHandlerProxy
、HttpsProtocolHandlerProxy
の各クラスを参照のこと。thorikawaさんのエントリに挙げられている課題は、一応解決されているはず。
thorikawaさんによるコードからの違いは以下の点だ。
一つは QueryInterfaceの部分で、QueryInterfaceの部分を置換前のXPCOMに丸投げしてしまっているので、その後の個別の処理も全て置換前XPCOMで行われてもよいはずです。だけど実際にはnewURI,newChannelといったメソッドは置換後のXPCOMのものが呼び出されます。
QueryInterface()
は、実はメソッドの返り値を見るまでもなく、メソッドを実行した時点でそのラッパーオブジェクト自体が変更される。なので、そのせいじゃないかと思う。例えば
var pref = Cc['@mozilla.org/preferences;1']
.getService(Ci.nsIPrefBranch);
var value = pref.getBoolPref(...);
このコードは
var pref = Cc['@mozilla.org/preferences;1']
.getService();
pref.QueryInterface(Ci.nsIPrefBranch);
var value = pref.getBoolPref(...);
と書いてもちゃんと動く。後者のような使い方をされている限りは、QueryInterface()
で何を返していようと関係ない、ということではないのかなあ。
C++で書かれたコンポーネントの中ではdo_QueryInterface()
という関数?がよく使われているようで、こいつが中で何をやってるのかまでは僕にはよく分かってないけど、上記の例の前者ではなく後者に相当するものなんだったら、引用部のような現象が起こるのではないかと思う。
ということでそういう場合に備えて、ProtocolHandlerProxy
クラスは、コンポーネント「{4f47e42e-4d23-4dd3-bfda-eb29255e9ea3}」が備えているすべてのインターフェースを実装しておくようにした。具体的には、nsIHttpProtocolHandler、nsIProtocolHandler、nsIProxiedProtocolHandler、nsIObserver、nsISupports、nsISupportsWeakReferenceの各インターフェース。といっても、やってることとしてはやっぱり単に元のコンポーネントに処理を丸投げしてるだけなんだけど。
またもう一つは、このサンプルでも正常に動作しないサイトがいくつかあること。AJAXを多用しているサイトでも基本的には問題なく動くのですが、たとえばGMailにアクセスするとなぜか簡易版HTMLが表示されてしまいます。もしかすると上記の問題と関連しているのかも知れません。
これは推測だけれども、HTTP_USER_AGENT等が正常に送られなくなっていたせいではないかと思われる。
ちゃんと調べたわけではないんだけど、Webページ内のスクリプトのnavigator.userAgent
の値や、HTTPの通信の際に送られるユーザエージェント名の文字列は、コントラクトIDが@mozilla.org/network/protocol;1?name=http
であるコンポーネントがnsIHttpProtocolHandlerインターフェースを通じて返す値を元に生成されているらしい。
然るに、thorikawaさんによるサンプルコードのコンポーネントにはnewChannel()
などのメソッドは定義されているけれども、nsIHttpProtocolHandlerが持つはずのuserAgent
等のプロパティは定義されていない。XPConnect経由でこのコンポーネントにアクセスすると、undefined
が文字列にキャストされて空文字として返ることになる。その結果、サーバに送られるUA文字列も空っぽになってしまう。つまりサーバから見たら未知のUAとなってしまう。GMailにアクセスするとなぜか簡易版HTMLが表示されてしま
うのは、未知のUAに対しては簡易版HTMLを返すようにGMailが作られているからではないかと僕は推測している。
変更点1で書いた話を実施するにあたって、当初はこれらのプロパティもgetterとして定義してみてたんだけど、実際に動かしてみると、期待通りには動かなかった。具体的には、Webページ内のスクリプトからnavigator.userAgent
等にアクセスしようとすると、セキュリティの制限により前述のgetter関数を実行できない、というエラーが出る。
なので、getter関数を使うことは諦めて、ProtocolHandlerProxy
クラスのプロトタイプに、単純な文字列や数値の定数プロパティとしてそれらを設定しておくようにした。general.useragent.* 系の設定の変更を動的に反映しないといけないので(ここでgetterを使えないのが痛い)、とりあえず今のところは、それらの設定の変更を常時監視して、変更があればその都度ProtocolHandlerProxy
クラスのプロトタイプの定数プロパティの値を更新するようにしている。
この実装では、ProtocolHandlerProxy
をスーパークラスとして、HttpProtocolHandlerProxy
、HttpsProtocolHandlerProxy
という2つのサブクラスを定義することにした。これらの違いは単にコントラクトIDだけ。(まあ、モジュールを登録する時にしか使わない情報なので、サブクラスにするまでもなかったんだろうとは思うけど……)
コントラクトIDが@mozilla.org/network/protocol;1?name=http
であるコンポーネントを入れ替える事を考えた時に、一番問題になるのはおそらく、同じ事をしようとするアドオンが2つ以上あった時のことだと思う。テストケース内でリクエストされるURIをリダイレクトするためだけに、いつもコンポーネントを入れ替えた状態にしておくというのは、無駄にリスクを高めるだけのような気がする。なので、必要な時にだけ機能を有効化できるようにしてみた。
当初は、NSGetModule()
が返すモジュールのregisterSelf()
メソッドの中でregisterFactoryLocation()
している箇所を、設定値を見て必要に応じスキップするようにすればいいだろうか、くらいに考えていた。でも2つの理由でこれはうまくいかなかった。
1の問題をもう少し具体的に書くと、例えばこのコンポーネントの有効無効をextensions.uxu.protocolHandlerProxy.enabled
といった名前の設定で切り替えるようにしようと思っても、NSGetModule()
が返すモジュールのregisterSelf()
メソッドが実行される段階ではまだユーザプロファイル内に保存された設定値が読み込まれていないため、その段階でextensions.uxu.protocolHandlerProxy.enabled
の値を取得しても常にデフォルト値(=false
)となってしまう、ということ。
これを回避するためにUxUでは、設定値ではなくファイルを使うことにした。プロファイル内に「.uxu-protocol-handler-proxy-enabled」という名前のファイルがあればコンポーネントを有効に、ファイルがなければコンポーネントを無効に、という風に、ファイルの有無を真偽値型の設定代わりに使うようにしている。泥臭いというか非効率的というかすごく馬鹿っぽいというかそんな気がするけど、これ以上にいい方法を僕は思いつけなかった。
2の問題は、1を解決できたとしても発生する。Firefoxは利用可能なXPCOMコンポーネントのデータベースをプロファイル内にcompreg.datとxpti.datとして保存しているようで、これらのファイルを生成する時にNSGetModule()
が呼ばれるんだけれども、毎回起動時にこのデータベースを作り直していたら無駄が大きすぎる。ということで、アドオンが追加・削除された時などの「コンポーネントの一覧に変更があった可能性がある」場合にだけ、有効なコンポーネントの一覧のデータベースが作り直されるらしい。UxU的には、プロトコルハンドラの乗っ取りのON/OFFを切り替えた後に必ずこのデータベース再作成の処理を走らせないといけない、でもそれができてない、ということだ。
で、これも似たような方法でアッサリ解決した。Firefoxはユーザプロファイル内に「.autoreg」という名前のファイルがあると(ファイルの有無しか見ないので、内容は何でもいい。空ファイルでよい。)、必ずcompreg.datとxpti.datを再作成する。なので、ユーザが設定を変更したらそのタイミングで「.autoreg」を作成してやり、次に起動した時には設定の変更が確実に適用される(コンポーネントが有効かあるいは無効化される)ようにした。
これだけごちゃごちゃと妙なことをやっておいて、できることといったら単にURIをリダイレクトするだけなんだよね。ショボっ!
FireMobileSimulatorでのローカルプロキシ実装の試みを見て、UxUでデバッグ用ローカルプロキシみたいな事をできるようにしてみたい、と思った。
ただ、HTTPのことはこれっぽっちも分からない。ソケット通信も、一応独自プロトコルっぽいものを使って別プロファイルで動作中のFirefoxからテスト結果を受け取るということはできるようになったけど、それ以上の事は分かってないまま。なので、まじめにローカルプロキシを立てる以外の方法で、「特定のURIにアクセスしようとした時だけ、あらかじめ定義しておいたルールに従って別のリソースを返す」ということをできるようにしてみようと考えた。
僕が現在把握している方法としては、以下の物がある。
http-on-modify-request
イベントのタイミングでリダイレクトするやり方。shouldLoad()
の中でリダイレクトするやり方。1はthorikawaさんが頑張っておいでなので、それに期待している(ソースがGPL互換ならUxUにそのまま入れられるので)。他人のフンドシ。他力本願。ここでは後の2つについての挫折の経緯だけ書き留めておく。
結論を先に言っておくと、2も3も実装上の制限により全滅っぽい。やはり、ローカルプロキシをちゃんと実装するしか完全な解決策はないようだ。thorikawaさん期待age。
http-on-modify-request
イベントを使うやり方これは、現在FireMobileSimulator等ですでに使われている。nsHttpChannelはリクエストを送信する前にnsIObserverServiceを通じてhttp-on-modify-request
イベントを、レスポンスが返ってきた後にhttp-on-examine-response
とかhttp-on-examine-merged-response
とかhttp-on-examine-cached-response
とかのイベントを通知する(SubjectはnsHttpChannel自身)ので、このタイミングでリダイレクトをしようという話。
FireMobileSimulatorの場合、nsHttpChannelの現在の通信をキャンセルした上で、nsHttpChannelからnsIWebNavigationを引っ張ってきてloadURI()
で新しく通信を始めてる。
var redirected = 'http://www.example.com/';
var observer = {
observe : function(aSubject, aTopic, aData) {
if (aTopic == 'http-on-modify-request') {
var httpChannel = aSubject.QueryInterface(Ci.nsIHttpChannel)
.QueryInterface(Ci.nsIRequest);
// ここでキャンセル
httpChannel.cancel(Components.results.NS_ERROR_FAILURE);
// リクエストし直し
httpChannel.notificationCallbacks
.getInterface(Ci.nsIWebNavigation)
.loadURI(redirected, Ci.nsIWebNavigation.LOAD_FLAGS_NONE, null, null, null);
}
};
Cc['@mozilla.org/observer-service;1']
.getService(Ci.nsIObserverService)
.addObserver(observer, 'http-on-modify-request', false);
通常のbrowserやiframeの場合はこれでいいんだけど、img要素やXMLHttpRequestからの通信では失敗する。具体的にはhttpChannel.notificationCallbacks.getInterface(Ci.nsIWebNavigation)
の時点でエラーになる。例えばXMLHttpRequestによる通信なら、httpChannel.notificationCallbacks.getInterface(Ci.nsIXMLHttpRequest)
とすれば元のリクエストを取得できるので、こんな感じで場合に応じて再リクエストの方法を振り分けてやる必要がある。(XMLHttpRequestの場合については、どうやれば再リクエストできるのかまではたどり着けてない。もしかしたら無理なのかも。)
spec
を書き換える場合nsIChannelのURI
プロパティはnsIURIインターフェースの読み取り専用プロパティなので、通信先のURIを書き換えることはできない……ように見える。でも実はnsIURIのspec
プロパティの方は書き換え可能なので、ここに新しいURIを代入することででもリダイレクトできてしまう。
observe : function(aSubject, aTopic, aData) {
if (aTopic == 'http-on-modify-request') {
var httpChannel = aSubject.QueryInterface(Ci.nsIHttpChannel);
httpChannel.URI.spec = redirected;
}
とはいえこの方法は全くお勧めできない。動く場合もあるけど、動かない場合もある、という感じで実に不安定だ。nsHttpChannelの実装を見れば分かるけど、http-on-modify-request
が通知された段階ですでにその時のリクエスト先URIに基づいた初期化処理がいくつか終わってしまっているので、それと矛盾するURIを設定する(例えば、HTTPのリクエストだった物をFile URLにリダイレクトするとか)と、この後の内部処理でエラーが起こるっぽい。
http-on-examine-response
の方ではnsIHttpChannelのsetResponseHeader()
を利用できるので、Location
ヘッダにURIを設定してみたんだけど、ダメだった。残念ながらヘッダを解釈してくれなかった。
nsHttpChannelの実装を見たら、HTTPのステータスコードが301とか302とかの時だけLocation
ヘッダを見るようになってた。ステータスコードを保持しているプロパティは読み取り専用なので、強制的にLocation
ヘッダを読ませるということはできそうにない。
shouldLoad()
を使うやり方これはURNサポートなどで実際に使っている。詳しい方法は2007年当時のエントリに書いてあるけど、要約するとこういうことだ。
やってみると、一見上手く動いてくれてるように見えるんだけど、XPConnect特権がある実行コンテキストで作成したImageやnsIXMLHttpRequestのインスタンスからの通信が捕捉されなくて、UxUの用途では使えない感じだった。まあ仮に捕捉できたところで、元の通信を止めて別のURIで通信するようにさせる方法は分かってない(もしかしたら無いかもしれない)んだけど。
あと、shouldLoad()
の第2引数はnsIURIインターフェースなのでこれのspec
プロパティを書き換えたらどうだろう?と思ってやってみたけど、これもうまくいかなかった。browser要素等での読み込みの場合だと、nsDocShellのInternalLoad()
でエラーが発生する。実装を見た感じでは、nsIContentPolicyに処理が渡ってくるより前に元のURIに基づいてセキュリティ関係の機能が初期化されてるので、その後でURIを書き換えたのがいけなかったんじゃないかと思う。
とにかく、nsHttpChannelのインスタンスが作成された後からどうこうしようと思うのがそもそも手遅れくさい。それより前のステップでアクセス先のURIを書き換えようと思ったら、ローカルプロキシを立てる以外に手は無いようだ。
いいかげん諦めてMozilla Partyの発表資料作ることにします……
僕をRubyの人にさせるんだったらRXPCOMでも作ってくんないと無理ですよ!(←Ruby覚えてもアドオン開発以外やる気なしなのか!) とかなんとかこないだ会社で言ってたけど、調べてみたらもうありました、rbXPCOM。
nsIMsgDBHdrとnsIMsgFolderからメールの本文を文字列として取得する方法をあれこれ試してみてこんな感じのところに辿り着きましたとさ。
Chromeウィンドウでは、window.open()
やwindow.openDialog()
の第3引数でalwaysRaised
フラグを指定することで、「常に最前面に表示」状態のウィンドウを開くことができる(通常のスクリプトではこのフラグを使うには特権が必要)。じゃあ、すでに開かれているウィンドウを最前面にすることはできないのか? というのが今日のお題。
フォクすけクロックを使ってみて、Firefoxのウィンドウの下に時計が隠れてしまうのは不便きわまりないと思ったので、これをどうにかしたかった。最初は、前述のalwaysRaised
を使った方法でいけるかなと思ったんだけど、Firefoxのアドオンとして動作する時はこれでいいけどXULRunnerアプリとして動作する時には「開く元の親ウィンドウ」が無いからこれじゃダメだ、と気がついた。
んでちょっと調べてみた所によると、どうもnsIXULWindowインターフェースのzLevel
というプロパティをいじることで、ウィンドウの重ね合わせの優先順位を動的に変更できるようだということが分かってきた。
以下のようにいくつかのインターフェースを経由することで、Chromeウィンドウ(nsIDOMWindow)からnsIXULWindowのインターフェースに辿り着くことができる。
var Ci = Components.interfaces;
var XULWindow = window
.QueryInterface(Ci.nsIInterfaceRequestor)
.getInterface(Ci.nsIWebNavigation)
.QueryInterface(Ci.nsIDocShellTreeItem)
.treeOwner
.QueryInterface(Ci.nsIInterfaceRequestor)
.getInterface(Ci.nsIXULWindow);
XULWindow.zLevel = Ci.nsIXULWindow.raisedZ;
zLevel
に指定可能な値はnsIXULWindowインターフェースにおいて定数プロパティとして定義されていて、以下の種類がある。
プロパティ | 実際の値 | 意味 |
---|---|---|
Ci.nsIXULWindow.lowestZ | 0 | すべてのウィンドウの最背面 |
Ci.nsIXULWindow.loweredZ | 4 | すべてのChromeウィンドウの最背面 |
Ci.nsIXULWindow.normalZ | 5 | 通常 |
Ci.nsIXULWindow.raisedZ | 6 | すべてのChromeウィンドウの最前面 |
Ci.nsIXULWindow.highestZ | 9 | すべてのウィンドウの最前面 |
lowestZ
とloweredZ
の違いは、前者がエクスプローラその他Windowsネイティブのアプリケーションのウィンドウも含めてすべての最背面になるのに対して、後者はあくまでFirefoxのウィンドウの中での最背面になるだけであるということ。loweredZ
を指定したChromeウィンドウが他のネイティブアプリのウィンドウの下にある時、そのChromeウィンドウをクリックすると、そのChromeウィンドウがネイティブアプリのウィンドウの上に表示されるようになると同時に、それに「押し上げられる」形で、FirefoxのウィンドウすべてがそのChromeウィンドウより前面に表示される。
highestZ
とraisedZ
もそれと同様に、後者を指定したウィンドウは上にネイティブアプリのウィンドウが重なりうるけど、前者にはいかなるウィンドウも上には重ならない……のかと思いきや、こちらはどっちを指定してみてもraisedZ
で期待される通りの挙動にしかならなかった(Firefoxのウィンドウの中での最前面になるだけで、他のネイティブアプリのウィンドウが前面にくると、その下に隠れてしまう)。これってバグ?
ちなみに、数値で1~3を指定した場合はloweredZ
(4)を指定したのと同じ挙動になるようだ。多分7~8はraisedZ
(6)と同じで、それ以上はすべてhighestZ
(9)と同じになるんだろうと思うけど……前述の通りhighestZ
とraisedZ
は実際の挙動に違いが全然無いので、それを確認することはできなかった。
あと、ずっと前にEz Sidebarでこの問題にぶち当たってから気になってるもののずっと直ってないみたいなんだけど、raisedZ
以上が指定されたウィンドウがあると、通常のウィンドウで開いたモーダルダイアログが親ウィンドウの下に潜ってしまうという問題が起こる。パスワードの入力を求めるダイアログ等がFirefoxのウィンドウの下に潜ってしまって使い物にならないので、これはマジで困る。どうにかならんものだろうか。
――ということで対策を考えてみた。
var XULWindow = window
.QueryInterface(Ci.nsIInterfaceRequestor)
.getInterface(Ci.nsIWebNavigation)
.QueryInterface(Ci.nsIDocShellTreeItem)
.treeOwner
.QueryInterface(Ci.nsIInterfaceRequestor)
.getInterface(Ci.nsIXULWindow);
var observer = {
observe : function(aSubect, aTopic, aData)
{
if (aTopic == "xul-window-registered") {
XULWindow.zLevel = Ci.nsIXULWindow.normalZ;
window.setTimeout(function() {
XULWindow.zLevel = Ci.nsIXULWindow.highestZ;
}, 250);
}
}
};
var ObserverService = Cc["@mozilla.org/observer-service;1"]
.getService(Ci.nsIObserverService);
ObserverService.addObserver(MakeOnTopObserver,
"xul-window-registered", false);
新しいウィンドウが開かれる直前にウィンドウのzLevel
を元に戻して、ウィンドウが開かれた後にまた最前面に戻す。こうすれば最後の問題は回避できる。
XUL/Migemo 0.7.0公開した。このバージョンから「Forked Edition」を外して、おこがましくも本家XUL/Migemoの後継とさせていただくことにした。
前のバージョンからの最大の変更点は、ローマ字と平仮名の相互変換処理部分にRuby/Romkanを移植して採用したこと。これはMigemoの大本であるRuby/Migemoが使用しているライブラリでもある。今までは元の処理に増築に増築を重ねたみたいなややこしい物になってたけど、これで、平仮名からローマ字への逆変換も含めて大部分のコードを共通化できて見通しが良くなった、と思う。ただ、速度面で若干遅くなってないかどうか心配ではある。体感できる程の差は無いと思うんだけど。
Ruby/Romkanのコードって無駄がない感じですごいなーと思った。Ruby自体、エレガントにそういう物を作れる言語なんだな、とも。Rubyでたった7KBちょいの物がJavaScriptへの移植で30KB近くにまで膨れ上がってしまうとは……いや、これは単に僕の技術力がヘボいだけか。
あと、Ruby/Romkan自体はRubyのライセンスに準拠していて、RubyはGPL2ということで、XUL/Migemo全体もこの際だからGPL2にしてみた。
うあああやっちまった。既にAPI使ってくれてる人がいたにもかかわらずAPIを予告なしに変更するという愚を…… 一応、本家XUL/Migemoと互換のAPI(xulMigemoCore
オブジェクト)も備えていて、そちらは動作を変えないようにしているので、XPCOMを叩かずにそっちを使ってもらっていれば今回の変更の影響は受けなかったと思うんだけど、そんなことを言っても後の祭りというやつで。
なぜこうもグダグダになってしまっているかというと、どうすれば国際化を楽にできるか、サービス同士の絡みを最小限に抑えられるか、という点で自分の中で考えが固まっていなかったからだ。
XUL/Migemo勝手改造版のXPCOMコンポーネントの機能のうち、日本語の検索に特化した部分とそれ以外とを分割して、国際化というか多言語対応できるようにしてみた。……まぁ、一番メンドクサイ所(入力から正規表現を作る部分)は実質的に日本語専用なので、あんまり意味が無いと言われればその通りなんだけど。
それだけじゃ何なので、おまけとしてやっつけ仕事で英語用のエンジンを作ってみた。「fx a-o」で「Firefox Add-ons」にヒットするようになったりしてちょっと面白いけど、あんまり役に立たないね……
独自エンジンの作り方も書いたので、暇な人が中国語(ピーイン)入力用エンジンとか作ってみてくれることに期待しておきます。
※21日追記。他人(Mozilla)のことには文句言うくせに性凝りもなくAPIをかなり大幅に変更した。誰もまだ手を付けてないことを祈ろう。
※21日追記(2)。APIの使い方とかエンジンの開発の仕方を英訳した。
掲示板で、XUL/Migemo勝手改造版の辞書フォルダの置き場所について相対パスでの指定もできるようにならないか、という要望が出てたのでがんばってみたよ。
以下、解説。
URNサポートをさらに更新して、今度こそあらゆる場面でちゃんとURNをURLにリダイレクトできるようにした。
何かヒントはないかと思ってbbs2chreaderのb2rThreadRedirector.jsを見たら、nsIContentPolicyの実装?を使って内部的にリダイレクトを行えるようだということが分かった。リダイレクト処理をプロトコルハンドラから分離して同様の実装に移してみたところ、うまくいった。URN用のプロトコルハンドラは現在では、単にurn:というスキーマのURIへのアクセスを受け付けるための役割しか果たしていない。
というわけで、以下、Firefox内部でリダイレクトを行う方法をメモしておこう。