たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
英語で書かれた障害報告のメールに返信する時にルーラーがひどくずれていたのが気になってたけど放置してた件について、ルーラーバー 0.3.2008120101で修正した。
今まで、ルーラーの表示サイズの基準には編集領域のdocument.documentElement
のfont-size
を使ってたけど、こちらはエンコーディングが変わっても値が変化しない。それに対して、document.body
のfont-size
は、エンコーディングごとのフォントサイズの違いの影響を受ける。ということでbodyの方の値を参照するようにしたら、ルーラーの間隔はおおむね正しいものになるようになった。
ただ、これでもカーソル位置の強調表示のずれは残る。フォントサイズだけでなくフォント自体もエンコーディングによって変わる可能性があり、フォントサイズだけ合わせても、実際の編集領域とカーソル位置検出用の非表示のフレームとでフォントが違ったら、ピクセル単位で位置を拾った時に微妙にずれが発生する可能性がある。そこで、非表示のフレームの方にもエンコーディングの変化を適用させるために、SetDocumentCharacterSet()
のタイミングで非表示のフレームの方のエンコーディングも変更するようにした。エンコーディングの動的な変更の方法はこんな感じ。
// this.calculator は非表示のフレームのbrowser要素
var docCharset = this.calculator.docShell
.QueryInterface(Components.interfaces.nsIDocCharset);
docCharset.charset = aCharset;
var webNav = this.calculator.webNavigation;
webNav.reload(webNav.LOAD_FLAGS_CHARSET_CHANGE);
var self = this;
this.calculator.addEventListener('DOMContentLoaded', function() {
self.calculator.removeEventListener('DOMContentLoaded', arguments.callee, false);
// 読み込みが終わった段階でルーラーの表示を更新する(カーソル位置の検出をやり直す)
self.updateRulerAppearance();
}, false);
最後にリロードしないと表示が変わらない、のかな?(リロードしなかった場合の挙動については未検証)
会社サイトのブログの方で解説を書くつもりですが、UxU新バージョン(0.5.0)を公開しました。日本時間10月30日の昼下がり、太平洋標準時で29日の肉の日リリースです。変更点はMozilla Add-onsのバージョン詳細の方を見てください。
自分自身がサーバソケットの方を使ってなかったのでMozRepl互換のサーバ機能の方がだいぶ長らく死亡してたみたいなんですが、今回プロファイルを指定してテストを実行する機能を作るにあたり、新たに起動された子プロセスと親プロセス側でテストの実行結果や中止の命令とかを通信しあうために、UxUサーバで使われていた機能をブラッシュアップして流用するようにしたため、ぶっ壊れていた所がだいぶ直りました。今後はサーバ周りの実装も気をつけて見るようになると思いますので、ぶっ壊れっぱなしのまま放置ということは減るんじゃないかと思います。多分。
ところで、子プロセス起動してうんたらかんたらということができるようになったということは、FirefoxやThunderbirdの上で動かすことにこだわらなくてもいいようになった(必要に応じてそれらを呼び出せば済む)という事で、やる気次第ではXULRunnerアプリケーション化という道もあり得るかもしれませんね。
Ruler Bar更新した。結局、今までのやり方はほとんど全部うっちゃって、ピクセル単位で位置合わせするようにした。
ピクセル単位で現在のカーソル位置を取得するには、カーソル位置=長さ0の選択範囲の位置に何かダミーの要素を挿入して、その要素の画面上でのX座標を取得すればいい。ただ、メール本文の編集中にこれをやると、場合によっては再描画とかノードがブツ切りにされまくるとかでかなり怖いことになるんじゃないだろうかという心配があったり、そもそもテキストノードの切断を伴うような処理をやると選択範囲が失われる(=カーソルが一時的に消える)のでその復活のための処理が面倒だったり、といくつかの理由があってこの方法を採るのをずっとためらってた。
でも上手い解決方法を思いついたので、今回この方法に切り替えることにした。
種を明かすと、非表示のフレームを一つ用意しておいて、編集中のメール本文のうちカーソルがある段落の箇所だけをその隠しフレームに複製して、そっちでテキストノードの切断を伴うような処理をやってる。フォントや文字の大きさ、body要素の幅などを合わせてやれば、そこで起こる折り返しは基本的に本物と全く同じ結果になるはずなので。編集されるのは複製の方で、しかもカーソル前後の段落だけ抜き出したものだから、ノードを切り刻んでも再描画のコストは最低限で済んでる……と思う。
ルーラバーだとやっぱり行ったことのある場所に行くあの呪文しか思い浮かばないという声があったので、日本語名をルーラーバーに変えた。
そのルーラーバーなんだけど、Rulerrrrrでもあった「折り返された次の行の先頭にカーソルがある時や行末にカーソルがある時にルーラー上の現在位置表示がおかしくなる(カーソル位置の計算に失敗する)問題」に真面目に取り組んで、0.2.2008101101でだいぶ改善した。
ルーラーバーもRulerrrrrも、現在のカーソルの位置を計算するのには選択範囲を使っている。FirefoxやThunderbirdではカーソル位置をJavaScriptから直接取得することはできないんだけど、現在カーソルがある位置は長さ0の選択範囲として取得できるので、選択範囲が含まれているノードとか選択範囲の開始・終了位置などからどうにかこうにかして「カーソルより前に何文字あるか」を数えて、カーソル位置を割り出している。
行末にカーソルがある時にカーソル位置が0(行頭)と判定されてしまっていたのは、この選択範囲から選択範囲が含まれているノードを取得できないせい。どういう事かというと、行末にカーソルがある状態というのは「テキストノード」「改行のBR要素」「テキストノード」という順番にノードが並んでいてBR要素の直前に長さ0のRangeがあるという状態で、「選択範囲が含まれているノード」は前後の要素やテキストノードではなくいきなりBODY要素になってしまう、ということでカーソル位置の求めようがなくなっていた。
そこで、TreeWalkerを使って各行のテキストノードやBR要素を走査し、compareBoundaryPoints()
でそのノードがカーソルに隣接しているかどうかを調べる、という風な処理を入れてみた。これにより、行末にカーソルがある時でもカーソルより前にある文字を数えられるようになった。
折り返された行の処理はもうちょっと厄介だった。普通に考えたら、「カーソル位置より前の文字数÷折り返し文字数 の余り」でカーソルの現在位置が分かるはずなんだけど、実際にはこれだけじゃダメだった。FirefoxやThunderbirdのエディタ機能では、折り返された行の行末にカーソルがある時に右キーを押すと、次の文字(折り返された次の行の先頭文字)の後の位置にカーソルが移動するのではなく、次の文字の前・仮想的な改行文字の後にカーソルが移動してしまう。折り返された後の行頭で左キーを押した時も同様。なので、いくら文字数ベースで計算しても、今「折り返された行の折り返し直前にカーソルがある」のか「折り返された後の行の先頭にカーソルがある」のかは分からない。
幸い、選択範囲の変更(=カーソルの移動)を監視する時にはその選択範囲の変更が発生したユーザの操作の種類がある程度分かる。なので、マウス操作でのカーソル移動については、行の左の方でのクリックでカーソルが移動した時は行頭、そうでなければ行末と判定するようにした。また、キー操作でのカーソル移動については、「直前にいた位置が行頭・行の中程・行末のどれだったか」と「どのキーが押されたか」の組み合わせを元に、今カーソルがどの位置にあるかを推測するようにした。
英単語等があるせいで予定の文字数より前で折り返しが発生した時や、HTMLでプロポーショナルフォントが使用されている時、画像がある時などについてはもう完全にお手上げです。カーソルの位置をピクセル単位で取れるようなAPIが付いてくれないことには、もうどうにもなりません。
このサイトの方にまだ配布ページ作ってないのでとりあえずMozilla Add-onsに置いてみました。「ルーラ」と書くか「ルーラー」と書くか迷って「ルーラ」にしてしまいました。知ってる土地まで戻る魔法ではありません。→0.2で「ルーラーバー」に名前を変更したのでこのエントリの表記も「ルーラー」に統一しました。
見ての通り、Rulerrrrrのクローンです。公開終了しちゃってる上に特にオープンソースなライセンスが設定されていたわけでもないので、Rulerrrrrの改造ではなく一応フルスクラッチです。以下の点がちょっとだけRulerrrrrよりパワーアップしてます。
空行から左キーを押して一つ前の行の末尾に移動する時に、ルーラー上の強調表示がちゃんと追従してくれないとか、右キーを押して行末→行頭に移動しても強調表示は行末側に残ってしまうとか、Rulerrrrrでも見られた問題がこいつにもあります。そのうちなんとかしたいですね。→0.2.2008101101で改善しました
ていうか誰かすでにクローンを作ってるんじゃないかと思ったら案外誰もやってなかったみたいで驚いた。
こないだからやってるNetscape Communicator 4.xからの移行、現地でのリリース候補版レベルでのテストでまた詰まった。自分とこで作ったテスト環境では問題なかったのに、実際の環境だとnsIMessengerMigratorのUpgradePrefs()
で謎の例外発生ですよ。
もういっそのこと処理を全部JavaScriptに移植してみるか? なんて不毛なことを考えてもみたけど、せめて現地でできる事はやり尽くしておこうと思ってMXRでソースを見ながら目デバッグし始めてみたら、冒頭でいきなりそれっぽい箇所を発見した。移行元の設定でmail.server_type
が未定義だと駄目らしい。よくよく調べてみたら、その環境ではnetscape.cfg内で指定されてる設定がたくさんあって、その値はユーザプロファイルの中のprefs.jsには保存されてないから、Thunderbirdが「全然設定が足りねえぞゴラァ!!」と怒ってた、と。
こんなん、今回うちで作った移行ツールじゃなくても本体の設定インポートでも普通に詰まるんじゃないの? どうなってんだまったく。
仕事で書いてるコードがどーにもうまく動かなくて、ついこないだまで正常に動いてたのにどうして?!と思って色々試していたら、特定の関数をtoString()
等で文字列化した時におかしな現象が起こっていた。具体的には、Thunderbird 2.0.0.17のAccountManager.jsで定義されているsaveAccount()
を書き換えようとしたら例外が発生して、onSave()
を文字列にしてreplace()
で改変した物はfor〜inループだった箇所がwhileループになってしまっていた。コードを削っていったらめちゃめちゃ短いコードでも再現したので、Bugzillaに報告しておいた。
上記のような方法で動的にパッチを当てる手法を僕は多用してるので、仕事で書いたコードもここで公開してる拡張機能のコードも、正直、どのくらい影響を受けるのか見当も付かない。早急に解決されることを祈るのみだ。
ちなみにFirefox 3.0.3ではこの問題は起こらなかった。2.0.0.17で入ったセキュリティ上の修正による後退バグっぽい?
追記。29日時点ですでに修正済みだったようだ。これ、あと1ヶ月間放置ですか……? ものっそクリティカルなバグだと思うんだけど。
Netscape Communicator 4.xのメールデータとか設定はインポートできるのにアドレス帳だけインポートできないってどないやねん。
調べてみたら、鍵になるのはnsIAbUpgraderインターフェースを実装したコントラクトIDが@mozilla.org/addressbook/services/4xUpgrader;1
のコンポーネントらしいんだけど、これ、Mozillaのソースには含まれてないんだ……オープンソースになってなかったいくつかのNetscape製コンポーネントの一つらしい。これがないせいでThunderbirdはNC4.xのアドレス帳を直接読めないんだって。なんてこった。
どうしてもやりたい場合、考えられるやり方は以下のような感じ。
というわけで調べてみてた。
まずNC4.xのエクスポート機能を使う方法。多分これが一番手っ取り早い。LDIFかCSV等に書き出して、Thunderbirdのインポートツールでそれを読み込めばいい。ただ、手動でやらなきゃいけないってのがネックで、自動化できないから今回の仕事じゃちょっと使えない。
次に、Netscape 7を使う方法。NS7には上記のコンポーネントが含まれてるから、プロファイルのインポートで普通に*.na2を*.mabに変換できる。ということで拡張機能なりパッチなりを使ってNS7をアドレス帳変換専用ツールに仕立て上げてしまえば諸々の処理を自動化できるんだけど……インストール先のchromeフォルダを見たら、昔半泣きになりながらexUnregisterer.jsなんて自作ライブラリを作ってどうにかこうにか凌いでいたあのRDF地獄があって一気にやる気消失してしまった。最近Firefoxのアドオンを作り始めた人は知らんでしょうけど、昔はオーバーレイいっこあてるのにも物凄い苦労があったんですよ……
じゃあ例のコンポーネントが含まれてるDLLを直接呼んだらどうなんだ?ってことでcompreg.datを手作業で書き換えてあれこれやってみたけど、これもうまくいかなかった。例のコンポーネントが含まれてるっぽいabupgrade.dll以外にもそれが依存してる物があるのか何なのか、コンポーネントを無理矢理登録してみてもちっとも動いてくれなかった。というわけでこれもダメ。
他のツールはないのか!と思って検索してみたらDawnとかいう色んなメーラのアドレス帳の読み書きに対応したツールがあったんだけど、試してみたら日本語の名前や住所が見事に文字化けして全然使えなかった。ていうかそもそも自動処理できないっぽいし。
そんな感じでにっちもさっちもいかなくなったので、ヤケクソでpab.na2(NC4.xのデフォルトの個人用アドレス帳。Personal Address Bookの略でpabらしい……というのはどうでもいい話ですね)のバイナリとにらめっこしながらデータ構造の解析を試みてみた。試行錯誤した結果、全部のフィールドに違う値が入ってる時に関してはなんとか個々のカードの内容を吸い出せるようにはなった(!)んだけど、複数フィールドに同じ内容が入ってたり複数カードのフィールドに同じ内容が入ってたりすると、そこだけ圧縮かかるみたいで全然うまくいかない。どういう順番でどこを読みに行けばいいのかさっぱり分からん……
ちなみに、ここまでの時点でFirefoxのコードを参考にしてnsreg.dat(NC4.xのプロファイル名とプロファイルのありかが保存されているバイナリ)の解析には成功してるので、後はホントに*.na2の中身をどうにかして取り出せさえすればインポートを自動化できるのに!という非常に悔しい状態なのです。ああもうっ。
Tuhnderbirdには標準で、メールを暗号化したりデジタル署名を付けたりする機能(S/MIME)が含まれている。しかし、これに使う証明書はベリサイン等で購入する必要があるので、ちょっとテストしてみたいという場合にはけっこう難儀する。
これについて、いわゆるオレオレ証明書でS/MIMEのテストをやる手順を以下にまとめておく。テストした環境は、Ubuntu 8.04とWindows XP。
これで、秘密鍵と公開鍵のペアができた。次に、送信者側の設定。
これで送信者側の設定は完了。新しくメールを作成して、ツールバーの「セキュリティ」ボタン(錠前のアイコン)の右の▼をクリックし、署名するだけの場合は「このメッセージにデジタル署名する」にチェック、暗号化する場合は「このメッセージを暗号化する」にチェックを入れて、自分宛に送信してみよう。受信したメールを選択すると、Subjectや送信者名などが表示されている欄の右端に、錠前(暗号化されたメール)や封印(署名されたメール)のアイコンが表示されていれば、S/MIMEでメールを送信できた事が分かる。
ちなみに、この状態で署名や暗号化されたメールを他の人に送った場合、受信者側では、署名されたメールでは封印のアイコンにバッテンが付いたアイコン、暗号化されたメールでは錠前にバッテンが付いたアイコンに加えて「このメッセージを復号できませんでした」というメッセージが表示される。
というわけで受信者側でも以下の設定が必要になる。
本当はこの後「他の人の証明書」他部を選択して同じ手順で証明書(公開鍵)をインポートする必要があると思うんだけど、ここまでで出てきているmail.crtは適当に作ったオレオレ証明書で認証局証明書と兼用になってしまってるので、「他の人の証明書」でインポートしようとしてもうまくいかなかった。
ともかく、認証局証明書にオレオレ証明書を登録した状態で、先程の送信者からの署名済みメールを受け取ると、Subject等の欄の右端に表示される封印のアイコンからバッテンが消える。
暗号化の方はよくわかんない……オレオレ証明書を一個だけ作るんじゃなくて、認証局証明書と個人用証明書の二つを作ってもう一度実験してみないといけない?
会社のサイトのコンテンツが一新され、コンテンツにブログが加わりました。何をやってる会社なのか(何ができるのか)分からんと言われがちなようなので、みんながちまちまやってる内容をここに書いていって、「当社ではこういうことができます」的な宣伝材料にする、というのが一応の目的のようです。
で、自分もアドオン開発者向けの自動テストツールであるUxUの使い方の解説なんかを書いてみました。ツールの使い方というよりは、「はじめての自動テスト」みたいな感じになってしまってますが。自分自身がまだ自動テストのことをよく分かってなくて須藤さんとかにしょっちゅう「何考えてんだ(全然分かってねえな)……」的な指摘を受けてばかりなので、自分の理解レベルに合わせるとこんな感じになってしまいました。技術力とか実績とかのアピールの場のはずなのに、こんな低レベルな記事を載せてしまうと却って会社の印象に泥を塗ってしまうんじゃなかろうか、ということをamachangのエントリとか見て思いもしましたが、もう後の祭りです。
UxUのマニュアルのつもりで、またそのうちXUL/Migemoのテストでの利用例の解説の続きを書くかもしれません。
あと、サービス→Mozillaサポート 実績紹介→Thunderbird用アドオンと辿ったページでThunderbird用の地味なパッチもいくつか公開しています。中にはもしかしたら同種のアドオンがすでに世の中にある車輪の再発明な物もあるのかもしれませんが、探すより作った方が早かったんで……