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

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

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

2012年12月18日

Bug-org 812427 Sort out event struct types in nsGUIEvent.h 初回投稿日時: 2012年12月18日22時58分50秒
カテゴリ: Mozilla Core Mozilla20 バグ修正
固定リンク: id=2012121800
リンク元: 0件
SNS: (list)

Geckoの内部イベントである、ns*Eventは、イベントの種類をuint32_tによるメッセージ定数と、イベントのクラスの実体をRTTI無しで判別できるように、uint8_tの構造型を示す定数のふたつが、似た名前で混在しており、誤解を招きやすい形になっていました。

ビルド時にこれらの取り違えミスを手軽に検出できるように、後者をenumで再定義しました。メッセージもenumにしたいのですが、こちらは試しにパッチを書いたところ、とてつもなく大きくなりそうになったのでひとまず保留しています。

Bug-org 786120 There should be default action settings for each direction which can override current settings 初回投稿日時: 2012年12月18日23時04分35秒
カテゴリ: Mozilla Core Mozilla20 バグ修正
固定リンク: id=2012121801
リンク元: 0件
SNS: (list)

D3E WheelEventの実装時に、実装上はナンセンスなので、モディファイアキーを押しながらホイールを操作した時のアクションを、X/Y/Z軸ごとに設定できないようにしましたが、えむけいさんが、ユーザが自己責任で設定できても良いのではないか、と提案されたので、それなら、オーバーライドする新規設定を追加もありですね、という話になったバグです。

えむけいさん自身がパッチを書いて、修正してくれました。感謝です。

Bug-org 819404 [TSF] Some methods of nsTextStore checks read lock, however, MSDN documents they don't allow to work without read-ONLY lock 初回投稿日時: 2012年12月18日23時12分50秒
カテゴリ: Mozilla Core Mozilla20 TSF Windows バグ却下
固定リンク: id=2012121802
リンク元: 0件
SNS: (list)

MSDNでTSFのITextStoreACPのメソッドのリファレンスを読んでいると、GetSelection()等のコンテンツ情報取得系のメソッドは、Readロックではなく、Read-Onlyロックをかけた上でアクセスするように書かれていることに気付きました。

呼び出し側からこの違いは非常に小さいことのように思えますが、実装側からすると、Read-Writeロック中に、変更されたコンテンツに、こういったメソッドで情報にアクセスできなくなる、ということになりますので、実装を非常に単純化できます。

このため、試しにRead-Onlyロックでなければアクセス出来ないように修正してみたところ、ATOK 2013も、Windows8のMS-IMEでも、Read-Writeロックで平然とアクセスしてきて、正常に動作しなくなりました。このため、この修正は断念しています。

とりあえず、両社には連絡すべきかなと考えていますが、現実的に考えればMSDNが修正されるべきかなという感じもします。

Bug-org 769548 Support ISO_Level5_Shift as AltGr too 初回投稿日時: 2012年12月18日23時20分51秒
カテゴリ: Events GTK Mozilla Core Mozilla20 バグ修正
固定リンク: id=2012121803
リンク元: 0件
SNS: (list)

GTK3では、ISO_Level3_Shiftに加え、ISO_Level5_Shiftという、もうひとつのAltGrキーが追加定義されました。

Geckoでもこれに対応し、どちらのキーが押された場合にも、DOM_VK_ALTGR(0xE1)のキーコードでキーイベントが発生し、また、押されている間のイベントでは、getModifierState("AltGraph")trueを返すように修正しました。

Webアプリからこれらのキーの違いを見分けることはできませんが、Linuxでしか見分ける意味の無いものですので、クロスプラットフォームなWebアプリの性質からすれば、この修正で十分でしょう。

Bug-org 769159 Handle ShiftLock key on GTK 初回投稿日時: 2012年12月18日23時34分59秒
カテゴリ: Events GTK Mozilla Core Mozilla20 バグ修正
固定リンク: id=2012121804
リンク元: 0件
SNS: (list)

フランス語キーボード等では、Caps_Lockではなく、Shift_Lockが一般的だそうです。これをロックすると、アルファベットだけではなく、数字キー等でもShiftキーがロックされた状態となります。

Linuxでは、Shift_Lockをロックしている間の入力イベントは、Shiftキーが押されたのと同様の挙動を示します。このため、Shift_Lockキーそのもののイベントは、Shiftキーのイベントとして発生するように修正しました。これにより、Shiftキーイベントが無いままに、getModifierState("Shift")trueを返すようになるという状況は、ひとつ減りました(もっとも、そのようなイベントの前後関係を期待したコードは書くべきではありませんが)。

Bug-org 813445 Sort out around flags of nsGUIEvent.h 初回投稿日時: 2012年12月18日23時56分01秒
カテゴリ: Mozilla Core Mozilla20 バグ修正
固定リンク: id=2012121805
リンク元: 0件
SNS: (list)

nsEvent::flagsは、uint32_tとして定義され、ビットマスクでその意味が定義されていました。しかし、その種類は多く、また大半はその意味がどこにも書かれておらず、さらに酷いことに、一部のフラグは他でも使い回されているという有様でした。そこで、これを整理しようというのがこのバグです。

当初考えていたのは、各フラグの意味をコメントで明確にし、ビット演算することなく、ヘルパーメソッドを大量にnsEventに定義して、イージーミスを回避することだけをひとつめの目標としていました。しかし、えむけいさんの提案で、C++のビットフィールドを用いた本格的なリファクタリングになってしまいました。

まず、mozilla::widget::EventFlagsという構造体を定義し、この中に1ビットのboolメンバを持たせ、各メンバにコメントでその意味を明確に説明するように修正しました。

フラグの参照側はbool変数をテストするだけですので、ビット演算によるイージーミスは無くなります(現に、修正中にイージーミスをひとつ発見しました)。

次に、nsEventDispatcherが、nsEventListenerManagerに登録されているイベントリスナを呼び出すコード部分では、イベントの処理状況を示すフラグとして、NS_EVENT_FLAG_BUBBLENS_EVENT_FLAG_CAPTURENS_EVENT_FLAG_SYSTEM_EVENTをメソッドのパラメータにセットし、フェイズやイベントグループをnsEventListenerManager側で判断できるようにしていました。しかし、これらの状態をそもそもnsEvent::mFlagsに持っていますので、nsEventListenerManagerがこれを参照するようにすることで、nsEventDispatcherまわりの単純化に成功しています。

さらに、nsEventListenerManagerにイベントリスナを登録する際にリスナの情報を指定する際に、そしてnsEventListenerManagerがこれを保存するのに、NS_EVENT_FLAG_BUBBLENS_EVENT_FLAG_CAPTURENS_EVENT_FLAG_SYSTEM_EVENTNS_PRIV_EVENT_UNTRUSTED_PERMITTEDNS_PRIV_EVENT_FLAG_SCRIPTが利用されていましたが、mozilla::dom::EventListenerFlagsという、ビットフィールドを利用した構造体を利用することで、nsGUIEvent.hからも、nsEventからも独立した情報として処理するように修正しました。

ただ、GCCではビットマスクによる実装よりも、ビットフィールドによる実装の方が若干遅い様で、極端なベンチマークを行うと、パッチ適用後はパフォーマンスが落ちていました。VCでは逆に若干の高速化が見られたのですが。ただ、どちらにしろ、Tpテストでは検出できない程度の話ですので、そのまま投入されています。

2012年12月19日

Bug-org 733630 It's difficult to resize window by dragging top border of it if the window shows Firefox button 初回投稿日時: 2012年12月19日00時06分58秒
最終更新日時: 2012年12月19日00時13分52秒
カテゴリ: Mozilla Core Mozilla20 Windows バグ修正
固定リンク: id=2012121900
リンク元: 0件
SNS: (list)

Windowsで、Firefoxボタンが表示されている時に、ウインドウの上端のボーダーでリサイズするのが難しいというバグです。半年ほど前に一度パッチを入れた時は、そのパッチに重大なバグがあり、バックアウトされましたが、このたび、ようやく修正が完了しました。

ボタンの無い部分では、システムのウインドウのボーダーの太さを参照するようになっています。ボタン上では、最小限の高さとして内部定義しているマジックナンバーで、3ピクセルだけがボーダーとして扱われます。

自分でも時々、イライラさせられているバグだったので、ストレスに感じてた方もそれなりに居たんじゃないかなと思います。無茶苦茶地味なんですが。