この記事は “Servo Nightly Builds Available” の抄訳です。
新しいレンダリングエンジンである Servo の Nightly 版が公開されました。 この Nightly 版には Servo エンジンに加えて、それを操作するための HTML 製 UI が付属しています。Servo の実験と貢献に多くの人が関わっていただきたいと考えています。そのため Mac OS と Linux (64 bit）向けにパッケージの提供を始め、Windows と Android 向けのものも近々の提供を予定しています。

バイナリパッケージのダウンロードと、インストール方法は https://download.servo.org/ をご覧ください。

Servo を初めて起動すると、Servo のレンダリングがうまく働くサイトが一覧できるタブページが表示されます。同じものがこちらからご覧になれます。ぜひ他のブラウザと描画性能を比較してみてください。

参加しよう！

Servo はコミュニティプロジェクトで、ソースコードはもちろん、議論も GitHub で行われています。初心者向けのバグリストも用意しました。Rust, JS, Python、そしてシェルスクリプトでかけるものも、その中にはあります。ウェブ開発をされている方なら、Servo を育てるのに大きく貢献できます。ぜひ参加してください。

また問題を発見した場合は、issue の追加をよろしくお願いいたします。

原文: 10 Years of Firefox and Innovation for the Web Platform

今日、私たちは、Firefox 誕生10周年を祝い、誕生プレゼントとして、開発者に試していただく、わくわくするようなたくさんの新しい技術をご用意しました。

これまでの10年間、Mozilla はただ単に Firefox を開発してきたのではなく、私たちは Firefox や他のブラウザを通じて今日利用者が体験する Web の多くを作るお手伝いをしてまいりました。

Mozilla プロジェクトはマイクロソフトからの Web への制御に対して立ち向かうために立ち上げられました。以前はマイクロソフト社の Internet Explorer 6 がブラウザの 98% を占め、マイクロソフト社が Web の革新をほぼ完全に制御していました。Mozilla は、Web のような私たちの生活に重要でかつ中心的なエコシステムが一社によって不均等に制御される事がなぜ問題なのかという主張を単に発信(telling)してきませんでした。
その代わりに、私たちは、より良く、よりパワフルな Web やブラウザ、いわゆる Firefox を作るために努力してまいりました。Firefox が Web に導いた競争や革新は、過去10年の間、 Web の開示性やブラウザの展望を劇的に変えました。

今日、マイクロソフト社の様に、1社のブラウザベンダーが市場を占める会社はありません。ユーザの皆さんはマイクロソフト社、グーグル社、アップル社またはもちろん Mozilla から、ブラウザを選ぶ事ができます。このブラウザ界の競合は、10 年にわたる私たちの使命に対する明確な成功の証です。

Mozilla では、消費者向けのブラウザを開発するだけではなく、Web そのものも開発しています。独占的なエコシステムを打開するために、Web はネイティブプラットフォームの機能やパフォーマンスに適合させるか、またはそれを越える必要があります。過去10年間、私たちは、多くの新しい Web 技術を開拓し、それらを標準化することに貢献してきました。ゲーム

ゲームは多くの面でエンターテイメントの重要な形成をしています。過去には、ブラウザゲームはプラグインに頼らざるを得ず、開発者が Web に幅広くコンテンツを提供することができませんでした。Mozilla は、現代のブラウザではおなじみの WebGL を含む、ゲームに夢中になれるプラットフォームとして Web を開錠する数多くの新しい技術を開拓してまいりました。さらに、私たちは、ゲームエンジン用にネイティブに近いパフォーマンスを可能にする新たな JavaScript の拡張 asm.js を開発いたしました。

パフォーマンスの改善

Mozilla の JavaScript エンジンが、ほぼ全ての分野における JavaScript のパフォーマンスで市場をリードし、ブラウザ上で最高クラスのゲーム体験を提供できている事をお伝えでき誇りに思います。私たちは、Firefox 自体から独立したプロセスでコンテンツを起動させることで、Firefox ユーザーの皆さんに更なるパフォーマンスや安全面での恩恵をご提供できるように、Nightly ビルドで E10s を使った実験をしています。最後に、パフォーマンス面において、日々の仕事に更なるパワーを必要とする方たちのために 64 ビット Windows ビルドをご紹介します。

オーディオとビデオの向上

Web上のオーディオやビデオにおいても Mozilla のサポートにより、飛躍的な前進を遂げています。私たちはオーディオやビデオ、またはデータチャンネル経由でのリアルタイムなコミュニケーションのための新しい WebAPI である WebRTC を先導して提唱する一グループです。私たちの長期にわたるパートナーである Telefonica と協力してソフトウェアのダウンロードやアカウント作成が不要な、リアルタイムでのコミュニケーションを可能にする WebRTC ベースのオーディオ、ビデオチャット機能である Firefox Hello を近日中に Firefox に追加します。

Web の構築

私たちのボランティアコミュニティは Firefox と Web の向上において大きな役割を果たし続けています。ブラジルのコミュニティのアンドレ・ナタルは Firefox と Firefox OS の音声認識機能に貢献しています。これにより、ユーザーのみなさんは自身の声により、デスクトップブラウザおよび Firefox OS 端末とやりとりできるようになります。この Web Speech API は、現在私たちのレンダリングエンジンである Gecko に追加されています。

もしあなたが Web 開発者で、上記に記した技術を是非試してみたいという事であれば、私たちは10周年を記念して特別な物をご用意しました。私たちが Web を開発する間、Web 上で可能なコンテンツや体験を開発するのは開発者の皆さんです。ボランティアの皆さんの努力と、また Web 開発者コミュニティへの私たちの継続的な関与の功労により、私たちは開発者の方がデフォルトで有効であってほしいと願う多くの機能が付いた Web 開発者の方向け専用の Firefox Developer Edition を公開いたします。この開発者エディションは開発ワークフローを合理化し、モバイルやデスクトップ等、様々なプラットフォームにおいて、Web 全体の開発プロセスを簡素化する新しい機能が加わりました。

将来待ち受けていること

Mozilla は 10 年前にマイクロソフト社によるプロプライエタリな支配から Web を自由にするための長旅を始め、今日、私たちはその目的を大筋達成しました。Web を自由にするための次なる大きな課題の局面は、新たに発生した iOS と Android が複占するモバイルです。10年前、私たちが Firefox でマイクロソフト社に挑戦したように、私たちは Web 向けに開発され、また 1 社による規制がなされない新しいスマートフォン OS、Firefox OS を作る事でグーグル社やアップル社のモバイル界の締め付けを取り払おうとしています。昨年最初にローンチしてから Firefox OS 端末は直近でローンチしたインドを含め現在世界中 24 ヶ国に広がっています。もしあなたが Firefox OS 開発者端末をお使いであれば、今日公開する新しい Firefox OS 2.0 の開発者向けビルドをお試しください。

私たちは、Servo と Rust を通じて Web の根本的な技術を向上させています。Servo は、並行処理を高度サポートし、安全性と信頼性を改善した次世代 Web の新しいレンダリングエンジンです。私たちが開発し、コミュニティの強力な支持をより広げている、新しいシステムプログラム言語 Rust のおかげで、私たちはこれを達成する事が出来ました。Servo 並びに Rust の構成要素は、近い将来 Gecko に入ってくる事になるでしょう。

将来の展望として、私たちは、Web における次なる開拓である仮想現実（バーチャル・リアリティ）を探し始めています。私たちは、Web 上で仮想現実の新たな可能性を開拓しており、技術デモのプラットフォームとして、またどのようにして仮想現実体験をWebに持ってくるかという事を学ぶための場所として mozvr.comを開始します。

2014 年 8 月 6 日 (日本時間) の Windows 版 Nightly から、Windows の新しいテキスト入力 API である TSF (Text Services Framework) のサポートがデフォルト設定で有効化されます。

TSF は非常に強力で、単に、従来までの IMM (Input Method Manager) を置き換えだけではなく、タブレット PC での手書き入力や、音声入力も、IME と同様に扱える API 群です。そのような、TSF に対応したテキスト入力を行うソフトウェアは、TIP (Text Input Processor) と呼ばれます。現在、IME と同様にキーボードからの入力を行う日本語 TIP は、Windows XP 以降で標準添付されている MS-IME 、ATOK 2011 以降 (ただし、Windows Vista 以降にインストールしている場合のみ) 、Google 日本語入力 (ただし、Windows 8 以降にインストールしている場合のみ) などがあります。ちなみに、TSF 非対応の古い IMM 向け IME の Japanist 2003 等は、引き続き、Gecko の IMM イベントハンドラにフォールバックされ、変わらず利用可能ですので、これらをご利用中の方も安心してください。

TSF にネイティブ対応し、デフォルトで有効化されているブラウザは、現在のところ、Internet Explorer 11 以降と、Google Chrome のメトロアプリ版のみです。前者はオープンソースなソフトウェアではないため、詳細は不明ですが、後者は、Transitory コンテキストとして実装している模様ですので、もしかすると、Nightly が初の TSF フルサポートの Web ブラウザになるのかもしれません。

TSF は前述のように非常に強力な API で、TIP 側からはフォーカスをもったエディタの内容に自由に、任意のタイミングでアクセスすることができます。このため、TSF 対応アプリと、TIP の組み合わせによっては、その動作や、実行時のパフォーマンスに問題が発生する可能性があります。 Gecko の TSF の初期実装は 2009 年 2 月に Nightly に取り込まれていますが、その当時は、Windows XP の未成熟な TSF や TIP そして、Gecko 側の実装レベルではまともに動作せず、ここから 5 年間、地道な改良を続けて、ほとんどの発見されている重大なバグの修正が完了したことで、一般のテスタの方々にもテストを行って頂くことができるようになりました。つまり、もし、なんらかの新しいバグを発見された場合、おそらくそれは、未発見のバグですので、Bugzilla へ Core 、Widget: Win32 のバグとして報告してください。その際に、バグのタイトルの先頭に、”[TSF] ” を付けておいてもらえると、他のバグとの区別が付きやすいので助かります。また、既に見つかっているバグかどうかを検索する際には、同様に、“[TSF]” がタイトルに含まれているバグを探せば、発見済みの全てのバグを見つけることができます。

もし、何らかの重大なバグがあり、Nightly でのテストが困難になるようでしたら、about:config から、intl.tsf.enable を false に変更し、再起動してください。これによって、従来の IMM サポートのみの状態に戻すことができます。ですので、TSF モード固有のバグであるかどうか確認する際にも、この設定を利用して、テストしてみてください。

ただし、前述のように、Windows XP では TSF や、標準で搭載されている TIP の MS-IME に問題が多数存在し、現在も未解決のため、今回も、また、これ以降もおそらく、デフォルト設定で、TSF モードが有効になることはありません。しかし、一部、タブレット PC 等で、需要がある可能性があるため、intl.tsf.force_enable を true にすることで、Windows XP や、Windows Server 2003 でも TSF モードを強制的に有効にすることは可能です。

一般的な日本人のユーザから見た、TSF モードでの分かりやすい変更点は、未確定文字列の表示でしょう。 IMM では、未確定文字列をアプリケーション自身で描画する場合には、その IME 固有の未確定文字列の表示スタイルを取得を行うことが、現実的には不可能でした。ですが、TSF では、このあたりの API も提供され、各 TIP の設定通りの未確定文字列が表示されるようになります。例えば、MS-IME の変換前の未確定文字列の下線は、波線で表示され、ATOK の変換中の文節の背景色は水色で表示され、Google 日本語入力の変換前のみ確定文字列は、点線で表示されます。これにより、今まで以上に自然なユーザ体験を提供することが可能になります。

それでは、Aurora や、リリース版でも TSF モードを有効にできるように、テストと、バグの報告をよろしくお願いします。

4 月 27 日、28 日の 2 日間にわたって行った Mozilla Hackathon 2013 が無事終了しました。
今回は、乃木坂の Mozilla Japan 新オフィスに合計 28 名の参加者が集まり、
それぞれに持ち寄った作業を行いました。

今回も 10 年以上 Mozilla で活躍されているベテランコントリビューターや有名なアドオンの開発者から
Mozilla のイベントに初めて参加される方まで、様々な方が参加されました。

初日は 13 時からスタート。
参加者は、翻訳や製品ローカライズを行うチーム、アドオンや Firefox OS 用アプリの開発を行うチーム、
そして Firefox それ自身の実装や改良を含むプラットフォーム開発を行うチーム、の3グループに分かれ、
自己紹介タイムをはさみつつ、18時過ぎまで作業を行いました。
その後、参加者のほぼ全員による懇親会が行われました。

2日目の作業開始時刻は午前 9 時。
精力的に作業を行い、15 時からの成果発表を迎えました。
各人・各チームがそれぞれの作業内容とその成果を発表し、2日間にわたるイベントを締めくくりました。

参加された方々は、真剣に作業される一方、他の方々との交流も大切にされていました。
今後もこのようなオフラインでの交流の機会となるようなイベントを開催できればと思います。
今回参加されなかった方も、機会がありましたらぜひご参加ください！

Firefox 16の頃から、戻るボタンや、進むボタン、セッション復元時等に、ページ全体がFile not foundというエラーになってしまったり、CSSファイルや、Javascriptファイルの読み込みにだけ失敗して、レイアウトが崩れてしまったり、Webアプリがうまく動かなかったり、という、非常に不快なバグがあります。今回は2012年11月末現在での状況を紹介しておこうと思います。

まず、当初のこのバグの発生した原因というのは未だに分かっていません。最初にキャッシュファイル生成時に、書き込みを終えた時に正しくファイルが閉じられていないことがあるケースが発見され、これはBug 771832でFirefox 17上で修正されました。

ですが、それだけではまだ再現する、ということで、壊れたキャッシュ自体を作ってしまうバグを修正するために、Bug 808532が登録されました。また、壊れたキャッシュを読み込んでしまった場合に、エラーとして断念せずに、ネットワークから再取得するように修正するため、Bug 812483が登録されました。

後者のパッチは、ほぼ完成していましたが、これはキャッシュが駄目になるバグが今後も発生した場合に気付かないのは良くないということで、投入するとしてもNightly以外にしようという話になっていました。ですが、そんな中、9月6日にFirefox 18上で修正された、Bug 405407が原因ではないかという話が出てきて、11月20日にNightlyから、11月26日にBetaから、11月28日にAuroraからバックアウトされました。このおかげか、私の手元ではここ最近、Nightlyでこのバグが発生しないようになっています。

もし、Firefox 17で、このバグに困っている方が居る場合は、Firefox 18 ベータ版への一時的な移行を促すと良いかも知れません。ベータ版への移行が難しい場合は、今まで通り、キャッシュを消してもらって、一時的に症状を押さえ込むしかありません。

ちなみに、キャッシュファイルの閉じ忘れ箇所が新たに指摘されているので、それでもまだ発生する可能性はありますが、ここ最近のNightlyを使っている限りは、よほどシチュエーションが限定されるのではないかと感じます。

どちらにしろ、長引いたこのバグも、ようやく収拾の目処がたってきたという感じですね。

twitter.comで発生している、長いツイートを入力すると、入力した文字が見えなくなってしまう、という問題ですが、最近、よく苦情を目にするようになっているので、ここに解説記事を書いておきます。Army of Awesomeでこの問題を見かけた方は、その、困ってるユーザに、この記事を教えてあげてください。

とりあえず、今、この問題を回避するにはどうすれば良いのか、という質問に答えるには非常に難しいものがあります。

最も簡単なのは、Firefoxのバグを利用することです。今回の一件で、入力欄の最後の行にキャレット(テキスト入力中に点滅しているインジケータ)がある時に、下矢印キーを押すと、一番下までスクロールすることが分かりました。これはバグなのですが、現在、ユーザが利用できる一番簡単なスクロール方法です。ですが、自由なスクロールはできませんので、最低限の回避策、というレベルのものです。

最も自然な解決策は、ユーザスタイルシートを記述することです。しかし、この解決策を行うには、ユーザが、ユーザスタイルシートを記述する知識を必要としますので、残念ながら、簡単ではありません。ユーザスタイルシートについて知識が無い方は、上記のバグを利用した操作で利用するしかありません。ユーザスタイルシートで解決したい方は、以下の原因に関する説明もあわせて読んでください。

何が、問題なのかを理解するには、CSSのoverflow: hidden;についての知識が必要になります。twitter.comのツイートの入力欄には、このスタイルが指定されており、CSS仕様では、ブラウザはユーザにスクロールするUIを提供してはいけないと定められています。このため、入力内容がはみ出してもユーザの操作を基に、スクロールしてはいけません。Javascriptからのスクロール位置の指定でのみスクロールできるのが正しいのです。これは、Webデザイナへ提供されたひとつのデザイン手法なのです。つまり、一言で言うなら、twitter.comのサイト側の設計に問題があります。

では、なぜ、今までは問題が無かったのか、というと、twitter.comでは、入力内容が入力欄からはみ出す場合に、入力欄のサイズを大きくし、全ての内容がスクロール無しで表示できるようになっていました。ですが、twitter.comはサイズ変更を行わないように変更され、入力内容がはみ出してしまうケースが出てきました。

では、なぜ、他のブラウザでは問題が無いのか、というと、他のブラウザでは、入力欄にoverflow: hidden;が指定されていても、キャレットが常に表示されるように、スクロールするためです。調査したところ、Internet Explorer、Safari、Google Chrome、Operaのいずれにおいても、キャレットの移動によるスクロールが可能でした。これでは、Webサイトの動作をFirefoxではテストされていない場合に、Firefoxのユーザに今回のような深刻な影響を与えてしまいます。このため、Firefox 18では、他のブラウザと同様に、内容が編集可能な場合にのみ、キャレットが常に表示されるようにスクロールするよう、修正されました。ですが、Firefox 16はもちろん、Firefox 17でも修正されないことが決定しました。これは、修正による副作用のリスクを考慮しての決断です。

現在、Mozillaでは、ツイッター社にサイト側でなんらかの対応がとれないか、コンタクトを試みています。ツイッター社がこの問題に、サイト側で対応してくれれば、一番良い解決策を、Firefox 18までに提供することができるでしょう。

modbuilders.jpに投稿しましたので、リンク貼っておきます。

VS Express 2012 for Desktopリリース

http://modbuilders.jp/vc11e-released/

今回のExpressは64bit版ビルドできます。

以前、IMMのハンドリングコードのログをとる方法について解説しましたが、Mozilla 18からは、TSFのハンドリングコードのログもとれるようになりますので、ここでは、それについて解説します。

TSFは今現在も実装されてはいますが、デフォルト設定では無効になっています。これは、互換性の問題やパフォーマンスの問題が未だに解決できていないためです。TSFを有効にするには、about:configで、intl.enable_tsf_supportをtrueに変更し、Firefox等を再起動します。

TSFのログを取る際は、Firefox等を起動する前に、環境変数を二つ、設定する必要があります。まずはファイルのパスを、NSPR_LOG_FILEに指定します。Windowsのパスの形式で問題ありません。そして、モジュール指定を、NSPR_LOG_MODULESに行いますが、現在、三つのモードが用意されています。ひとつめは、nsTextStoreWidgets:1です。この場合、TSFとの通信で、どのインターフェースメソッドが呼ばれたのか、そしてどのような値が返されたのかが記録されます。また、nsTextStoreクラスの生成や破棄等も記録されます。二つ目は、nsTextStoreWidgets:2です。この場合、ひとつめのログに加えて、何らかのエラーが発生した場合、そのエラーも記録されます。最後はデバッグ用の、nsTextStoreWidgets:4です。これは、上記二つのログに加えて、全ての内部処理のログをとります。

もし、あなたが、TSFを勉強したい場合や、TIPの開発者の場合は、nsTextStoreWidgets:1がお勧めです。

もし、Firefox等の動作に不審感を感じて、エラーログを取りたいのであれば、nsTextStoreWidgets:2がお勧めです。エラーに関しては、全ての内部処理のものが記録されるからです。

最後のデバッグ用のnsTextStoreWidgets:4は、本当に詳細なログが記録されるので、バグを実際に修正しようとしている場合や、バグ報告に利用しようとする場合以外には好ましくありません。

もし、IMMの動作ログも同時に記録したい場合は、nsTextStoreWidgets:2,nsIMM32HandlerWidgets:1としてください。この場合、同じファイルに両方のログが記録されます。

最後にひとつ、注意すべきことがあります。現在、未確定文字列がある場合、高い頻度で、TSFにレイアウトが変更された可能性があることを通知しています。これは、スクロール等によって、変換候補ウインドウの位置等がずれてしまわないようにするためですが、これにより、本来読みたいログとは関係の無いログが大量に保存されます。これを回避する場合は、about:configで、intl.tsf.on_layout_change_intervalの数値をとことん大きな値に変更してください。数値の単位はミリ秒です。そうすれば、シンプルなログを取得することができます。

Firefox OS の開発環境構築手順をまとめました。

http://masap.sakura.ne.jp/firefoxos/build.html

すっかりおそくなりました、その他編です。

hATrayflood

Bug 778393の対応を行いました。

himorin

Bugzillaの最新版がリリースされたこともあり、日本語版の作業を行いました。

m_kato (私)

Androidの入力周りを直そうと思っていくつか (Bug 771201, Bug 778389, などなど) を作業しました。現在の地点でいくつかの修正はNightlyで実装済みです。

あと現在のところOperaのみで実装されているCSS Image Level 3のobject-fitプロパティのテスト実装を行いました。

masayuki

CSS Text Level 3のtext-underline-positionプロパティのテスト実装を行いました。

saneyuki

以下のいくつかのバグ対応をしました。

• bug 774692- “Implement “visit site” in aboutCertError.xhtml for desktop”
• bug 778392- Use handleEvent() for BrowserOnClick” (パッチ作成終了)
• bug 764572- “add “Open URL” option to net panel items’ context menu” (パッチ作成終了)
• bug 723951 – “Popup notification does not continue when the tab move to other window” (work in progress. I may not be able to fix this bug…)

taken

SVGのfocusable属性の実装を行いました (bug 409404)。

出来たこと

• 手動テストケースの作成
• focusable属性でフォーカスの可否を決定
• イベントリスナー（DOMFocusIn, DOMFocusOut, DOMActivate）の有無でフォーカスの可否を決定

出来なかったこと

• 自動テストの作成（mochitest？）
• アニメーション（DOMFocusIn, DOMFocusOut, DOMActivate）の有無でフォーカスの可否を決定
• イベント属性（onfocusin, onfocusout, onactivate）の有無でフォーカスの可否を決定（https://bugzilla.mozilla.org/show_bug.cgi?id=371728？）
• フォーカスリングの描画（bug 369507）

wuitap

Boot to Geckoのホーム画面をカスタマイズしてWindows Phoneで使われているメトロUIチックに変更してみました。