この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2008年12月)

2008年12月4日

Bug-org 451204 Highlighted text is white on white text on a yellow background, difficult to read 初回投稿日時: 2008年12月04日05時21分01秒
カテゴリ: Firefox Mozilla Core バグ修正
固定リンク: id=2008120400
リンク元: 0件
SNS: (list)

既に半月ほど前に修正されたバグですが、この辺の元々の設計を行ったので解説しておきます。

バグの元々の内容は検索文字列のハイライト時のテキストがシステムの選択時の文字色をそのまま使っていたため、Windowsのように白い文字が使われている場合には黄色背景だと読めない、というものでした。これを一旦黒い文字を利用するようにしていたのですが、通常の背景が白のページで、WindowsやLinuxでは背景色が黒で文字色が黄色になってしまうということでreopenされていました。

背景色と前景色が入れ替えられていた理由は、その要素の背景色と選択文字の背景色に十分なコントラストが確保されていない場合に選択文字の前景色を背景色に利用する方がよりコントラストが確保できるので、入れ替えて見やすくする、という機能が働いていたためです。Macはこの機能の実装当時に、関係者からの反対でこの機能自体が無効になっているため、Macを利用している開発者には問題無く動くように見えていた、という不幸な理由もこのバグの発生に一役買っています。

詳しい「十分なコントラスト」の定義は複雑なので今回は解説しません(たぶん、過去のエントリで説明していると思うので、興味のある方は検索してみてください)が、もう既にお分かりのように、このバグを修正する一番簡単な方法はハイライト時に利用する色を白と十分なコントラストがある色に変える、ということです。

白と十分なコントラストを確保するには黄色系の色では、黒を混ぜた、かなり濁った色にしないといけませんが、これはあまりにも汚いので、蛍光ピンクのマーカーっぽい色に変更されています。また、これと十分なコントラストを保った文字色として再び白が文字色として選ばれています。

この修正の結果、以下のように表示されるようになりました("ハイライト"部分がそうです)。

この段落のテキストはハイライトの例です。

2008年12月5日

京都・一乗寺 ラーメン荘 夢を語れ 初回投稿日時: 2008年12月05日04時34分22秒
最終更新日時: 2008年12月12日19時55分25秒
カテゴリ: ラーメン
固定リンク: id=2008120500
リンク元: 0件
SNS: (list)

京都の一乗寺でも一番変わり種のラーメン屋です。とにかく肉。肉。肉。

小ブタラーメンの写真

こちらが一緒に行ったKENZさんの注文していた「小ブタラーメン」です。肉がすごいですが、この肉の下には野菜がどっさり入ってます。

小ラーメンの写真

そしてこちらが普通の「小ラーメン」。ちなみに、この店のラーメンは小でも200グラムもあるので(普通は一玉で120グラムぐらい)、初めて注文するときに小ではないラーメンを頼まないように注意しましょう。

麺は太くて、独特です。スープは醤油がキツく、肉も塩分がたっぷりなので、関西人の舌に合うんだろうかと思ってしまいますが、行列のできる店なので受け入れられてるんでしょう。たぶん。


大きな地図で見る

奈良・押熊 河童ラーメン本舗 押熊店 初回投稿日時: 2008年12月05日05時07分18秒
最終更新日時: 2008年12月12日19時56分01秒
カテゴリ: ラーメン
固定リンク: id=2008120501
リンク元: 0件
SNS: (list)

本店は大阪千日前の河童ラーメン本舗です。店のサイトによると、各店で自由にやってるらしく、確かに味は店それぞれ癖があります。この写真は奈良の押熊店のものです。

チャーシュー麺煮卵入り

写真は「チャーシュー麺煮卵入り」。極細麺に濃厚な背脂入りで醤油のよく効いたスープが絡まってます。

河童ラーメン本舗はキムチが食べ放題なのが珍しいです。


大きな地図で見る

2008年12月6日

大阪・箕面 らーめん菜菜 初回投稿日時: 2008年12月06日03時37分42秒
最終更新日時: 2008年12月12日19時56分44秒
カテゴリ: ラーメン
固定リンク: id=2008120600
リンク元: 0件
SNS: (list)

小洒落た雰囲気のお店、らーめん菜菜です。大阪箕面で171号線沿いにある店で、女性客が他のラーメン屋より多いように思います。

玉子入りラーメンの写真

写真は玉子入りのものです。非常にあさっりとしたスープでチャーシューもあまり脂っこくありません。空腹時には逆に物足りないのではないかというぐらいにさっぱりとした味なので、こってりしたラーメンが苦手な方や、二軒目にという奇特な方にお勧めです。ちなみに、サイドメニューがしっかりとしています。


大きな地図で見る

大阪・鶴見 カドヤ食堂 初回投稿日時: 2008年12月06日04時16分42秒
最終更新日時: 2008年12月12日19時54分16秒
カテゴリ: ラーメン
固定リンク: id=2008120601
リンク元: 0件
SNS: (list)

鶴見の有名店、カドヤ食堂です。ものすごく並ばないとダメだと聞いていたのですが、平日の19時前に行くと並ばずに食べることができました。

中華そばの写真

「中華そば」です。丁寧に作られたスープの味が印象的です。

豚めしの写真

そしてこちらはサイドメニューの「豚めし」です。辛子を混ぜて食べますが辛くはないです。


大きな地図で見る

奈良・天理 彩華ラーメン 本店 初回投稿日時: 2008年12月06日15時48分18秒
最終更新日時: 2008年12月12日19時53分46秒
カテゴリ: ラーメン
固定リンク: id=2008120602
リンク元: 0件
SNS: (list)

関西の超有名店、彩華ラーメンです。奈良以外にも複数の府県に店舗がありますが、奈良の店舗とは味が全然違っています。天理の本店は一番お勧めです。

彩華ラーメンスペシャル(もも) 大の写真

写真は「彩華ラーメンスペシャル(もも) 大」です。大は二玉なのでかなり大きいです。醤油ベースの四川風の辛いスープに極細麺が入っていて、その上に白菜がたっぷりのっています。玉子入り、チャーシュー入りでスペシャルになります。生卵を混ぜると辛みが消えてまろやかになるので、生卵入りだと食べている最中に味を変えることができるのでお勧めです(ラージャンが置いてあるので再び辛くすることも可能です)。


大きな地図で見る

Googleマップの写真では移転前(少なくとも一年以上前)の写真のようで、畑しかありませんね。

Bug 6417 メッセージボックスが出るときに、システム既定の音が鳴らない 初回投稿日時: 2008年12月06日20時37分04秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2008120603
リンク元: 2件
SNS: (list)

Geckoのメッセージボックスは全て自前実装なのですが、これが出る時にシステム既定の音が鳴らない、というバグです。も組フォーラムにあった投稿からバグとして処理しました。

IE等、他のブラウザの挙動ともあわせてalertconfirmでは表示時にシステムで設定した音が再生されるようになっています。prompt等、他のメッセージボックスでは変わらず音は鳴りません。

ちなみにこの修正はXPレベルで音を鳴らすためのコードを埋め込んでいますが、それをハンドリングできているのはWindowsだけです。OS/2は担当者によると不要とのことでした。Macは今のところ、これを実現するためのAPIすら見つけていません。LinuxはAPIを見つけているので、Fx3.2以降で対応するかもしれません。

Bug 6438 搜狗拼音输入法が入っている環境で、智能ABC输入法を使うとクラッシュする 初回投稿日時: 2008年12月06日20時40分41秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2008120604
リンク元: 0件
SNS: (list)

中国語のIME、智能ABC输入法を特定の条件下で利用するとクラッシュしてしまう、というバグです。Fx3.0.xでもtopcrashに指定されるほど重大なバグでした。

しかし残念ながら中国に詳しい開発者が居なかったため、スタックトレースからは再現条件等が分からずに長期間放置する結果となりました。バグのフィードバックの重要性があらためてよく分かるバグでした。

実際の修正にはえむけいさんの提案が多々盛り込まれています。どうもありがとうございました。

Bug 6443 [Cocoa] gmailでESCキーを押すと、未確定文字列が確定されてしまう 初回投稿日時: 2008年12月06日20時46分14秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2008120605
リンク元: 0件
SNS: (list)

Gmailのメール作成画面のエディタで未確定文字列がある状態でESCキーを押すと、Macでは未確定文字列がキャンセルされずに確定されてしまうというバグです。

Gmailではkeydownイベントやkeyupイベントをハンドリングしていて、ESCキーを押すとエディタからフォーカスを移動させるようにしています。何故Windowsではこのバグが発生しないかと言うと、IMEの未確定文字列がある状況ではキーイベントを一切発行していないためです。

MacでもIMEの未確定文字列がある場合はキーイベントを発行しないようにしていたつもりでしたが、単に条件に漏れがあり、イベントが発行されてしまっていました。今回の修正でキーに関わらず、一切のキーイベントがIMEの未確定文字列がある状態では発行されないようになっているはずです。

Macでしか動作確認していないWebアプリケーションは無いとは思いますが、ある意味では大きな仕様変更ですのでWebアプリの開発者の方は注意してください。

Bug-org 467593 "WARNING: GetCharCode used for wrong key event; should use onkeypress." should not be displayed by Web pages 初回投稿日時: 2008年12月06日22時22分12秒
カテゴリ: Javascript Mozilla Core バグ修正
固定リンク: id=2008120606
リンク元: 0件
SNS: (list)

Bug 6443の修正中に発見されたバグです。デバッグビルドだと、keypressイベントではないキーイベントのcharCodeプロパティにアクセスすると警告が出力されていました。

ただ、これはWebアプリケーションのバグを示しても仕方がないですし、Webアプリケーション作者も通常のビルドで見れるようになっている方が好ましい、ということでそのように修正しています。Webアプリケーション作者の方はキーイベントで誤ったロジックが無いかどうかをエラーコンソールで確認できるようになっています。

Bug-org 458588 remove uses of -moz-outline* and drop the aliases afterwards 初回投稿日時: 2008年12月06日22時26分22秒
最終更新日時: 2008年12月06日22時33分02秒
カテゴリ: CSS Mozilla Core バグ修正
固定リンク: id=2008120607
リンク元: 0件
SNS: (list)

-moz-outline*プロパティがドロップされたようです。今のところ、trunkのみの修正で、コメントによるとFx3.1ではサポートを継続しそうに見えます。

タイミング悪く、記事を書いてる間にtinderboxが炎上したため、一旦バックアウトされています。

2008年12月9日

Bug 6417 メッセージボックスが出るときに、システム既定の音が鳴らない #2 初回投稿日時: 2008年12月09日16時43分33秒
最終更新日時: 2008年12月09日17時14分46秒
カテゴリ: Mozilla Core
固定リンク: id=2008120900
リンク元: 2件
SNS: (list)

先日修正したこのバグですが、現在のところユーザが設定を変えるにはWindowsのコントロールパネルでOS全体の設定を変更するしかありません。

その様にした理由の一点目は、アプリケーションはXPなものであっても、できる限りそのOSでのネイティブアプリケーションの挙動に従うべきであるという考えに基づきます。Win32APIからメッセージボックスを表示する場合、指定したアイコンの種類に応じて、否応なく設定されたサウンドが再生されます。ここに、アプリケーションが介在する余地はありません。

次にメッセージボックスの出る頻度ですが、これは非常に少ないと言わざるを得ないと思います。まず私自身、一日どころか一週間に一度もメッセージボックスを見ていません。くでんさんの意見によると、ウインドウを頻繁に閉じる上に、タブの存在を確認するダイアログを出す設定のままにしてあるので他のアプリケーションよりも頻繁に出てくる、とのことですが、これは使い方の問題だと思います。例えば、秀丸で新規ウインドウを開き、何らかの編集を行って閉じようとするとメッセージボックスが出ます。秀丸の新規ウインドウをちょっとしたメモ書きに利用して頻繁に閉じる、というのであれば同じように頻繁にメッセージボックスが出てきます。くでんさんの言う頻度の高さは、メッセージボックスが不当に大量に出現している訳ではなく、使い方が頻度を高めているのであって、一般的なアプリケーションに比べてFirefoxが極端に多くの回数メッセージボックスを出しているのではないと思います。

続いてMozilla Firefox Thunderbird の拡張あれこれ-MEMOさんの意見では、Javascriptのデバッグ時にalertを多用するので鬱陶しいと書かれています。しかし、私はalertはデバッグで用いられるべきではないと思います。その理由は、非同期処理の結果が変わってしまう点や、フォーカスが移動する点にあります。少し複雑なJavascriptのコードであれば、デバッグ用のalertがコードの挙動を変えてしまいます。Firefoxでのデバッグなら、dumpを利用してみてはどうでしょうか?

ちらし◎のうらさんの意見は少し興味深いかもしれません。確かにこのケースでは一般的なアプリケーションに比べて明らかにメッセージボックスの開く回数は多いと思います。ですが、この件こそシステム設定に従って、きちんと確実にユーザに警告を出すべきケースのように思いますがどうでしょうか? ユーザは音を頼りにメッセージボックスの出現を感じ取ろうとしているのかもしれません。音が鳴らないのは深刻なアクセシビリティの問題を抱えていると言って良いと思います。またこのケースは本当に音が原因であるのか、UI設計に問題があるのではないのか、そこもじっくりと考えるべきなのかもしれません。

Firefoxではシステム既定の音を鳴らさない、というユーザ設定をFirefox内で持ち、チェックすることは可能です。手間もあまりかかりません。パッチを書くことが決定すればすぐに用意できるでしょう。しかし、そのパッチの必要性について私がレビュアを説得する材料は持ち合わせていません。ユーザがカスタマイズできる項目は細かければ良いというのは気持ちは分かりますが、それも限度があります。その限度はレビュアが納得するかどうか、というところにあります。レビュアを説得できなければ過剰な細かさである、ということです。

メッセージボックスの音を鬱陶しいと感じる人(私もそうです)がなぜシステム設定では音を出したがるのか、ここが私の一番の疑問点です。メッセージボックスはモーダルダイアログです。つまり、メッセージボックスを生成したスレッドはメッセージボックスを出したところで一旦停止します。つまり、音が出なかったことで気付かなかったから不利益を被る、という状況は自動で長時間、何らかのジョブを行わせるようなアプリケーションで問題になるだけで、ブラウザのようにインタラクティブな利用方法がメインのアプリケーションでは視覚に不自由が無いユーザには問題無いのではないか、というのが私の意見です。Fxでのみ音を消したい、という方は、他にメッセージボックスが多く出現するアプリケーションを使いたくなった時に、逐一、そのアプリケーションに音を消す設定を追加してくれと要求していくのでしょうか?

今回、三つのサイトの方から意見を頂いていますが、こういったUIの変更への不満に関するフィードバックは大抵、本家bugzillaにすぐに来ます。しかし、今回はまだ来ていません。こういったケースは初めてのことで、どの程度のユーザが同様に不満に感じるのか計りきれずに居る、というのが正直なところです。

ちなみに、Windows2000以降で、問い合わせ(confirmダイアログ)時に音が標準で出る設定になっているのはWindows2000のみで、WindowsXPとWindowsVistaは警告(alertダイアログ)でしか音は出ないようです。

2008年12月10日

京都・一乗寺 天宝 初回投稿日時: 2008年12月10日04時20分43秒
最終更新日時: 2008年12月12日19時52分41秒
カテゴリ: ラーメン
固定リンク: id=2008121000
リンク元: 0件
SNS: (list)

一乗寺でもなかなかに食べることができないことが多い店、天宝です。オフィシャルサイトにも書いてますが、不定休なんですよね……

角煮ラーメンの写真

写真はこの店のメインメニューらしい、角煮ラーメンです。醤油ベースというにはちょっと変わった味でした。作っているところを見ていると、通常のラーメンのスープの上に野菜と軽く餡っぽくした醤油色のスープをかけ、そして具を載せていました。個人的にはおいしかったのですが、ややとんがった味なので好みが分かれるかもしれません。


大きな地図で見る

2008年12月11日

Bug 6461 メニューに関連するシステム既定のサウンドが再生されない 初回投稿日時: 2008年12月11日07時55分19秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2008121100
リンク元: 0件
SNS: (list)

本家のbug IDが83056と、5桁なのでかなり長期間修正されなかったバグです。Windowsのシステム音にはメニューを開いたときの音とメニューの項目を選択して実行した場合の音というのが定義されていますが、Geckoはこれらのシステム音を鳴らしていませんでしたが、ようやく鳴るように修正しました。

2008年12月15日

2008年12月17日

Bug 6302 [Win] windowlessのFlashでIMEが利用できない #2 初回投稿日時: 2008年12月17日05時25分59秒
最終更新日時: 2008年12月17日05時27分52秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2008121700
リンク元: 0件
SNS: (list)

数ヶ月かかってようやく修正完了しました。

Windows版のGeckoはwindowlessプラグインに対して特定のネイティブイベントのみを仲介しています。なぜ全てのネイティブイベントを送信していないかと言うとパフォーマンスの問題や設計上の問題があるからです。

このバグの原因はどちらかというと後者の問題でした。Geckoのwidgetはネイティブイベントを元に、コンテンツがXPレベルで処理するためのGeckoイベントを生成します。プラグインのインスタンスをlayoutで管理しているnsObjectFrameはそのXPイベントに保存されているネイティブイベントをNPEventでwindowlessプラグインに渡しています。このため、Geckoが必要としていなかったイベントはwindowlessプラグインに送信されていなかった、ということが分かるかと思います。そう、解決策は送信していない必要とされているネイティブイベントを全て送信するだけです。実に単純な話でした。

ですが、実装は単純にはいきません。まず、IME関連のイベントは以前からGeckoイベントが存在していますが、これをそのまま流用する訳には行きません。Geckoイベントとネイティブイベントが1対1の関係には無いからです。また、それ以外のイベントもwindowlessプラグインがフォーカスを持っていない時にはこれらのイベントを送信する必要はありませんし、副作用の方が恐いので安全な方法を考えなくてはいけませんでした。

そのためにまず、新しいプラグイン専用のイベントを定義し、これを利用することで他のコンテンツがフォーカスを持っている場合の挙動に影響が出ないようにしています。そして、エディタ以外ではIMEは利用できないことを利用し、プラグインがフォーカスを持っている時には全てのネイティブなIMEイベントをそのまま新しいイベントで送信するようにしています。

ですが、Adobeとの調整に手間取ったこともあり、Fx3.1b2に修正が間に合わなかったので、NPEventの仕様をおおっぴらに変える訳にはいきません。そこで、Flash Playerの場合にのみ、新しいNPEventを生成するようにして、Flash Player以外でregressionが出ることを防止しています(Fx3.1後にこの制限を外して仕様書を変更予定)。

これでプラグイン側がwindowlessモードであっても本格的に対応することが可能となりました。Flash Player以外でも新しいイベントを送信して欲しいプラグインがある場合、そのベンダ側からリクエストがあればすぐにGecko側は対応できるようになっています。ですが、この新しいイベントをハンドリングする必要があるため、プラグイン側のアップデートも当然必要です。このため、実際にFlash PlayerのwindowlessモードでIMEを利用するには、新仕様のGeckoと、これに対応したFlash Playerの両方が必要になります。前者はFx3.1がその最初のリリースバージョンになる予定です。後者は既にAdobeからテスト用にもらったインターナルビルドでは実現されていますが、正式リリースの予定はまだ聞いていません。

ちなみに、windowlessモードは上記のメカニズムから分かるように、パフォーマンスには難があるのでWebサイトの開発者がこのモードを入力フォームに利用することは推奨しません(そもそもアクセシビリティの問題が大きすぎますが、その問題がなくてもです)。CSSとの親和性が高いのはwindowlessモードですので、windowlessモードを使わないといけない理由(CSSを利用したメニューと重なる場合や、半透明にしたい場合等)がある場合のみ利用すべきモードでしょう。

2008年12月18日

大阪・大東市 しせんらーめん 住道店 初回投稿日時: 2008年12月18日03時11分30秒
カテゴリ: ラーメン
固定リンク: id=2008121800
リンク元: 3件
SNS: (list)

大阪、大東市の小洒落た感じのラーメン屋さんです。阪奈沿いです。

四川こっさりチャーシュー麺の写真

写真はこっさりのチャーシュー入りです。写真には写っていませんが、チャーシューの下にチンゲンサイも浮かんでました。麺は極細です。

普通のままだとあまり辛くないので、テーブルに置かれている「魔法の唐辛子」をバサッと入れてあげるとピリ辛な感じが楽しめました。

チンゲンサイのみ入っている「四川ラーメン」だと550円と、異様に安いお店ですが、味は悪いわけではなく、むしろ好みでした。しかも食べたら150円の割引券をくれました。


大きな地図で見る

2008年12月20日

Bug 6462 [Win] ハングルのIMEでキャレットが常に変換文字列の最初に表示される 初回投稿日時: 2008年12月20日05時40分46秒
最終更新日時: 2008年12月20日05時41分47秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2008122000
リンク元: 0件
SNS: (list)

Windowsに標準で付いているハングルのIMEでは未確定文字列の先頭に常にキャレットが表示されるというバグです。

問題のIMEはキャレット位置を問い合わせると、常にゼロが返されていたのが直接の原因です。えむけいさんの指摘通り、IMEからの情報を無視して問い合わせているGeckoもまずいのですが、IMEが非サポートのプロパティへのアクセスにエラーコードを返さなかったのもこのバグが長年修正されなかった原因だったわけですね。

IMEのようなミドルウェアを作る立場からするとあらゆるアプリケーションのバグから逃れて正常っぽく動作するためにエラーを返さない、という手法が良いのかもしれません。そう考えると納得がいくのですが、アプリ開発者からすると、自分達の間違いを見つけるのが困難になるのがたち悪い話です。

GeckoのAPIも本当はエラーであっても(既存の動作との互換性のために)意図的にエラーを返さないものを書いたことがあるのでなかなか難しいことなのかもしれません。GeckoのAPIもそんな感じですので、Fxの多くのアドオンにも大量のバグが含まれているかもしれません。おそらく全てのXPCOMコンポーネントのメソッドをtry-catchで保護して呼び出しているアドオンというのは少ないでしょう。こういったアドオンに潜在しているバグもバージョンアップ時に問題になっているのかもしれません。

2008年12月23日

Bug 3611 マウスでフォームのセレクトを選択できない 初回投稿日時: 2008年12月23日06時27分20秒
最終更新日時: 2008年12月23日06時31分15秒
カテゴリ: Mozilla Core バグ検証中
固定リンク: id=2008122300
リンク元: 0件
SNS: (list)

:hover { position: relative; }という指定があるとドロップダウンリストがうまく機能しなくなるというバグです。今となってはすごく変なスタイル指定ですが、IE全盛だった頃であれば、このスタイルはa要素ぐらいにしか効かなかったので、このようなセレクタの使い方はよく見かけました。ですが、今となっては、このような間違った指定でモダンブラウザの方が苦しめられている、という訳です。未来への互換性、という点ではWebデザイナは標準仕様を常に遵守するか、コンテンツを永遠にメンテし続けないといけない、ということが分かる話ですね。

それはさておき、このバグは、マウスカーソルの下にあるCSSのボックスが異なるものになる度にそのボックスの要素をルートとしてreflowが発生してしまい、コンボボックスもドロップダウンリストも再生成されてしまうというのが原因です。これにより、初期状態、つまりドロップダウンリストが閉じた状態に戻ってしまっている訳です。

Geckoのコンボボックスのドロップダウンリストはコンボボックスが生成して所有しているオブジェクトである、というのがこのバグが発生している一番直接的な設計のマズイ点でしょうか。しかし、このへんを正直に正攻法で修正するのはちと大がかりなことになりそうに思えます。

現在提案しているパッチは、ドロップダウンがreflowによって自動的に閉じられてしまっても、reflow終了時に自動的に再度開かれるというものです。見た目は不格好ですが、ひとまず、アクセシビリティ上の問題は避けられそうです(まだいくつか修正すべき問題がありますので日程的にももうFx3.1には厳しいですが)。

大島さんの環境のようにLinuxではこれがクリティカルなアクセシビリティバグであるケースもあるようなので、本来なら無理をしてでも修正すべきなのでしょうが、正直なところ、このへんのコードには詳しくないのでコードフリーズの近いFx3.1での修正は断念した方が良いように思えます。さすがにkey hellの再現は嫌ですし。

2008年12月28日

ANS-9010 初回投稿日時: 2008年12月28日01時26分34秒
最終更新日時: 2008年12月28日01時27分46秒
カテゴリ: 雑談
固定リンク: id=2008122800
リンク元: 1件
SNS: (list)

先日ゲットしたANS-9010をようやく設置してみました。

ANS-9010のパッケージ ANS-9010の外観

で、蓋を開けて、CFDのDDR2 PC2-6400 2GBのメモリ、W2U800CQ-2GL5Jを8枚挿したのが次の写真です(メモリを挿す前の状態も写真にとっていたのですが、手ぶれがひどくてお見せできるものではありませんでした)。

ANS-9010にメモリを8本挿した写真

二枚だけ色が違いますが、全て同じ製品です。ANS-9010の発売前からメモリを買い進めていたので購入時期が少しずれているのが原因だと思います。

そしてANS-9010の最大の欠点である、電源断で全てのデータが失われる、という問題の対策のためにSATAの電源に給電できるACアダプタが付いている、UD-505SAをゲットしてみました(ついでに、PC本体内の配線のためにSATA電源の延長ケーブルも一緒に購入)。

UD-505SAとSATA電源ケーブルの延長ケーブル

で、ウキウキしながら電源を入れてみると、BIOSから認識できず

当然、Windows上からも認識できませんでした。

SATAホストやメモリとの相性を最初は疑ったのですが、どうもUD-505SAのACアダプタからの給電がうまくいっていない模様でした。PCの電源から給電すればあっさり認識したのです。

ANS-9010のLED類は正常に点灯していたので、全く通電していない、という訳ではないようでしたが、メモリ枚数を減らしたり、バッテリを外したりして消費電力を抑えてみても認識させることはできませんでした。

認識さえすれば、当たり前ですが、あっさりHDDとして扱えるようになりました。

ディスクマネージャから見たANS-9010

16GBじゃなくて14GB強になっているのは、総容量の1/9はECCエミュレーションのために利用されているためです。i-RAMではデータが壊れてしまうことがあったので、この機能はとてもありがたいです。

電源の問題を解決できたら、ビルド環境を今のSSDから、こちらに移す予定です(以前はi-RAMを利用していましたが、データが時々壊れるのと、4GBという容量の少なさからSSDに変更していました)。

2008年12月31日

Bug 6468 [Cocoa] deadkeyを初めて入力しようとすると失敗する 初回投稿日時: 2008年12月31日20時41分07秒
最終更新日時: 2008年12月31日20時44分11秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2008123100
リンク元: 0件
SNS: (list)

Macでデッドキーを初回入力時のみ、入力できなくなっていたというバグです。

Macのデッドキーの入力はIMEで実現されています。例えば、アクセント記号を入力した段階で、アクセント記号が未確定文字列として表示されます。ですが、その実装が(表向きは)同じベンダの製品であることえり等のCJKのIMEとは違っているようで、Bug 6369Bug-org 447635の際に追加したIMEへのウインドウレベルの通知タイミングをずらしたのがバグ自体が発生してしまった原因でした。

ですが、本当の原因は他にあり、Bug-org 447635ではAppleのドキュメントにある通りの実装を行ってもATOK(2006)でのみうまく動きませんでした。ATOKはプロパティを設定しても、activate時にしかそれを反映していないバグがあるようで、これに対する回避用のhackyなコードがデッドキーの入力をキャンセルしてしまっていたことが本当の原因でした。

この回避コード自体をATOK以外の場合に走らせないことが一番安全なのですが、Macでは現在のキーボードレイアウトがどのIMEのものであるのかを検査する手段がありません。そこで、キーボードレイアウトが日本語用かどうか調べて、日本語の場合のみこの処理を走らせるようにしています。

それにしてもATOKはWindows版、Mac版を問わず挙動におかしなところが多々あります。個人的にATOKユーザなので事細かく対応できていますが、ATOKユーザじゃなかったら無視しているバグも多々あると思います。ジャストシステムにはもう少しバグの修正を頑張ってもらいたいものです。フィードバックを返そうとしても、お客様窓口、みたいなところしかなくて普通のユーザと同様の定型的な返し方されるので困ったものです。ミドルウェアという他のアプリケーションとの連携ができて初めてまともな製品たりうるものなのですから、開発者向けのちゃんとした窓口を用意してもらいたいものです。

ちなみに、このバグでもMacOSのひどすぎる互換性に苦しめられています。もうレガシーな10.4は切り捨てて欲しいですね。

IMEのベンダに感じる問題 初回投稿日時: 2008年12月31日21時07分10秒
最終更新日時: 2009年01月08日15時22分05秒
カテゴリ: 雑談
固定リンク: id=2008123101
リンク元: 1件
SNS: (list)

愚痴ついでにIMEまわりの修正を行っていて常々感じている問題点を列挙しておきます。IMEのベンダの関係者の方が見ていたら、是非、検討していただきたいことです。

問題点1: 開発者向けのライセンスがない

開発者向けのライセンスがないため、IMEまわりのデバッグを行うには製品のライセンスを通常通り買い続けないといけません。常用しているWindowsのATOKでは年一回、製品のバージョンアップがありますが、それ以外にもMac版のリリースがあったり、他のIMEのライセンス購入もしなくてはいけなかったりと、やたらと金食い虫です。そのため、絶え間なくIMEを各アプリケーションのベンダは買いそろえ続けなくてはいけません(さすがにMS Office等の高額製品を買わないと入手できないMS-IMEは完全に断念していますが)。もし、買い損ねたまま、販売が終わってしまっているIMEとの連携に問題がある場合、そのIMEを持っていないと対応不能に陥ってしまうからです。ダウンロードで、ある程度古いバージョンから最新のバージョンまで入手できるライセンスというのは必要だと思います。

問題点2: 英語のUIが用意されていない

開発者としてIMEまわりのテストや実装を行っていると、自分の知らない言語のIMEであっても利用しなくてはいけません。これは漢字を利用しない開発者にとってはより深刻な問題です。

現在、ほとんどのメジャーなソフトウェアは英語圏で開発されています。当然、日本語や中国語の言語処理についてはある程度の開発はできても、それらの言語を読み書きできる開発者はほとんど居ません。そのため、日本語や中国語ができる開発者が居ない製品では特定のIMEとの連携を改善するためには英語版のUIが無ければ、実際にインストールしてテストすることができないのです(バグの現象自体は言語を知らなくてもレポートからなんとかなりますが、環境作りはいかんともしがたいのです)。

当然、UIそのものだけではなく、ダウンロードの案内等、一通りのサービスが英語で提供されていなければ意味がありません。先日のAdobeのFlash Playerの開発者にATOK固有の問題を対応してもらうのにも、この言語の問題で非常に難航しました(ATOKの最新版のみ、幸い、ダウンロードで30日試用できるようになっていたのは大きかったです)。

問題点3: システムロケールがIMEの扱う言語と異なる場合に動作しない

未だにUnicodeベースではないアプリケーションが多いWindows固有の問題ですが、Windows版のIMEは未だにUnicodeアプリケーションになっていないものが多いです。

ATOKももちろんそうですし、中国語のIMEでもいくつか見受けられます。これらのIMEをテストするためにはシステムロケールをそのIMEにあわせて再起動する必要があり、とても効率よく開発できるようなものではありません。

そろそろ全てのIMEにはUnicodeアプリケーションに移行してもらいたいものです。

文意は変えていませんが、色々と加筆修正しています。あまりにも変な文章だったので。