この日記はMozilla Japanのプロダクトへの貢献を中心に書いていますが、断り書きがある場合を除き、 オフィシャルな発表ではありません。あくまでも個人的なものです。 Mozilla Japan、Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
ちなみに、誰の日記なのかよく分からないという方はInside Mozilla Japan内の 私の自己紹介 を参照してください。
Macのかなパレット等のソフトウェアキーボードから文字を二文字以上入力できないというバグです。修正終わりましたが、Fx3.0.xでも修正すべきバグなのかどうかは今のところ分かりません。
ソフトウェアキーボードであっても、キーイベントからエミュレートしている場合は再現しません。単純にアプリに対して文字入力イベントだけを発行していると、このバグが障害になります。
最近、時々見かける「エキスポート」という単語、文脈等からすると"export"の訳語のようなのですが、私は「エクスポート」の方が一般的だと思ってました。現に様々なソフトウェアでのUIや用語解説等でも「エクスポート」という表記が一般的に用いられています。しかし、双方の単語でGoogleで検索してみると、「エキスポート」の方が桁違いに大量のWebページが引っかかってきます。
うーん。どうしたことでしょう。既に市民権を得ている表記なんでしょうか。
そういえば、"Firefox"のカタカナ表記、一応オフィシャルなものがあるのをご存知でしょうか。決まっていたはずですが、私は忘れました(笑)
dom.event.contextmenu.enabledがfalseだとLinuxで発生するバグです。
問題の設定だとコンテキストメニューを開くべきイベントが抑制された後でもその状態を強制復元させる、というのが原因です。他のプラットフォームでは再現しないのでwidgetのバグかと思ったのですが、コードの理屈から考えるとコンテキストメニューイベントを復元している部分のXPなバグだったようです。
他のプラットフォームでは単純に各プラットフォームのネイティブイベントの仕様の都合と、プラグインのそれらの処理の都合上、バグの再現条件が整っていなかっただけのようです(面倒なのできちんとは調べていませんが)。
border-styleにridge、groove、inset、outsetが指定されていると、rgbaで半透明色を指定していても、ソリッドカラーで表示されてしまう、というバグです。
これらのスタイルでは指定されている色よりも明るい色と暗い色を算出して、それらを使ってレンダリングするのですが、この色算出時にalpha値を継承しないようになっていたのが原因です。単に半透明色に対応した時の修正漏れですね。
このバグも全然報告がなかったようなので、これらのスタイルは人気がないのかもしれません。実際に表示される色がブラウザ依存なので、ということでしょうか。
contenteditable属性を削除した場合、編集モードを終了すべきなのですが、実際に編集はできなくなるものの、内部の要素の状態が完全には元に戻らず、フォーカスを受け取ったりできなく、IMEの状態管理もおかしくなるというバグです。
属性の削除時の処理に問題があり、実際の削除がスーパークラス内で終了する前にエディタの状態を終了させようとしていたのが原因でした。何故属性の変更時にはこのへんがきちんと考慮されているコードになっていたのに、削除時のみだめだったのか不思議です。
それにしても、本家ですらバグ報告がなかったので、contenteditableの利用というのはほとんど無いのかもしれません。
MSThemeCompatibleが利用されている場合、Windowsのテーマを無効にした場合のようにクラシックなスタイルで各種コントロール類を表示するのですが、スクロールバーのクラシックな見た目を定義しているCSSに問題があり、こんなバグが発生していました。
単に、スクロールバーのボタンの背景画像を中央付近に表示するように修正しただけです。
ただ、コードや挙動を見ている限り、本来であればCSSの指定を使うのではなく、nsXPLookAndFeelのクラシックテーマのレンダリング機能を使うべきであるようです。