この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
原因は分かって、patchを書いたものの、それを検証できない。 インストーラをビルドしようとしても、GREのアンインストーラをビルドする時にnsinstall.exeが見つからないというエラーで止まってしまう。何故。
ようやくスーパーレビューが通ったので、あとはチェックインを待つのみ。
Bug 1658はスーパーレビューで若干のNGが出たので、バージョン管理の都合上、このバグがチェックインされた後に再修正を行う予定。
リファラやUA名に(おそらく)自分のサイトのURIを記述してあちこち動き回るという新手のスパム発見。 早速リファラの集計のブラックリストに追加。
こんなスパム活動やめてください。
メッセンジャーとMozillaを併用しているときとか、ウインドウ幅を縮めている場合にやたらと不便に感じる。
本人が思っている以上にブックマークでの中クリックを使用しているということかな。
ようやく一つ終了。
二、三日待っても反応が無い場合は個別に担当者にメールを出さないと駄目です。 特に、superreviewの場合、Bugzillaからのリクエストはほとんど機能してません。
とりあえず、Bug 1658の修正パッチのコンセプトを解説。 IME関連のバグは基本的にこの仕組みで修正するしか無いと思う。
まず、おおまかな概略図は次のようになる。
まず、nsWindowクラスがnsTextEditor*Listnerクラスに対してクロスプラットフォームなイベントを生成する。 この部分は大抵、既存のルートがあるはず。 通常、ここからイベントに応じて処理を行う訳だが、今回はnsEditor内で処理を行う必要があったので、nsIEditorIMESupportインターフェースにメソッドを追加して、nsEditor内でイベントを拾えるようにしている。 今回追加したのは、フォーカス取得と、フォーカス喪失イベントの二つである。
これらのイベント内で今度はIMEを操作する必要がある。 しかし、nsEditorはクロスプラットフォームなソースコードのため、当然、OSのAPIを直接呼び出せない。 そこで、OSのAPIを呼び出せるクラスで、nsIKBStateControlクラスをスーパークラスに持つクラス、Windowsの場合はnsWindow、他のOSの場合はnsWidget等のクラスに共通のAPIを追加して、このAPI内で各OSごとに処理を行うことになる。
今回、このバグはWindowsでしか修正は終わらない。 しかし、クロスプラットフォーム部分の修正は終わるので、他のOSではこのAPIを実装するだけでバグ修正が行える。 ちなみに、APIの実装だけで済むのはmac/、cocoa/、photon/、gtk/のみ。 gtk2/やos2/、beos/等はnsIKBStateControlクラスそのものをnsWidgetか、その派生クラスに実装する必要がある。
若干の問題は残っているが、ひとまず修正した。
Macでは問題があるということで春永さんがreopenした。
ただ、Macで今まで何の症状もなかったという話と、今回のスクリーンショットを見る限りではMac固有のソースコードに問題があると思う。
今回のパッチは単に、line-heightを1にするだけのものだが、理屈としてはこれは正しいはずである。他のOSでは、一行入力用のinput要素の場合、その内容領域は一行分のスペースのみが割り当てられている。ここに、1より大きいline-height値を与えると、行間のためのスペースを無理矢理とろうとする。このため、文字が押し下げられていたのが今までのバグの原因である。それに対してMacでは綺麗に表示されていたというのは、一行分以上の内容領域が与えられていたか、行間のためのスペースを中和するだけ押し上げられていたかのいずれかの方法を、Mac単独でアドホックに対応したのではないだろうか。最初のスクリーンショットにあるように、ボタンのテキストの位置を見ると、意図的に後者の手法をとっているように見えるのだがどうだろうか。
私はMacユーザへの対策として一時的にバックアウトされるのは仕方が無いと思う。だが、原因の所在を明確にしておかなくては、このバグは事実上wontfixと同じ扱いになってしまう。なぜなら、もうひとつの解決策である内容領域を広げるという手段は使えないからだ。
文字の大きさを現在のままとし、line-height: normal;に耐えられる内容領域を確保しようとすると、そのinput要素のある行の行高自体が大きくなり、様々なページでレイアウトが崩れる可能性が高い。そのため、この手段は使えない。では逆に、文字の大きさを小さくして余裕をもたせようとする。すると、今度は小さすぎてアクセシビリティの問題が出てくるのでこれもできないだろう。バックアウトするかどうかは別として、今回の修正が最終的に取り入れられ、MacのWidgetまわりを他のOSにあわせることがより良い修正方法であると思う。
音声読み上げブラウザで数値を思い通りに読み上げさせる方法のひとつとして、lang属性、xml:lang属性を使うのが良いのかもしれないですね。例によって、たぶん、実際にはここまで実装は進んでいないとは思うのですけど。
例えば、ドラクエ2を記述すると、普通、2をツーと読み上げさせたいんじゃないかと思います。にではなく。この場合、ドラクエ<span xml:lang="en">2</span>とすればツーと読み上げてくれそう。しかし、厳密に考えると、xml:lang="en"で、英語として記述されたことになるのでツーではなく、tû:と発音されることになってしまうんでしょうか。これではアヤシげな英語を喋る人ですね(笑)
ところで発音記号で長音を表すセミコロン似の記号ですが、無いんですかね。とりあえずコロンで代用しましたが……
ついに修正完了。 以下の設定項目でカスタマイズ可能。
パスワードフィールドにフォーカスを移す際にIMEをOFFにするかどうか。 falseだと、OFFにする。
パスワードフィールドからフォーカスが出る際にIMEの状態を元に戻すかどうか。 falseだと元に戻す。 ime.password.onFocus.dontCareがtrueの場合、この設定は意味を持たない。
偶然発見。実装された模様。
問題が多いということで、残念ながらバックアウトされてしまった。
キーボード入力周りを改善したので、他の言語での入力も可能になってます。
あとはフォント周りの改善と、検索ダイアログの改善ができれば、ようやくUnicode対応エディタと言えるかな。
MozillaZine日本語版で横スクロールバーが表示されていた問題。ようやく修正された。
それにしても、本家に先に報告されているが、Bugzilla-jpで最小テストケースを作るまで待って欲しかった。Berndがテストケースを作ってくれているが、あのレベルのハッカーがこれに時間を割くのは勿体ないことだ。
動的疑似クラスでマージンの相殺がおかしくなるという問題が修正された。 似た様な問題を前に見つけていたように思うのだが、思い出せない……
ビット研というサイトもapplication/xhtml+xmlの模様。
WebSiteManagerを使ってくれている人がどういう人なんだろうかと、ふと考え込んでしまいました。
そもそも、プログラミングの勉強がてらに、普段から不便に感じてたHTMLコーディングの問題点をつぶしてくれるツールを作っていこうと考えて作り始め、その後で私にとって都合の良いツール、機能の追加を行ってきました。 そんな開発経緯ですから、万人向けな訳がありません。 付属のツールもHTMLエディタとしてはありきたりのものばかりなので、特にWebSiteManagerがぬきんでている点はありません。 Unicode対応でも、まだまだ不十分な点があり、他のUnicode対応エディタにはかないません。 こう考えると、本当に良いところが無いわけです。
でも、使ってくれている人は(少数ですが)確実にいるようなので何か良いところがあるんでしょうね。 とりあえず、作者である私は、Web標準化プロダクトのおかげで、数多くのHTML文書を解析、修正する機会がありました。 これにより、様々なHTML文書でテストが行われています。 また、Weblogを移転前は全て手作業で更新していたため、非常に多数の更新を行うために便利なツールを実装し、デバッグにもなっていました。 こういったことから、ひょっとすると実戦向きなのかもしれません。
文字列の変換や、特殊な貼り付けにあるような、手軽なツールであれば実装が簡単なので何か要望があれば、私宛にメールを投げてもらえると実装されてしまうかもしれません。 あと、バグ報告は大歓迎です。 基本的には逐一、修正していっています。 もし、修正不能なバグが出てきても、その問題が重要だったり、他にも大きな問題がある場合、再設計する際にその修正を考慮に入れることになるので最終的には修正されるかもしれません。
とりあえず、次のバージョンではいよいよエディタのパーサの再設計にとりかかる予定です。 今のパーサのソースコードはスパゲッティ状態なので、もっと柔軟なエンジンに書き換えて現在あるバグを一掃しようかと企んでいます。
本家の方でJungshik Shinに召喚されたのでソースコードを検証してみた。 ところが今の設計の駄目っぷりを思い知らされただけだった。
まず、現在のFind Toolbarを利用した検索には二種類の処理系等がある。
ひとつはCtrl+Fによる通常検索のモード。 これは、見た目通り、Find Toolbarが入力を受け付け、ボタンを押すことによってJavascript(browser.js)上で処理を行っている。
それに対して、もうひとつのモード、FAYT専用モードが問題である。 こちらは、Find Toolbarは形骸にすぎない。Find Toolbarは今までのステータスバーと何ら変わりの無い、表示するためだけのシロモノである。 どういうことかと言うと、FAYTの入力を受け付けているのはbrowserウインドウそのものである。browserウインドウでkeypressイベントが発生すると、その時に押されたキーコードと、それまでに入力されていた文字列とを合成し、新たな検索文字列とする。 この文字列をFind Toolbarにセットしているだけである。
ところが、keypressイベントではIMEの文字は受け取れない。 何故ならキーが押されることと、実際の入力があったこととは関係無いからだ。 ここで、Windowsプログラミングに詳しい人ならWM_CHARの様にイベントを生成すれば解決するかと思う人もいるかもしれないが、この手法では絶対に未確定文字列の処理もできないことにも注意が必要だ。 つまり、現在のFind Toolbarの実装方法でIMEの入力を受け付けていないのはバグであるというよりも、そもそも不可能な設計なのである。
国際化問題に対して正常な理解があればFind Toolbarはバックアウトされるべきである。 しかし、Mozilla Foundationがあの目玉機能を諦めるとは考えにくい。 CJKユーザには不便な日々が延々と続きそうな気がする。
明日から月曜日まで大阪へ行くのでメール等では連絡がつかなくなります。
修正された。 斉藤さんに感謝。