もずはっく日記(2009年5月)

なんとか無事に帰国 初回投稿日時: 2009年05月01日22時50分16秒
最終更新日時: 2009年05月02日00時21分51秒
カテゴリ: 雑談
固定リンク: id=2009050100
SNS: Tweet (list)

なんとか無事に帰国しました。報道されているように私も検疫を機内で受けましたが、これのなんと無駄なことか。一時間以上機内で拘束された後、通常の関空の検疫の列(長蛇)へと誘導されましたが、これが間違いでした。機内検疫を受けている場合は通常の検疫は必要無く、横のゲートからそのまま入国手続きに移れたはずだったのです。

また待たされるのかとUA客の苦情から、間違いに気付いた係員が戻るように声をかけますが、この係員も含めて誰もまともに誘導もしないものだから、引き返そうとするUA機の乗客と検疫を受けないといけない客の流れがぶつかり、にっちもさっちも行かない渋滞状態に。

まわりの関西人のおっちゃん達、当然のごとくキレ出しますが、それでも何もしない係員達。自分の本来の持ち場以外はどうでも良いようです。更に係員の一部はUA機の人間でも再度検疫受けてくださいと声を出す人まで出る始末。まったく統制というか段取りができていない馬鹿達の仕事っぷりでした。

その後、UAの乗客達は未検疫の乗客と接近した後にそのまま別のゲートから入国手続きへと移りました。検疫後に(良くない方に)状況が変わってる訳ですが、そんなことおかまいなしです。さらにひどいことに、長蛇の列に並ばずにゲートを通過する人が、検疫を受けたUA機の客かどうか誰もチェックしていませんでした。

ただでさえ意味の薄い検疫なのに、ここまでずさんで何の意味があるんでしょうか? 公務員は馬鹿ばかりかと思わされた一日でした。というか、こんな無意味なことに税金使うな、と心底思いました。

Steven Michaudと会えた 初回投稿日時: 2009年05月03日08時11分44秒
カテゴリ: 雑談
固定リンク: id=2009050300
SNS: Tweet (list)

先日、USで初めてSteven Michaudと会えました。なかなか気さくなおっちゃんという感じの人で、漢字なんかは少しだけ分かると言ってました。

もし、去年のMacのFlashのIME問題で騒いだ人で、この人の名前覚えてない人が居たら、心底軽蔑します。そう、あのバグを修正してくれた人で、今もAdobeとFlashのIMEのハンドリングの改善について作業してくれている人です。

日本語は当然、分かる訳ではないので(日本語喋ることはできませんと、マンガのような台詞はマスターしておられましたが)、IMEの対応はやっぱりしんどいというのが本音かもしれません。

Bug-org 476062 box-shadow applied to form controls should drop the native look 初回投稿日時: 2009年05月04日07時17分13秒
最終更新日時: 2009年05月04日07時23分37秒
カテゴリ: CSS Mozilla Core バグ修正
固定リンク: id=2009050400
SNS: Tweet (list)

少し前にtrunkと1.9.1branch双方で修正されたバグですが、CSSネタとしておもしろいので紹介しておきます。

ネイティブテーマを利用しているフォームコントロールにbox-shadowを適用した場合にも常に四角の影が適用されるのはよろしくない、というバグです。

結果としてWebKitと同様にネイティブテーマ時にはbox-shadowを無視するという挙動に修正されています。テストケースを参照してもらうと分かるように、ファイルコントロールと画像は対象外です。前者はネイティブコントロールの組み合わせ、後者はネイティブコントロールですら無い、ということです。

このバグの興味深い点はCSSの暫定仕様には何も違反していなかった点です。現在の(publicな)最新仕様では、

The ‘box-shadow’ property attaches one or more drop-shadows to the box.

とあるので、本来、その要素が作り出したボックスの影であるべきです。追加で以下のような追記もあります。

If the box has a nonzero ‘border-radius’, the shadow is rounded in the same way.

ボックスの角がborder-radiusで丸められている場合は影もそれと同様に丸めるべきだとあります。完全にボックス自体の影であると仕様書のエディタ達は考えていると思われます。

ここで、フォームコントロールというものは何なのかを考えてみましょう。

CSS3ではappearanceというプロパティが追加されることでコントロール可能になりますが、CSS2.1では置換要素として考えるしか説明がつきません。つまり、仕様的にはボタン等は前景であって、background-*やborder-*はボタン等の背景のボックスに適用されるべきであると私は考えています。ですが、実際の実装ではこれらのプロパティが指定されると前景であるべきフォームコントロール自体の見た目を変更します。CSS3の仕様書(ドラフト)でもそうするべきである旨が明記されています。もちろんこちらの実際の挙動の方がデザイナにも喜ばれる動作であり、好ましいと思いますが、CSS2.1では説明できない特殊な存在になってしまっています。

つまり、今までの発想ではbox-shadowはCSSがレイアウトのために作り出したボックスに対してかかるべきであって、前景のフォームコントロールの形を意識した影であってはいけないと、仕様書を素直に解釈した場合に考えられると思います(CSS2.1+CSS3 box-shadowというレベルでの話)。実際に、このパターンを考慮していなかったGeckoはそのようにレンダリングしていた訳です。

ですが、やはりネイティブコントロールに四角の影が付くのは直感的にすごい違和感があります。WebKitでは影をネイティブコントロールには適用しない、という乱暴な手法が利用されていました。Geckoもこれに合わせています。乱暴ですが、単純だから、というのが一番の理由です。

理想的にはネイティブコントロールの形の影を描画するようになるべきでしょう。しかし、そのためには複雑な処理が必要となりますが、それに見合うだけの価値があるのかどうかはよく分かりません。また、そもそもネイティブなコントロールに影があること自体がネイティブな見た目ではなくしてしまっていると言えるかもしれません。

Bug 6377 [MozillaBuild] x64環境ではVSやSDKのパス取得に失敗する 初回投稿日時: 2009年05月07日17時12分18秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009050700
SNS: Tweet (list)

出したのすら忘れていたパッチですが、trunkに取り込まれたようです。近日リリース予定のMozillaBuild 1.4には入ってることになるそうです。

Bug 6380 IMEの状態をJavascriptのコードから取得できるべき #2 初回投稿日時: 2009年05月07日17時21分25秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009050701
SNS: Tweet (list)

IMEの有効、無効等を自動テストで実現するために、状態を取得するAPIを追加しました。

nsIDOMWindowUtils::IMEIsOpenでIMEのオン/オフ状態を、nsIDOMWindowUtils::IMEStatusでIMEの状態(有効、無効(パスワードエディタ用)、無効(非エディタ用)、プラグイン用)が取得できます。

IMEの状態は内部的にはnsIWidget単位で管理されています。これが意味するのは、要素毎にIMEの状態を持っている訳ではないということです。また、複数のnsIWidgetで一つのコンテキストを共有していることもありますが、この辺はプラットフォーム依存です。ですので、これらのプロパティで取得できる状態をキャッシュしないでください。つまり、必要がある場合は逐一、これらのプロパティから最新情報を取得してください。

これらのAPIはIMEの状態をかなり低いレベルのまま取得できるので、Geckoの今後の仕様変更の影響をダイレクトに受けることに注意してください。これらは拡張からも利用できるようにしているだけで、かなりunstableであることは保証しておきます。

Bug 6541 [IMM32] IMM32のコードはnsWindowから分離されるべき #2 初回投稿日時: 2009年05月07日17時29分57秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009050702
SNS: Tweet (list)

従来からのIMM32のハンドリングを行っているコードをnsWindowから分離しようというバグでした。

IMEのコードは最近でこそ減りましたが、昔はよくnsWindowの修正時に誤って壊されていることがありました。このような理由から、IMEと関係無い開発者からはIMEのコードはできるだけ分離しておく方が好ましいです。

また、WindowsのネイティブコードのレビュアもIMEに詳しくないので、現状のモジュールオーナーシップのルール上、無駄というとアレですが、スムーズな開発ができなくなっていましたので、コードを独立させることでレビュープロセスを簡略化してしまうことができます。

そして、メモリの利用をより効率的にすることができることになります。今まではIMEの利用が全く無い場合でもIMEの処理に必要なメモリを確保していましたが、それが改善されています。

Bug 4416 IME未使用時のフットプリントの向上 初回投稿日時: 2009年05月07日17時35分27秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009050703
SNS: Tweet (list)

本家のバグのIDからしてもかなり古いバグ(本家では2002年末に登録)の修正です。

Bug 6541でIME関連のコードを分離したため、そのクラスを初めて必要になった時にインスタンスを生成することでIMEの無いキーボードレイアウト利用時には若干ですがフットプリントを改善しています(今時のPCやスマートフォンでも困ることは無かったはずですが)。

Bug 6602 [IMM32] IMEがインストールされている環境だと、フォーカス移動でnsIMM32Handlerのインスタンスが生成される 初回投稿日時: 2009年05月07日17時41分11秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009050704
SNS: Tweet (list)

Bug 6541の修正で、IME関連メッセージの処理をnsIMM32Handlerのインスタンスで処理するようになりましたが、インスタンスが必要無いメッセージの処理でもインスタンスを作成してしまうため、IMEがインストールされている環境では意図通りにメモリを削減できていない、というバグです。

IMEがインストールされていない環境であれば、WM_IME_*メッセージが来ないのですが、IMEを一度でもインストールしたことある環境だと例えIMEが使えないキーボードレイアウトに変更していたとしても、フォーカスを移動しただけでWM_IME_SETCONTEXTが送信されてインスタンスが生成されてしまっていました。例えば、TSFしか利用しない場合であってもインスタンスが生成されてしまっていた訳です。

この修正では一部のハンドラをstaticなメソッドとすることでインスタンスを生成せずに処理するように改善しています。

Bug 4461 [IMM32] IMEマウスイベント時、文字列の位置情報が狂っていることがある 初回投稿日時: 2009年05月16日02時50分26秒
最終更新日時: 2009年05月16日03時06分26秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009051600
SNS: Tweet (list)

IMM32で、MS-IMEのマウスイベントを有効にするには未確定文字列の位置情報が必要なのですが、それを非常にいい加減に取得していたので全然まともに動かないよ、というバグです。

今までは特定の位置にある文字のオフセット等を取得する方法が無かったので、未確定文字列が一文字入力されるたびに、キャレット座標が変わるので、その位置情報から何番目の未確定文字の矩形を推測していました。もちろん、こんな方法なので、等幅フォントでなければ、変換することによって文字幅が変わってしまい、位置情報がまったくでたらめになっていました。また、未確定文字列がある状態でtextareaをスクロールしてしまうとやはり位置情報はでたらめになってしまいます。さらに、未確定文字列の位置情報を64文字までしか保存していなかった、という(あまり問題ないでしょうが)変な制約もありました。

今回、新たにwidgetのコードから特定のポイントにある文字のオフセットと、その矩形を簡単に取得できるようにしたので、情報が必要になった時に問い合わせることによって上記の問題を全て解決しています。

またこの修正により、TSFでの対応や、Macでの対応も簡単に可能になっています。

Bug 6597 [TSF] Korean Input System (IME2002) で確定した文字と未確定の文字が表示上区別できない 初回投稿日時: 2009年05月16日02時59分22秒
カテゴリ: Mozilla Core TSF Windows バグ修正
固定リンク: id=2009051601
SNS: Tweet (list)

TSFではTIPの指定するスタイルで未確定文字列をレンダリングするようになりましたが、これの弊害によって韓国語のTIPが使いにくくなっていたというバグです。

韓国語のTIPは少し変わった挙動をとります。まず、未確定文字列のスタイルに、そのままの文字色、背景色を利用するように指示が来ます。つまり、確定済みの他の文字と見分けは付きません。その代わりに未確定文字列(常に一文字)全体を覆うキャレットを表示するように指示がきます。つまり、未確定文字列全体が変化なし、反転を繰り返すのが韓国語のTIPの希望するスタイルのようです。

ですが、Geckoはcairoへの移行に伴い、反転描画はできなくなってしまいました。このため、手軽な修正で韓国語のTIPの要求する未確定文字列の表示はできません。しかも、スタイル指定だけが有効になってしまっているので、未確定文字列がどこにあるのか見分けが付きにくくなってしまっています。このため、キャレットが未確定文字列全体を覆うようになっていて、さらに未確定文字列のスタイルが通常のテキストと見分けがつかない場合は、選択された未確定文字列のスタイルを使って描画するように修正しています。

Bug 6576 [TSF] Korean Input System (IME2002) で未確定文字の先頭にキャレットが表示される (末尾に表示されるべき) 初回投稿日時: 2009年05月16日03時02分42秒
カテゴリ: Mozilla Core TSF Windows バグ修正
固定リンク: id=2009051602
SNS: Tweet (list)

Geckoでは一文字以上の文字幅で表示するキャレットの表示に対応していないのですが、韓国語のTIPがそれを指定してきた時にその範囲の先頭にキャレットを表示してしまう、というバグです。

Bug 6597の修正でキャレット位置に末尾が指定されたと読み替えるコードを入れたことで解決しています。

ATOKのime-modeによるカナロック問題について 初回投稿日時: 2009年05月21日16時56分13秒
最終更新日時: 2009年05月22日00時39分55秒
カテゴリ: Mozilla Core 雑談
固定リンク: id=2009052100
SNS: Tweet (list)

先日、リファラから知りましたが、ATOKでかな入力モードを利用している時、ime-mode: disable;のフィールドにIMEがオンの状態のままフォーカスを移すと、IMEが無効になるものの、カナロックがかかったままになる、という問題があるようです。

• フォームでime-mode:disabledしてIME使用不可にすることの問題点 - Lism.in * blog - nekoya (id:studio-m)
• はてなブックマーク - フォームでime-mode:disabledしてIME使用不可にすることの問題点 - Lism.in * blog - nekoya (id:studio-m)
• WEBマーケティング会社i-seeds社長ブログ» ブログアーカイブ » かな入力とfirefox3系列とime-mode問題
• のくす牧場 : ATOK 書庫 - JustSystems ATOK総合スレ Part41

で、どうにも要領を得ないので、物置部屋から古いATOKを引っ張り出して検証してみました。VM上のWinXPに、ATOK2007、ATOK2006、ATOK2005、ATOK17、ATOK15(ATOK16は残念ながら買ってませんでした)をインストールして、挙動をみて見ると、ATOK15でのみ、デフォルト設定で再現しました。

ちなみに、IE6でも再現するので、ATOK側の問題と考えて良いと思います(アプリからカナロックの状態を変更する方法があれば対応可能ですが、今のところその方法は分かりません)。

ATOK16では上記のリンク先に再現情報がありますので、これを信じるなら、ATOK17以降では修正が入っていることが分かります。また、ATOK2005以降には日本語入力無効のときはｶﾅﾛｯｸを解除するという設定が入力補助の設定内にあり、デフォルトで有効になっています。ATOK17でこの挙動に変えたものの、何らかの理由により、ATOK2005でATOK16以前の挙動もオプションとして用意しなくてはいけなかった、ということかもしれません。

現在の対応策としてはATOKをアップグレードするしかありません。他のIMEで再現する場合も同様です。

欲を言えば、こういった問題はきちんと報告して欲しかったのですが、今のMozillaの体制でそれを望むのは高望みなのは分かっているので、新しいバグ報告専用のコミュニティを引き続き準備中です。このコミュニティの作成・運営に興味のある方は私にコンタクトをとってください。

Mozillaの開発環境にNOD32を入れている時は 初回投稿日時: 2009年05月22日16時26分47秒
カテゴリ: Memo Mozilla Core 雑談
固定リンク: id=2009052200
SNS: Tweet (list)

Mozillaの開発環境にNOD32を入れている場合、cloneするフォルダをリアルタイム保護の除外対象としておいてください。除外しておかないと、cransh testsの485217.xslが脅威とみなされ、ファイル作成時に削除されてしまい、clone自体に失敗してしまいます。

UACを回避してソフトウェアを常駐させることができる? 初回投稿日時: 2009年05月26日23時03分49秒
カテゴリ: 雑談
固定リンク: id=2009052600
SNS: Tweet (list)

先日、IRCでUACの話をしていた時にふと思いついた話です。

一部の方に絶賛不人気なUAC、基本的には私は好きですし、これの無いWindows XPやWindows 2000を今更使いたくないです。ですが、そのUACも(悪意あるソフトウェア側からみると)抜け穴があるもので、これを利用している一番メジャーなソフトはGoogle Chromeではないかと思います。

Google ChromeはUACによる認証が必要なProgram Files配下ではなく、ユーザフォルダのAppData\Local\Google\Chrome\Applicationに強制的(勝手に、とも言う)にインストールします。各ユーザごとのフォルダは、そのユーザに所有権があるのでUACの承認無しでファイルが作れてしまうためです。これは、悪意あるソフトウェアがGoogle Chromeの実行ファイルを改竄する際にもUACで止めることができない、という非常に危険な話でもあります(この点に関しては是非ともGoogleにはあらためてもらいたいです)。

前置きが長くなってしまいましたが、この話から思いついたのが以下の話です。

同じ条件のUACによる確認が行われない重要なフォルダにスタートメニューがあります。スタートメニューの実体はAppData\Roaming\Microsoft\Windows\スタートメニューにあるためです。さらにこの中にはスタートアップフォルダがあります。そう、UACを回避して、悪意あるソフトウェアを常駐させることが可能な訳です。

もちろん、スタートアップに任意のショートカットを仕込んだり、またその前段階としてその悪意あるソフトウェアを侵入させておかないといけない、という問題はありますが、自動再生の問題を利用したりすることを考えると、ちょっと恐い気がします。

Microsoftにこの件について問い合わせたところ、仕様であるとの回答をもらったので、注意喚起のためにここに書いておきます。一応、以下の方法で、スタートメニューへの書き込み自体でUACのダイアログが出るようにすることもできますので、不安な方は対処すると良いかもしれません。

1. (設定したい)フォルダのプロパティを開く
2. セキュリティタブで詳細設定ボタンを押す
3. 所有者タブで、所有者をAdministratorに変更する
4. アクセス許可タブで編集ボタンを押す
5. 「このオブジェクトの親からの継承可能なアクセス許可を含める」のチェックを外す
6. 権限をコピーするか聞かれるので「コピー」を選択
7. 現在のユーザからのアクセス許可を削除する
8. 追加で、Usersを追加し、Usersには読み取りと実行権限だけを与える(つまり、書き込み権限は与えない)

間違いがあるかもしれませんが、その場合、blogなり、なんなりからツッコミを入れていただけるとありがたいです。