文句を言うのは簡単で、結果を残すのは大変

Mozilla 開発から遠ざかっていたのだけれど、Mac 版を開発している人が TSM(IME, 要は仮名漢字変換) イベント周りを書き直した後のトラブルを見てコードを見ました。

結果を残すのは大変です。口は出したけれど、自分でパッチを作る技術と時間がありません。

問題が起きたのはイベントハンドラを Classic Event から Carbon Event に書き直そうとした Bug-org 332579 の作業が終わってからで、追跡するバグが Bug-org 337199 として登録されました。

Bug-org 332579 - Improve Mac event handling for 1.8.1
https://bugzilla.mozilla.org/show_bug.cgi?id=332579
Bug-org 337199 - Keypress events for RETURN key processed but return nsEventStatus_eIgnore (RETURN key events double-processed)
https://bugzilla.mozilla.org/show_bug.cgi?id=337199

Mac OS X で Classic アプリを Carbon アプリにするには、イベント処理を Carbon 風にしなくても構わないんです。Classic Event (あの WaitNextEvent() ) + Apple Event のままで一応動きます。ただし CPU パワーをよけいに食う重いアプリになります。

Firefox/Thunderbird はずっとイベント周りが Classic Event + Apple Event でした。今実用されている 1.5.0.x もそうです。ただ、やっぱり重いのはユーザへの印象が悪いので、Firefox 2 を前にそこを Carbon Event に書き直す開発者が現れました。そしたら書き直しが不十分で仮名漢字変換が動かなくなりました。いつ直るかと期待して見ていたら、TSM(IME) 周りを Apple Event に戻せば動くから戻す作業が始まりました。

ちょっと待て、今更戻るのか、と怒ってソースコードを見てみたら、確かに大変です。キーイベントを格納する構造体に Apple Event のデータ構造への参照があって、イベントを処理するコードがそれを参照しているんです。Apple Event を見るのを止めて Carbon Event を見て処理しようとすると、大量の関連コードを書き直す必要が出てきます。

私にはキーイベントハンドラのオーバーホールはできません。さて、誰かがやるのでしょうか。

なお Firefox 3 は Cocoa アプリになる予定です。現在の Camino のソースコードが使われる予定です。

Camino で、候補ウィンドウが左上に固定される件を本家 Bugzilla に報告してみる

Mozilla の開発に戻ってきた、のかなあ。

Bug-jp 4586 - [Mac, Camino] 日本語入力変換時に候補ウインドウが正常な位置に表示されない。 を本家 Bugzilla に Bug 308471 - implementation of protocol NSTextInput -firstRectForCharacterRange(), -characterIndexForPoint() need to be more correct として報告しました。

現在の Camino は、変換中の候補ウィンドウが常に画面左上(アップルメニューの下)に表示されるはずです。Cocoa widget は変換中の文字列が画面上に表示されている位置を TSM(IME) に渡していないからです。

開発者も分かっていて、他にもたくさんのバグがあるようで、Wiki に " International Input bugs として記されています。

and some bugs are probably lurking here.

私は Firefox で見ておりました

年下の先達の Blog にて「もっとOperaを使おうよ」と呼びかけられましたが、私は Firefox で見ておりました。今も SuSE Linux 9.2 (on VMWare Workstaion 5) の Firefox から投稿していたりして。

先日の投稿の通り Mac 版 Mozilla(Gecko) の開発から降りたのですが、閲覧環境入れ換えまでには至っていません。

私個人の事情で Opera に対抗意識があるのが一番の邪魔です。

Mozilla を降り、Helix Player for Symbian に乗りかけ

親しい人への連絡のような投稿です。

1. Mozilla のソースコードを読むのを止めます。これは簡単なのですぐにできます。
   
2. Helix Player for Symbian のソースコードを読むことに決めました。これは難しいので、できていないようならせっついてください。
   

理由は Series 60 ならびに Symbian OS のプログラミングを覚えたいからです。Mac 版 Mozilla のソースコードを読みつづけたときに勉強することになるだろう Cocoa は勉強としては面白いです。でも Cocoa は勉強で終わるのに対して Series60/Symbian OS は職場で使う可能性が結構あるんです。趣味と実益をかねる作業をしたくて。

夢は大きく、まずは一歩から

Blog "Well, I'm back" に Gecko 1.9 の目標が載りました。

夢が盛りだくさんです。こんなことができるのかとうれしくなり、また、できるのだろうかと不安になります。どれだけすごいかはご自身でお読みください。

私自身が参加するとして、Mac の日本語環境と言うニッチな分野に微力ながら参加できるかどうか。まずはバグ出しです。社会人として他にやるべきことが盛りだくさんで時間がないのは脇において。

誰かが一頑張りするべきとき

今、[Bug 157967] Make Gecko interoperate better with advanced typography systems such as ATSUI, Uniscribe, Pango & STSF で大事で面白い話をしています。ここで日本語を話す人が参加しないと、近い未来の Firefox/Thunderbird のα版で日本語が表示できなくなるかも知れない話を。

討論の題名は、Windows や Linux 含め UNIX や Mac OS X での文字表示の国際化をプラットフォームの機能を生かすものに変えよう、という意味です。変えればいいじゃないか、と言うだけなら簡単な話です。かなり作り直しが必要で滅多にできることではなく、いざ作り替えようとなった今こそよく考えなければならないんです。本当に、作り直しなんですよ。

ここで、説明のために意味のとれない一段落を置いてみますね。

This is a pen. This is aペン. This is a pen. This is aペン. This is a pen. This is aペン. This is a pen. This is aペン. This is a pen. This is aペン. This is a pen. This is aペン. This is a pen. This is aペン. This is a pen. This is aペン. This is a pen. This is aペン. This is a pen. This is aペン. This is a pen. This is aペン. ...

上の段落を現在の Firefox/Thunderbird が表示するときには、改行しそうにない位置で分割して文字列の幅を求めて行を折り返しています。まず決められたフォントで "This" がどのくらいの幅になるかプラットフォームに確認して、空白を入れて、次に "is" がどのくらいの幅になるか確認して、"a" がどのくらいの幅になるか確認して、そのまま "pen" を横に書けたらいいけれども画面の端(あるいはテーブルの端)に来ているようだと改行してから "pen" の幅を確認して。

この方法は簡単だけど、それで正しく表示しようとすると Firefox/Thunderbird が世界の言語にかなり精通していないといけない訳です。まず改行していい位置も変わります。"pen" の途中で改行するとおかしいけれども「ペン」の間には改行が入れられますから、その違いを知っていなければなりません。さらに空白の開け方・詰め方が変わります。「aペン」を日本語で書くときには "a" と「ペン」に微妙に空白を入れたいですが、それを Firefox/Thunderbird が知らないと空白を開けられません。そんなこんなで、ある程度読めるようにするには楽だけれど、きれいに表示しようとすると地獄の道です。実際、あんまりきれいに表示できていません。

そんな話を、現代のデスクトップシステムはプラットフォームが持っています。Windows なら Uniscribe、Linux 含め UNIX では GTK+ 上の Pango、Mac OS X では ATSUI、という機能がそれを受け持ちます。これらは大体似た作りをしています。少なくとも一段落全てを先にプラットフォームに渡して欲しいということです。

先の段落だと "This is a pen. This is aペン. This is a ..." をプラットフォームに渡します。すると「a と pen の間に改行をいれて、a と ペン の間に空白をいれて...」とひとしきり考えた後、結果全体をアプリケーションに返します。アプリケーションはその結果を全部覚えておいて、後で表示するときに使う、というのがマナーです。

「This の幅がこれで、is の幅がこれで...」と動かしたらどうなるか。プラットホームは一応は文句言わずに動きますが、とても遅いです。それは嫌がらせじゃありません。段落全部任せてくれるときと同じように考え込んでしまうのです。

現状の Firefix/Thunderbird はいわば単語ごとの幅の確認しかしないのを、段落を一気に計算する動きに変えないとプラットフォームの国際化機能は使いこなせません。その話がようやく動き始めました。

しかし日本からコードを書いたり少なくともこの話に参加する人がほとんどいません、これはとても危険なことです。正直な話、欧米のプログラマに日本語は読めません。日本語が読めないプログラマが日本語の表示のバグに気付くことはありません。無料のソフトウェアだから「日本人は金持ちだから日本語に対応すると売れるぞ」という動機も発生しないので、もともと言葉を知っている人がプログラミングしないと勉強してプログラミングしようという気もなりません。

すると、チェックは欧米の言語だけになされて、日本語を表示してみたらダメダメだったということが起きても全く不思議はないんです。このままでは。

日本人プログラマだって他の言語で起きるバグは分からない訳ですから他人のことをとやかく言えませんし。

私は気持ちだけあるのでにわか勉強中。しかし追いつける方が不思議です。今はまだ、アジるだけ。

水道水と生水

ぽっとでの思いつきを大発見と思い込むのが好きです。

Mozilla Firefox や Mozilla Thunderbird の、Release Build (リリースビルド)と Nightly Build (ナイトリービルド)の違いを一言で言うとこうなるんだろうと思いつきました。

水道水版

Release Build (リリースビルド)
味より安全性重視です

生水版 または 冷や水版

Nightly Build (ナイトリービルド)
おなかを壊した人が実際に多数居ます

「リリースビルドも水道水の安全性に届いていない」とか「古いナイトリービルドより新しいリリースビルドの方がおいしい」という突っ込みは脇に置きます。

そして、次の質問にはどう答えていいか分かりません。

「おいしくて安全なミネラルウォーターはないの?」

ブラウザを立ち上げ損ねても気にしない話

mozillaZine 日本語版に、Thunderbird は Windows の標準ブラウザの設定が壊れていると http:// のリンクをクリックしても反応しないという話が投稿されていました。投稿主は、Eudora のように実行ファイルが見つからないときはファイル選択のダイアログを出すなど対策をとるべきだとお怒りの様子。

そこでソースコードを見てみました。

リンクを選択したときのメソッドから見るのではなく外部アプリケーションを呼び出すコードからボトムアップに見ているので間違えているかも知れませんが。

不満を漏らした人は Thunderbird がブラウザへのパスを記憶していると思い込んでいる節がありますが、私は Thunderbird はブラウザへのパスを記憶していないと思っています。なぜなら Windows には URL だけ渡せば関連付けされたアプリケーションを呼び出す ShellExecute() という API があるから。
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shellexecute.asp

Thunderbird も、この API を使用しています。
http://lxr.mozilla.org/mozilla/source/uriloader/exthandler/win/nsOSHelperAppService.cpp#251

しかし、この API がアプリケーション起動に失敗したことを無視するとしたらちょっとおかしいです。API リファレンスを見てもエラーを示す返り値が返ります。では Thunderbird がこのエラーコードを見ているのかという話ですが。

ShellExecute() を呼び出しているのは nsOSHelperAppService::LoadUriInternal() というメソッドで、LoadUriInternal() というメソッドを呼び出すのは nsExternalHelperAppService::handleExternalLoadEvent() というメソッドだけ。このメソッドがエラーコードを握りつぶしています(返り値を変数に代入することも return 文で返すこともしていません)。
http://lxr.mozilla.org/mozilla/source/uriloader/exthandler/nsExternalHelperAppService.cpp#1088
このメソッドは OS 中立のモジュールなので、どの OS でもブラウザの立ち上げに失敗したことは見ていないことになります。

じゃあエラーコードを返せばいいのかというと、本当はここからが大変なんです。ユーザにエラーを伝えて、リカバリーして。私にはそこまでの技術力がありません。

Bug 61363 が起きる原因を見る (その1)

Bug 61363<meta> with charset and autodetection should NOT cause reload (loads twice/two times)
ページをダウンロードしたときに文字集合の自動検出によって文字集合がユーザ設定と違うと分かったときに再度 GET/POST を発行してしまう、という日本人にとってとんでもないバグ。いきなり大物から見ていくのは、自分の力を考えていないから。

HTML 限定と当たりをつけてソースを読むと nsHTMLDocument::StartDocumentLoad() というメソッドにて nsHTMLDocument::StartAutodetection() というメソッドが呼ばれている。(POST の場合は自動判定しないという Mozilla ユーザにはおなじみの条件が入っているので間違ってはいないと思う)
http://lxr.mozilla.org/mozilla/source/content/html/document/src/nsHTMLDocument.cpp#857

nsHTMLDocument::StartAutodetection() というメソッドの心臓部は nsICharsetDetectionAdaptor::Init() というメソッド。
http://lxr.mozilla.org/mozilla/source/content/html/document/src/nsHTMLDocument.cpp#666

nsICharsetDetectionAdaptor クラスはインタフェースしか定義しておらず
http://lxr.mozilla.org/mozilla/source/intl/chardet/public/nsICharsetDetectionAdaptor.h#50
実装しているのは nsDetectionAdapter クラス
<>http://lxr.mozilla.org/mozilla/source/intl/chardet/src/nsDetectionAdaptor.h#98

nsDetectionAdapter::Init() は中心部で nsMyObserber::Init() というメソッドを呼んでいる。
http://lxr.mozilla.org/mozilla/source/intl/chardet/src/nsDetectionAdaptor.cpp#137

この nsMyObserber::Init() メソッドは mNotifyByReload というフラグが立っているとリロードを実行してしまう。
http://lxr.mozilla.org/mozilla/source/intl/chardet/src/nsDetectionAdaptor.cpp#67
自動検出を担当するオブジェクトにリロードをするための機能が用意されているところまでは分かった。

するとこのフラグがどこで何のために立つのかを見るべきなのだけれど、ここからの見通しが立たない。

このフラグを立てるのは nsMyObserber::SetNotifyByReload() メソッドだけで、
http://lxr.mozilla.org/mozilla/source/intl/chardet/src/nsDetectionAdaptor.h#79
呼び出しているのは nsDetectionAdaptor::RawBuffer() メソッドだけ。
http://lxr.mozilla.org/mozilla/source/intl/chardet/src/nsDetectionAdaptor.cpp#158
nsDetectorAdaptor::RawBuffer() メソッドを呼び出すのは static ParserWriteFunc() メソッドだけ。
http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/nsParser.cpp#2506
このとき nsDetectAdaptor オブジェクトを保持するのは static ParserWriteFunc() メソッドの引数 closure 。
http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/nsParser.cpp#2453
ParserWriteFunc の文字が現れるのは nsParser::OnDataAvailable() メソッドの中で nsIInputStream オブジェクトの ReadSegments() メソッドの引数としてだけ。
http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/nsParser.cpp#2564

ここから nsIInputStream オブジェクトと nsParser::OnDataAvailable() メソッドの使われ方を見るべきだけれど、今夜はもう眠い。