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

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

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

2012年11月4日

Bug-org 801101 Needs a option to scroll over one page 初回投稿日時: 2012年11月04日18時38分22秒
カテゴリ: Mozilla Core Mozilla19 バグ修正
固定リンク: id=2012110400
リンク元: 0件
SNS: (list)

D3E WheelEventの実装時に、ホイールイベントのハンドリングをまるごと書き直すまでは、どうも、1回の操作でのスクロール量を1ページ以上スクロールしないようにする、という機能にバグがあり、スクロール量を大きくして、全ページスクロールということに使えていたようでした。しかし、現在はそれができなくなってるのでどうにかして欲しい、というバグです。

色々と悩みましたが、結果的にdelta_multiplier_*が100000 (1000倍)以上の場合、ユーザはそういった操作を望んでいるものとして、スクロール量を制限しないように修正しました。

Bug-org 805357 nsIMEStateManager should always call nsIWidget::OnIMEFocusChange(false) when our editor loses focus 初回投稿日時: 2012年11月04日18時43分51秒
カテゴリ: Mozilla Core Mozilla19 TSF バグ修正
固定リンク: id=2012110401
リンク元: 0件
SNS: (list)

nsIWidget::OnIMEFocusChange(false)はこれまで、nsIWidget::OnIMEFocusChange(true)が呼ばれた時に、NS_OKか、NS_SUCCESS_IME_NO_UPDATESを返した場合にのみ、呼ばれるようになる、という変な実装になっていました。これは、パフォーマンス対策等で場当たり的な修正を繰り返したためです。

今回の修正で、編集可能なエディタがフォーカスを失う場合には、必ずnsIWidget::OnIMEFocusChange(false)が呼ばれるようになり、不要になったNS_SUCCESS_IME_NO_UPDATESは削除されました。

この修正によって、さらにwidget側のコードを単純化していくことができる見込みです。

Bug-org 805766 [TSF] TSF isn't available on designMode editor 初回投稿日時: 2012年11月04日18時54分28秒
カテゴリ: Mozilla Core Mozilla19 TSF Windows バグ修正
固定リンク: id=2012110402
リンク元: 0件
SNS: (list)

WindowsでTSFモードで動かしていても、designModeで編集可能なドキュメントではTSFではなく、IMMでIMEが動いてしまうというバグです。

designModeで編集可能なドキュメントは、要素はフォーカスを持たず、ドキュメントのみがフォーカスを持つことができるという特殊な動作を行います。このため、HTMLエディタのフォーカスイベントのハンドラがnsTextStateManagerの生成をnsIMEStateManagerに促さないといけないのですが、nsFocusManagerが、ドキュメントにフォーカスイベントを送信する前に、nsIMEStateManager::OnFocusChange()を呼び出していなかったため、nsIMEStateManagerはフォーカスを持っていると思っている要素は、直前にフォーカスを持っていた要素だと思い(つまり、別のドキュメントがフォーカスを持っていると判断され)、処理に失敗していたのがこのバグの原因でした。

修正自体は単純で、フォーカスイベントを送信する前に、nsIMEStateManager::OnFocusChange()を呼び出し、状態のズレがなくなるようになっています。

Bug-org 789881 [TSF] TSF isn't available when you open bookmark panel at first time 初回投稿日時: 2012年11月04日19時03分20秒
最終更新日時: 2012年11月04日19時03分36秒
カテゴリ: Firefox Mozilla Core Mozilla19 TSF Windows バグ修正
固定リンク: id=2012110403
リンク元: 0件
SNS: (list)

ブックマークパネルを★ボタンをクリックして表示すると、その上にあるエディタが自動でフォーカスを持つのですが、起動してから初めてこのパネルを開いた時に、TSFモードであっても、IMMでIMEが処理されてしまう、というバグです。

内部で起きている現象は、パネルを初めて表示される際にはまだコンテンツが実際には生成されておらず、編集可能ではない要素がフォーカスを持つので、IMEの状態は無効であると、判定されていました。その後、パネルが開いた時に、IMEの状態が有効になったという通知がnsTextStoreに来るのですが、どうもその更新処理が駄目らしく、TSFの有効化に失敗して、IMMモードで処理されるという形になっていました。

やや説明が曖昧なのは、実際問題、よく分かっていないためです。ですが、このバグは、Bug-org 805766の修正で、再現しなくなりました。

もし同じような状況をJavascriptから作り出せてしまうと、同様のバグがあるのではないかと思いますが、具体的な方法を思いつかないので、worksformeとしています。

2012年11月8日

FirefoxでYouTubeに時々見れない動画がある場合 初回投稿日時: 2012年11月08日13時06分05秒
最終更新日時: 2012年11月08日13時09分43秒
カテゴリ: Firefox 雑談
固定リンク: id=2012110800
リンク元: 22件
SNS: (list)

Firefoxで、YouTubeで動画が再生できない。という漠然としたツイートをちょくちょく見かけるのですが、困ってる方に症状を聞いてみると、動画のプレーヤー部分が真っ黒に表示され、再生ボタン等が出ないというものでした。

さらに、数人の方から頂いた、解決した旨のフィードバックを確認してみると、原因は、YouTubeで"HTML5 試用版"が有効になっている場合に、YouTubeのサイト内で動画を表示しようとした場合に動画がきちんと読み込めていない場合であるということが分かりました。

この問題で困っている方は、YouTube HTML5 動画プレーヤーの設定画面の下の方にHTML5 試用版が有効になっています。 と書かれていないか確認してください。その場合、その下にあるHTML5 試用版を無効にするというリンクをクリックして、全ての動画をFlash Playerで表示するようにしてください。

現在のところ、原因がFirefox側なのか、YouTube側にあるのかはよく分かっていません。読み込めない動画として教えてもらったものでも、私の環境では問題なく読み込めたり、トラブルの起きた方の環境でも埋め込み版だと正常に再生されるそうです。

さらに情報をお持ちの方は教えて頂けば助かります。

2012年11月14日

Bug-org 806996 CreateTextStateManager not called when editor is reframed during focus 初回投稿日時: 2012年11月14日13時58分50秒
カテゴリ: Mozilla Core Mozilla19 TSF バグ修正
固定リンク: id=2012111400
リンク元: 0件
SNS: (list)

Bug-org 805306の修正によるregressionで、<input type="text">や、<textarea>といった要素が、フォーカスを持っている際に、nsTextStateManagerはその匿名div要素を監視して、選択位置の変更や、テキストの変化をIMEに通知していますが、一部リフローが原因でリフレームが発生した場合に、監視している匿名div要素がエディタから削除され、新たに別の匿名div要素が使われるようになっても、古い方を監視し続けていた、というバグです。

Android版で、Google Instantがうまく動かず、未確定文字列が複製され続けるという形で症状は出ていたようです(私の端末ではIMEの違いのせいか、再現しませんでしたが)。

nsEditorからnsIMEStateManagerにフォーカスが変わったと擬似的に通知していたのですが、nsTextStateManagerはまだ、古い匿名div要素で監視が成功していると判断していたのがこのバグの直接的な原因でした。ただ、nsIMEStateManagernsTextStateManagerの設計の悪さがこのバグを招いているので、この機会に再設計を行っています。

まず、エディタからは、実際に起きたことをそのまま伝えるように、nsIMEStateManager::OnChangeFocus()ではなく、nsIMEStateManager::UpdateIMEState()を利用するようにしました。

nsIMEStateManager::UpdateIMEState()はIMEの状態に変化がない場合には、何もしていなかったので、変化がない場合でも、nsTextStateManagerが監視している匿名div要素が既にドキュメント内にない場合には作り直すように修正しています。

また、このままではIMEへのフォーカス移動通知が非常に壊れやすい設計であることも問題なので、これを確実に通知できるように、nsTextStateManagerは編集可能な要素がフォーカスを持つ場合には常に存在するように修正し、nsTextStateManagerのコンストラクタで、nsIWidget::OnIMEFocusChange(true)を呼び出し、nsTextStateManager::Destroy()で、nsIWidget::OnIMEFocusChange(false)を呼び出すようにし、確実に1:1の呼び出し回数で、ミス無く処理できるように改善しています。

また、IMEのテスト中にのみ、IMEにフォーカス移動を通知する直前にその内容をカスタムDOMイベントで、そのドキュメントに通知するようにし、自動テストでカバーしています。

この修正により、nsTextStateManagerの動作が非常に分かりやすい物になったと思います。

Bug-org 805767 nsIMEManager::CreateTextStateManager() should use nsIWidget::GetIMEUpdatePreference() rather than the result of OnIMEFocusChange() 初回投稿日時: 2012年11月14日14時08分25秒
カテゴリ: Mozilla Core Mozilla19 バグ修正
固定リンク: id=2012111401
リンク元: 0件
SNS: (list)

nsIMEStateManagerと、nsTextStateManagerの再設計、最後のバグです。nsTextStateManagerがエディタ内での選択位置の変化や、文字列の変化を通知するのは非常にコスト高なので、各プラットフォームのwidgetが望んだ場合にのみ実行するようになっていました。ただ、その通知方法が、非常にハッキーで、nsIWidget::OnIMEFocusChange(true)NS_OKを返すか否か、という、widget側の開発者からすると訳の分からないことになっていました。このバグはこれを修正しています。

e10sやモバイル用でのプロセス間通信用のPuppetWidgetがどのように振る舞うべきかを確認するために、nsIWidget::GetIMEUpdatePreference()というAPIが既にあり、この返す値が、nsIWidget::OnIMEFocusChange(true)の戻り値の代わりになることが分かっていました。

nsTextStateManagerはコンストラクタで、nsIWidget::OnIMEFocusChange(true)の戻り値を確認しないようにし、代わりに、nsIWidget::GetIMEUpdatePreference()になりました。これにより、widget側では、実装しているにも関わらず、nsIWidget::OnIMEFocusChange(true)NS_ERROR_NOT_IMPLEMENTEDを返さなくて済むようになっています。

本当であればnsIWidget::OnIMEFocusChange()の戻り値をvoidにしたかったのですが、そのためにインターフェースを変更するのも良くありませんので、そのままにしてあります。まだ承認されるかは分かりませんが、nsIWidgetのIME関連APIの再構成の祭に削除する可能性が高いAPIですし。

2012年11月16日

MacでFirefoxがメモリを2.4GBも消費をしているとか出てきた 初回投稿日時: 2012年11月16日13時29分55秒
カテゴリ: Firefox 雑談
固定リンク: id=2012111600
リンク元: 1件
SNS: (list)

MacBook Proのディスプレイを閉じておいて、数日後に開いてみると、OS全体がやたらと遅いので、アクティビティモニタで確認してみると、Firefoxがメモリを2.4GB、仮想メモリに至っては6GB以上消費していました。1時間ぐらいかけて、がんばってabout:memoryを表示してみると……

2,687.62 MB (100.0%) -- explicit
├──2,449.70 MB (91.15%) -- window-objects
│  ├──2,238.85 MB (83.30%) -- top(http://www.facebook.com/, id=12)/active
│  │  ├──2,238.56 MB (83.29%) -- window(http://www.facebook.com/)
│  │  │  ├──2,106.60 MB (78.38%) -- js/compartment(http://www.facebook.com/)
│  │  │  │  ├──1,846.57 MB (68.71%) -- gc-heap
│  │  │  │  │  ├──1,524.96 MB (56.74%) ── unused-gc-things
│  │  │  │  │  ├────245.05 MB (09.12%) -- objects
│  │  │  │  │  │    ├──133.56 MB (04.97%) ── ordinary
│  │  │  │  │  │    ├───98.10 MB (03.65%) ── function
│  │  │  │  │  │    └───13.39 MB (00.50%) ++ (2 tiny)
│  │  │  │  │  ├─────35.81 MB (01.33%) ++ shapes
│  │  │  │  │  ├─────28.73 MB (01.07%) ── arena-admin
│  │  │  │  │  └─────12.02 MB (00.45%) ++ (4 tiny)
│  │  │  │  ├────144.47 MB (05.38%) -- objects-extra
│  │  │  │  │    ├──121.99 MB (04.54%) ── elements
│  │  │  │  │    └───22.49 MB (00.84%) ── slots
│  │  │  │  ├─────69.93 MB (02.60%) -- shapes-extra
│  │  │  │  │     ├──38.81 MB (01.44%) ── tree-tables
│  │  │  │  │     ├──28.82 MB (01.07%) ── dict-tables
│  │  │  │  │     └───2.29 MB (00.09%) ++ (2 tiny)
│  │  │  │  ├─────41.12 MB (01.53%) ++ string-chars
│  │  │  │  └──────4.50 MB (00.17%) ++ (6 tiny)
│  │  │  ├────120.52 MB (04.48%) -- dom
│  │  │  │    ├──116.83 MB (04.35%) ── orphan-nodes
│  │  │  │    └────3.69 MB (00.14%) ++ (3 tiny)
│  │  │  └─────11.43 MB (00.43%) ++ (3 tiny)
│  │  └──────0.30 MB (00.01%) ++ window(http://www.facebook.com/ai.php?aed=AQL...)
│  ├────146.16 MB (05.44%) ++ (18 tiny)
2,009.25 MB (100.0%) -- js-main-runtime-gc-heap-committed
├──1,570.46 MB (78.16%) -- unused
│  ├──1,565.23 MB (77.90%) ── gc-things
│  └──────5.23 MB (00.26%) ++ (2 tiny)
└────438.79 MB (21.84%) -- used
     ├──376.57 MB (18.74%) ── gc-things
     ├───31.66 MB (01.58%) ── chunk-admin
     └───30.56 MB (01.52%) ── arena-admin
      0.01 MB ── canvas-2d-pixel-bytes
  2,685.08 MB ── explicit
      0.93 MB ── gfx-surface-image
            0 ── ghost-windows
    659.59 MB ── heap-allocated
    684.21 MB ── heap-committed
     24.58 MB ── heap-committed-unused
        3.72% ── heap-committed-unused-ratio
      1.71 MB ── heap-dirty
     41.37 MB ── heap-unused
      0.60 MB ── images-content-used-uncompressed
  2,023.00 MB ── js-gc-heap
    2,055,394 ── page-faults-hard
2,120,979,848 ── page-faults-soft
  2,480.11 MB ── resident
     20.80 MB ── storage-sqlite
  6,149.01 MB ── vsize

こんな状況でした。

GC、CC、Minimize Memory Usageを試してみましたが、いずれも効果ありませんでした。

Facebookは前々から怪しいなぁとは思っていたのですが…… ちなみに、twitterも開いてますが、そちらは消費量がここまで極端ではありませんでした。

バグとして報告した方が良いんでしょうかね……

2012年11月18日

グラフィックチップ(GPU)のドライバ、更新してますか? 初回投稿日時: 2012年11月18日08時23分56秒
最終更新日時: 2013年07月10日10時53分57秒
カテゴリ: Firefox Flash Game Google Chrome IE plugin Windows
固定リンク: id=2012111800
リンク元: 47件
SNS: (list)

注意: Flash Player 10.3のサポートは終了しましたので、ダウングレードによるトラブル回避は非常に危険です。絶対に、行わないでください。

Firefoxを使っていて、クラッシュする時に、Windowsそのものや、他のアプリケーションを巻き込んだり、ブルースクリーンが出たりと、不安定なことはありませんか?

FirefoxでFlash Playerを利用しているページにアクセスすると急にパフォーマンスが低下したり不安定になるということはありませんか?

Firefoxで動画を見るときに画面がちらついたり、描画が不安定になることはありませんか?

Windowsユーザの方で、こういった症状があるのでしたら、その原因はグラフィックチップのドライバのバグの可能性があります。そういった方は今まで、グラフィックチップのドライバを更新されたこと無い方が大半ではないでしょうか? パソコンを快適に使うには、意外とこの作業が重要ですので、現在、上述した不具合を抱えている方は是非、最新版への更新を行ってみてください。

パソコンでは、グラフィックチップ、GPUと呼ばれるチップが、ディスプレイへ出力する映像を処理しています。そして、最近のブラウザ(Firefox、IE、Google Chrome)や、Flash Player、ゲームソフト、一部のメッセンジャー系のアプリ、Windows Media PlayerやPowerDVDやWinDVDといった、ビデオを再生するアプリは、パソコンの描画のパフォーマンスを最大限に引き出すために、このグラフィックチップと直接やりとりを行っています。ですので、複数のアプリが同時におかしくなる場合、これらのアプリが同時におかしくなっている、もしくはクラッシュしているのではないかと思います。

上述のアプリがグラフィックチップと直接やりとりするときに重要になってくるのが、このグラフィックチップのドライバのデキです。そして、残念なことにグラフィックチップのドライバというのはどのバージョンであっても何らかの問題を抱えているものです。現に、NVIDIAやAMDといったメーカーは毎月のようにドライバのアップデートを公開しています。

まずはあなたのPCのグラフィックチップのメーカーを知る必要があります。Windowsキーを押しながら、pause/breakキーを押して下さい。そうすると、コントロールパネルのシステム全体の情報が表示されます。

コントロールパネルのシステムのスクリーンショット
この画面にある、「デバイス マネージャー」というリンクをクリックします。

デバイスマネージャのスクリーンショット
この中にある「ディスプレイ アダプター」のツリーを開くと、Intel、NVIDIA、AMD (古いPCだとATiかも)、いずれかのメーカー名が表示されるかと思います。その表示されたメーカーのサイトへアクセスして、ドライバをダウンロードしましょう。

Intelの場合、インテル・ダウンロード・センターにある、自動認識ツールを利用するのが簡単です。

NVIDIAの場合、NVIDIAドライバダウンロードのページにある「オプション2: エヌビディア製品用ドライバを自動検索する」のボタンから自動認識ツールを利用するのが簡単です。

AMDの場合、自動認識ツールが無いようなので、AMD.com | サポート & ダウンロードの右上にある「ドライバーのダウンロード」で必要項目を選択して絞り込む必要があります。

もし、ドライバをアップデート後に元に戻したい場合には、Windowsのシステムの復元機能を利用することで簡単に戻せますので、是非、怖がらずにチャレンジしてみてください。

なお、希に、メーカー製PCでカスタムドライバを利用しているために、グラフィックチップのメーカーには適合するドライバが無いケースがあります。例えば、VAIOには一部、電源接続時と、バッテリ駆動時にGPUをNVIDIAのものと、Intelものとを切り替えたりするものがありますが、こういったものがカスタムドライバで実現されています。こういったモデルではPCメーカーがドライバを更新してくれるのを待たなくてはいけませんが、経験上、丁寧にアップデートを出し続けてくれるメーカーは皆無です。こういったPCをお使いで、グラフィックドライバまわりに問題がある場合、FirefoxやFlash Playerではグラフィックチップと直接やりとりする、ハードウェアアクセラレーションを設定から切ることができるようになっていますので、これを無効にすると改善するかもしれません。ただし、この場合は実行時のパフォーマンスが低下したり、CPUの使用率が上がることになることに注意してください。

ちなみに、グラフィックチップのドライバというのは、ゲームや動画プレーヤー等の、特定のアプリのバグにドライバ側で対応を入れたりすることが多々あります。このため、最新版のドライバが誰にとっても最良の選択肢とは限らないという悩ましい話があります。

パフォーマンス改善には重要なアップデートですので、基本的にはグラフィックドライバを毎回アップデートし、自分に都合の悪い、ハズレバージョンだった場合にのみ、ドライバを古いバージョンに戻す、というやり方をとることをお勧めします。

2012年11月24日

アドオンとは上手に付き合っていきましょう 初回投稿日時: 2012年11月24日18時53分22秒
最終更新日時: 2012年12月05日16時42分46秒
カテゴリ: Firefox Mozilla17
固定リンク: id=2012112400
リンク元: 15件
SNS: (list)

Firefox 17が先週リリースされましたが、タブ周りに深く食い込んだアドオンのいくつかの開発がこのリリースに残念ながら間に合わず、不便を感じている方も多々居らっしゃるようですね。今回、特に話題になっているのは、Tab Mix Plusと、Tab Utilitiesの二つです。この二つに共通する、二つの特徴があります。そして、この二つの特徴の組み合わせが技術的には割と最悪だったりします。

特徴1: 複数の機能を持ち、内部構造が複雑な「統合型」アドオン

一つ目の特徴は、どちらも多くの機能を持ち、サイズそのものが大きく、複雑な、「統合型」のアドオンだという点です。

このようなアドオンと逆の特徴を持った物は、「単機能型」と呼ばれる、シンプルでコンパクトなアドオンです。文字通り、ひとつ、もしくは2〜3個の似た機能の追加のみを行うアドオンです。

タブ関連の単機能型アドオンを、名前から推測して検索してみると、以下のようなものが見つかります。

実際に中身を確認した訳ではありませんが、実装している機能からすると、どのアドオンも内部はシンプルであることが想像できます。

このような、単機能型アドオンの場合、以下のようなメリットがあります。

バグが発生しにくい
アドオンそのものが単純になりますので、開発者からするとソースコード全体を簡単に見通せます。そのため、アドオンにバグが混入しにくくなります。不具合なく動作する、クラッシュの原因になりにくい、メモリリークが発生しにくい、アドオンが完成すると考えれば、これは実に良いことです。
互換性に問題がある機能のみが無効化される
たとえば、統合型アドオンが20個の機能を持っていたとします。すると、そのうちの一つでも、新しいFirefoxと互換性が無くなると、このアドオンは無効化され、20個の機能全てが利用不能になります。もし、その原因となった一つの機能があなたの利用している機能ではなかった場合、巻き込まれただけ、という話になってしまいます。もし、強引に互換性情報を無視して動かすと、タブが開かないといったようなバグが発生したりします。ですが、単機能型アドオンであれば、互換性に問題が出たものだけが無効化されます、互換性に問題が無いアドオンはそのまま継続して使うことができます
メンテナンスが容易なのでリリースに間に合う可能性が高い
アドオンの内部がシンプルということは、Firefox側の変更で互換性が無くなった場合にその原因をいち早く見つけることができます。それに加え、そのアドオンを修正しても、それが提供している少数の機能だけをテストすればリリースできますので、非常に迅速にリリースにこぎ着けることができるでしょう。
開発者がメンテナンスできなくなっても、他の人が作業を引き継ぎやすい
アドオン開発者の大半はアドオンの開発やメンテナンスが本業ではありません。このため、本業が忙しかったり、私生活の変化により、いつかはメンテナンスを続けることができなくなるでしょう。このような場合に統合型の複雑なアドオンのメンテナンスを引き継ぐには相当な覚悟と技術が必要になります。ですが、シンプルな単機能型であれば、それができる人の数が格段に増えます。つまり、メンテナンスが別の人へと引き継がれる確率が比較的高くなり、アドオンの寿命が長くなることが期待できます。

単機能型のアドオンの難点は、やはり、探すのが面倒ということに尽きるでしょう。しかし、今後もアップデートの際にアドオンが無効化され、多くの機能が一度に無効化されてしまって不便な体験をするぐらいでしたら、この機会にシンプルなアドオンを必要なもののみ、インストールする、スマートな形にしてみてはどうでしょうか?

上記のアドオンの名前を見て分かるように、単機能型アドオンは、その名前が、そのまま機能を言い表していることが多いので、意外と検索で見つけやすいことが多いです。

特徴2: 元々あるユーザインタフェースと密着している

もう一つの共通する特徴は、アドオンがFirefoxのユーザインターフェースと、かなり深い部分に密着・融合してユーザインターフェースの内部構造や、見た目を変えてしまっている点です。

どのようなアドオンであっても、Firefoxから情報を得る場合や、Firefoxの元々ある機能を呼び出す場合には、そのインターフェース(APIと呼ばれます)が変更された場合には互換性を失います。

ですが、ユーザインターフェースと密着しているようなアドオンの場合、Firefoxが機能追加やバグ修正等で、ユーザインターフェースの形や構造を少しでも変更した場合にも互換性が無くなってしまいます。例えば、タブの上にボタンや、進捗メーターを配置するアドオンを作った場合、Firefoxがバージョンアップ時に、このタブの内部構造を少しでも変更していると、アドオン側での修正が必要になってしまいます。

これとは対照的に、コンテキストメニューに項目を追加して、それを選択された場合にのみ動作するアドオンや、ツールバーにボタンを追加して、そのボタンをクリックされた場合にのみ動作するアドオンの様に、元々あるFirefoxのユーザインターフェースを変更せずに動作するアドオンというのは、内部APIの仕様変更以外では修正が必要になることはほとんどありませんので、修正が必要な回数がより少なくて済みます。

このようなことを踏まえて、アドバイスさせて頂くと、シンプルな単機能アドオンで、しかも、ユーザインターフェース自体を変更してしまわないものを必要な数だけ入れておくと、意外と1年以上、どのアドオンも問題が出ることなく動き続けたりします。

徹底的にその時点で理想的なブラウザをアドオンを大量に使って実現するのもひとつの手ですが、無理のない範囲で、そこそこ自分に適した環境を作り上げることができれば、トラブルの無い生活をおくれます。

その時点で実現できる自分にとっての理想的なブラウザを徹底的に求めるというのは、確かにFirefox最大の利点であり、これも楽しみの一つではあります。ですが、理想を追求した環境を維持するコストは実は非常に大きなものであるということも理解した上で、多少無理のあることをしているアドオンを採用するかどうするかを判断していただきたいと思います。

2012年11月25日

ひとことだけ 初回投稿日時: 2012年11月25日14時41分52秒
最終更新日時: 2012年11月25日14時49分00秒
カテゴリ: Firefox 雑談
固定リンク: id=2012112500
リンク元: 0件
SNS: (list)

なんで、we disable the 64-bit Windows nightly buildsとか、we should consider disabling the win64 builders completely開発中止と訳されるの? 英語力やばすぎない?

少なくとも、今回の一件を広めてる人は読売新聞のiPS細胞の検証がいい加減で誤報だった件を叩くことはできないですよね。

2012年11月30日

Bug-org 808287 Intermittent test_bug386782.html | Editing failed. - got <p>contentEditabEDITED le</p>, expected EDITED <br><p>contentEditable</p> (and 3 more) 初回投稿日時: 2012年11月30日23時55分02秒
カテゴリ: Android Mozilla Core Mozilla19 バグ修正
固定リンク: id=2012113000
リンク元: 0件
SNS: (list)

Bug-org 805766の修正により、test_bug386782.htmlのテストがAndroidでのみランダムに発生するようになったというバグです。

このテストは、開いたウインドウでdesignModeのテストを行い、そのウインドウを一端閉じ、再度新しく開いたウインドウでcontentEditableのテストを行うというものです。

原因が分かるキッカケとなったのは、誤って入力されている位置、これが、designModeのテストの最後にキャレットがあった位置と同じということを発見したことでした。designModeのテスト後のキャレットの位置を一文字ずらした状態でテストすると、綺麗に一文字分ずれて、同様の失敗が発生したことから確認がとれました。

Android版のFirefoxは、キャレットが移動した際に、移動した位置をIMEに通知します。ただし、GeckoのGUIスレッドからではなく、AndroidのUIスレッドから通知しています。このため、designModeエディタで最後に発生したキャレット移動が、contentEditableのテストが始まってからIMEに通知され、IMEがキャレット位置で良いという反応がGeckoに戻された際に、Android版のwidgetが新しい方のウインドウ上でその位置に設定しなおす、ということが発生していたわけです。

今までは、Bug-org 805766が修正されるまでは、designModeエディタでこのIMEの通知がそもそも動いていなかったため、隠れていたバグだったわけです。

Android側の修正は私には無理だったので、Android widgetの担当者に任せ、私はnsTextStateManager側が非同期でwidgetにキャレット位置変更等を通知する際に、送信すべきwidgetかどうかを確認してから送るように修正しています。

Bug-org 814303 [Mac] Zoom-in/out is not available with mouse wheel since control+wheel is reserved by OS and the default action is always used when two or more modifiers are active 初回投稿日時: 2012年11月30日23時56分39秒
最終更新日時: 2012年12月01日00時01分35秒
カテゴリ: Events Firefox Mac Mozilla Core Mozilla20 バグ修正
固定リンク: id=2012113001
リンク元: 0件
SNS: (list)

Bug-org 719320の修正によるregressionです。Macでは、標準の設定では、control+ホイールで、画面全体をズームするようになっています。この際、Geckoにはホイールイベントが通知されませんので、Firefoxのデフォルト設定では、ホイールを使ったズームができなくなっていました。

Macの他のブラウザの挙動を調べたところ、Operaがoption+ホイールでズームした以外、ホイールでのズームが共通の操作として定着している感じはありませんでした。ですので、他のプラットフォームのGeckoと同じように、最も主となるショートカットキー用のモディファイアキーである、commandとホイールの組み合わせでズームするようにデフォルト設定を変更しました。

なお、control+ホイールのOS側の機能を設定から無効化した場合にも、今までと同じように操作出来るように、controlキーの設定はそのままにしてあります。