このドキュメントは Firefox 17 のサイト互換性に関わる修正のまとめ に移動しました。もし一覧に漏れや間違いがあるときは、下のコメント欄でお知らせいただければ幸いです。

Firefox 16 の正式版が今日 10/9 深夜にリリースされる予定です。可能な限り互換性を維持するよう開発されましたが、他のブラウザとの相互運用性や最新 Web 標準仕様への準拠のため、後方互換性に関わる修正も含まれます。そのような修正点をまとめましたので、動作検証時などにご参照ください。

ここでは後方互換性に影響し得る修正のみ解説します。その他の新機能や変更点については次のページをご覧ください。

• Firefox 16 ベータ版リリースノート
• Firefox 16 for developers (MDN)
• Aurora 16 is out — Unprefixing time ! (Mozilla Hacks)

この一覧に漏れや間違いがあるときはコメント欄でお知らせください。

原文: Using window.matchMedia to do media queries in JavaScript (on June 5, 2012 by Robert Nyman)

Web サイトを構築する人々にとって、レスポンシブ Web デザイン で、可能な限り多くのユーザがコンテンツを利用できるようにすることが自然なアプローチになってきました。これには CSS メディアクエリ が使われますが、JavaScript でも同じことができます。

window.matchMedia の紹介

JavaScript でメディアクエリを利用するには、window.matchMedia を使います。基本的には CSS で行うのと同じことを、JavaScript コールで行います:

var widthQuery = window.matchMedia("(min-width: 600px)");

このクエリは、MediaQueryList オブジェクトを返します。このオブジェクト上では、次のことができます:

matches

クエリがマッチするかどうかの真偽値。

media

シリアライズされたメディアクエリのリスト。

addListener

イベントリスナをメディアクエリに追加する。値のポーリングなどよりも優先される。

removeListener

イベントリスナをメディアクエリから削除する。

メディアクエリがマッチするかどうか簡単に調べるには、matches プロパティを使います:

var widthMatch = window.matchMedia("(min-height: 500px)").matches;

リスナを追加するのはとても簡単です:

function getOrientationValue (mediaQueryList) {
    console.log(mediaQueryList.matches);
}
 
portraitOrientationCheck = window.matchMedia("(orientation: portrait)");
portraitOrientationCheck.addListener(getOrientationValue);

デモとソースコード

window.matchMedia のデモ で、いくつかのクエリの動作を確かめられます。ウィンドウをサイズ変更して値がどのように変わるか見てみてください。

このデモの完全な JavaScript コードは、GitHub にも置いてあります:

(function () {
    var matchMediaSupported = document.querySelector("#matchmedia-supported"),
        width600 = document.querySelector("#width-600"),
        height500 = document.querySelector("#height-500"),
        portraitOrientation = document.querySelector("#portrait-orientation"),
        width600Check,
        height500Check,
        portraitOrientationCheck;
 
    if (window.matchMedia) {
        matchMediaSupported.innerHTML = "supported";
 
        // Establishing media check
        width600Check = window.matchMedia("(min-width: 600px)"),
        height500Check = window.matchMedia("(min-height: 500px)"),
        portraitOrientationCheck = window.matchMedia("(orientation: portrait)");
 
        // Add listeners for detecting changes
        width600Check.addListener(setWidthValue);
        height500Check.addListener(setHeightValue);
        portraitOrientationCheck.addListener(setOrientationValue);
    }
 
    function setWidthValue (mediaQueryList) {
        width600.innerHTML = mediaQueryList.media;
    }
 
    function setHeightValue (mediaQueryList) {
        height500.innerHTML = mediaQueryList.matches;
    }
 
    function setOrientationValue (mediaQueryList) {
        portraitOrientation.innerHTML = mediaQueryList.matches;
    }
 
    // Setting initial values at load
    function setValues () {
        width600.innerHTML = width600Check.matches;
        height500.innerHTML = height500Check.matches;
        portraitOrientation.innerHTML = portraitOrientationCheck.matches;
    }
 
    window.addEventListener("DOMContentLoaded", setValues, false);
})();

Web ブラウザのサポート

この記事の執筆時点で、window.matchMedia は次のブラウザに実装されています:

• Firefox 6 以降。
• Google Chrome 9 以降。
• Safari 5.1+。注記: addListener はサポートしていません。
• モバイル版 Firefox
• Android 版の Google Chrome ベータ。注記: addListener はサポートしていません。
• iOS 版の Safari 5。注記: addListener はサポートしていません。
• Android ストックブラウザ。注記: addListener はサポートしていません。

Internet Explorer 10 でのサポートも計画されています。

古い、サポートしていない Web ブラウザでは、matchMedia() polyfill を試してみてください。ただし、addListener はサポートしていません。

Mozilla Hacks よりも先に解説記事を書けました。

概要

10日ほど前に 772434 – Blob support for Zip file contents のパッチが mozilla-central に投入され、DOM File API 経由で取得した zip 形式のアーカイブファイルの取り扱いを行うための API、Archive API が試験的に実装されました。このAPI は最新の Firefox Nightly 17 で試すことができ、このまま何事もなければ 年末にリリースが予定されている Firefox 17 にも載ると予測されます。

今回の Archive API の試験実装は、 今年 7月 17日に Andrea Marchesini によってwhatwg の ML にて提案されたもの（ [whatwg] Archive API – proposal ）を実装したものになります。

API

今回の試験実装によって、Gecko に以下のインターフェースが実装されました。

• mozilla-central: dom/file/nsIDOMArchiveReader.idl
• mozilla-central: dom/file/nsIDOMArchiveRequest.idl

使い方の流れとしては以下のようになります

1. 取得した zip ファイルの Blob または File オブジェクトを ArchiveReader コンストラクタに渡してオブジェクトを生成
2. 生成した ArchiveReader オブジェクトのメソッドを呼び出して ArchiveRequest オブジェクトを取得
3. 取得した ArchiveRequest に、操作の完了時に呼び出すイベントハンドラを設定

コード的には以下のようになります。

// ArchiveReader のインスタンスを生成
var reader = new ArchiveReader(file);

// 格納されたファイル名一覧の取得
var requestFileList = reader.getFilenames();
requestFileList.onsuccess = function (event) {
  var request = event.target; // this を使っても良い
  var fileList = request.result; // 配列でファイル名の一覧が返ってくる
  console.log(fileList);
}; 

// 格納されたファイルの取得
var requestFile = reader.getFile("hoge/sample.txt"); // zipファイル内でのパスを指定
requestFile.onsuccess = function (event) {
  var request = event.target;
  var file = request.result; // File オブジェクトが返ってくる
  console.log("file name" + file.name);
  console.log("file type" + file.type);
  console.log("file size" + file.size);
};

サンプル

筆者が作成した zip ビューアのサンプルコードへのリンクを以下に記します。

Archive API sample for Firefox Nightly 17 — Gist

テキストファイルのエンコード判別が未実装であったりと、色々と雑な作りとなっています（申し訳ありません）。実行の際には注意をお願いします。

現在の実装における注意点

現在の実装は試験的なものであるため、各所にバグ・考慮漏れと思われる挙動が散見されます。上記のサンプルコードの作成を通じて、筆者が発見したものを以下に挙げます。

パスワードをかけた zip ファイルを渡した場合、ファイルの MIME タイプが application/x-javascript となる

アーカイブファイル内の構成（格納されているファイルのパス名など）までは読み込むことが可能ですが、ファイル自体の展開は不可能です。

アーカイブされたファイルの名前の文字コードが utf-8 以外の場合、2 byte 文字のファイル名を正しく扱えない

• そのような zip ファイルを開いた場合、ArchiveReader.getFilenames() で取得したファイル名の一覧は空文字列の要素の配列になっているように見える（それらの配列の要素は、直接 ArchiveReader.getFile() にパスとして渡した場合にファイルの取得はできるが、文字列として取り扱うことはできない ）。
• 同様の zip ファイルを開いた場合、ArchiveReader.getFile() にパスを文字列で指定すると、パスが 2 byte 文字の場合はファイルを取得できない

アーカイブされたファイルのサイズが大きい場合（画像・音声・動画など）、ArchiveReader.getFile() を経由したファイルの展開が途中の状態のまま処理が完了してしまう（ArchiveRequest に successイベントが発行される）

• 取得したファイルの Blob から window.URL.createObjectURL() すると、ファイルの読み込みが途中のまま
• FileReader.readAsDataURL() を介した場合、生成された dataURI が中途半端なところで切れている旨の警告が表示される
• ArchiveRequest.onload() で回避できるのではないかとおもったが、load イベントが発行されないためハズレ

780145 – ArchiveReader doesn’t unzip large files が修正され、最新の Nightly では、大きいファイルもちゃんと展開されるようになりました。

まとめ

現在の実装は非常に試験的なものであり、今後、どのような形に API および実装が落ち着いていくかは不透明ではありますが、手軽に zip アーカイブファイルを使用できるようになる可能性が示されたため夢は広がります。Archive API の提案がなされたメールアーカイブでは導入理由として「ゲームの開発のため」と書かれていますが、ゲームに限らず、epubのようなzip形式のコンテナを使用しているフォーマットのビューアの実装や、「複数のリソースファイルを1つに集約して通信をおこなうことによるリクエスト数の軽減」「ファイルを zip で圧縮することによる通信料の軽減」などのテクニックとして取り扱えることが期待できます。

反面、zip アーカイブされたファイルをクライアント上で展開させるという根本的な仕組みから、要求されるメモリ量も大きなものとなりますが、仕様の安定化および実装の普及までの時間がハードウェア性能の向上というかたちで解決してくれるものと前向きに期待しましょう（笑）

米国時間 8/3 午前 10 時過ぎ（日本時間 4 日 午前 2 時過ぎ）に、MDN の技術ドキュメント Wiki のシステムが新システムに移行しました。

今までは、DekiWiki という Mozilla 外部のシステムを使っていましたが、新システムは Kuma と呼ばれる、Mozilla 内製のシステムになりました。

ドキュメント翻訳のための機能として大きなものは、翻訳版と英語版との紐付けがシステム側で行われるようになったことです。新しい翻訳方法については、MDN 日本語版の翻訳についてのドキュメントを参照してください。

Kuma は SUMO のシステム Kitsune を元にしているものの、まだ実装の足りない部分や解決されていない不具合があります。主なものは、Mozilla 翻訳フォーラム内の Kuma の既知の問題を参照してください。

未知の不具合に遭遇したときは、MDN サイト右上のバグ報告ボタンから、Bugzilla に報告してください。

英語での報告が難しい場合は、翻訳フォーラム、あるいは、MDC 日本語版 MLへ報告してください。Twitter ユーザであれば、MDN 日本語版リーダー宛 (@potappo）にリプライやメンションを飛ばすのでもかまいません。

MDN 日本語版も、新システムになっても引き続き、コンテンツの充実を目指していきたいと思いますので、興味のある方はぜひ翻訳にご参加ください。

Android 版の Firefox 14 以降にはリモートデバッガ機能がサポートされており、PC 版の Firefox 15 以降と組み合わせることでモバイル Web サイトをリモートデバッグできるようになっています。リモートでバッグをするまでの手順を簡単に説明しますので、興味のある方は是非お試しください。

デバッグ環境の準備

Android 端末に Firefox 14 または Firefox 15 Beta をインストールし、Android の設定で USB デバッグを有効にしてください。Android 2.x であれば Android 設定 → アプリケーション設定 → 開発 → USB デバッグで設定できます。

PC 側では Android SDK および Firefox 15 Beta 以降をインストールしてください。Android SDK を使うには、Windows であれば端末に応じた デバイスドライバが必要になることや、~/.android//adb_usb.ini ファイルにサードパーティベンダー ID の記載が必要なことがあります (本来は manifest.ini を書くべきだという話もあります)。

SDK のインストールができたら、USB 接続して次のコマンドで Android 端末を認識できているか確認してください。

adb devices

接続した端末が表示されるようになれば準備は完了です。

リモートデバッガの接続手順

リモートデバッガを有効化

Android と PC 両方の Firefox でそれぞれ about:config ページを開いてください。ページ上部の検索バーに “debugger” と入力して絞り込み、devtools.debugger.remote-enabled という真偽値の設定を見つけ、true に切り替え、Firefox を再起動してください。

Android 端末を USB 接続し、次のコマンドで端末側のポートと PC 側のポートを中継させてください。

adb forward tcp:6000 tcp:6000

あとはデバッグしたりソースを確認したいページを Android 版の Firefox で開き、PC 版の Firefox で「開発者メニュー」 → 「リモートデバッガ」を選択してください。接続するホスト名とポート番号を入力するように求められますが、remote.debugger.port などの設定を変えたりしない限り、デフォルトの 「http://localhost:6000/」 で問題ありません。

接続できたらリモートデバッガウィンドウにソースが読み込まれるので、いつも通りファイルを選択、ブレークポイントを設定し、デバッグしてください。ステップ実行、コールスタックの確認、各タックでの変数の確認、変数の書き換えなど基本的なデバッグ機能は揃っています。

モバイル Web アプリをデバッグ

ブレークポイントを設定

なお、現時点の Android 版 Firefox 16 Aurora および Firefox 17 Nightly にはバグがありリモートデバッグできません(PC 版は問題ありません)。いずれ修正されますが、それまでは安定動作するバージョンでテストしてください。

Enjoy Remote Debugging!

Hixie が WHAWG のニュースグループに投稿したことを切っ掛けとして再び HTML5 およびその先の標準化について注目が集まる中、HTML5 仕様策定に関する最新の状況について W3C Blog に書かれた記事です。公式ブログの記事らしい落ち着いたトーンで書かれています。
誤訳の指摘はコメント欄や Twitter で @dynamitter 宛にお願いします。

原文: W3C Blog – HTML5 and HTML.next

2つ目は、HTML5 仕様を完成させるエディタチームにコミュニティから参加するメンバーを発表したことです。Travis Leithead、Erika Doyle Navara、Ted O’Connor 並びに Silvia Pfeiffer ですが、まだ増える予定です。私たちの会員からこのように時間と資金の援助を頂いたことで、私たちは HTML5 を先に進めていけると自信を持っています。また、私たちはワーキンググループがコミュニティの多くの皆さんと協力して次に来たるものにも注力していけることを嬉しく思います。Web 技術が生きた技術として成長を続けられるように。

2012-08-02 追記: HTML ワーキンググループの議長達は Canvas 2D Context の編集チーム も発表しました。

– 2012年 7月 26日 Jeff Jaffe

訳者コメント

Michael Smith さんも Google＋ にも書いていましたが、何か驚いたり慌てたりするようなことが起きているわけではありません。かつて無い速度と規模で Web 技術が進化し続ける中で、進化と安定化の両立を図るための協力・調整が続いています。

「HTML5 が 2 つ分裂する」と心配される方もいますが、HTML4 から HTML5 で変わったところがあるように、HTML5 とその次でも Web で求められ使われる技術の変化に応じて変わっていくのは自然ではないでしょうか。変化が早いから同時進行になっているだけで、対立や分裂とは違うと思います。

心配しすぎることなく、進化を続けるオープン Web プラットフォームの未来に期待しましょう。(・・).

若干テンション高めというかフレンドリーというかそんなニュアンスで訳しました。Hixie の意図するニュアンスとは異なる可能性がありますがご了承ください。
誤訳の指摘はコメント欄や Twitter で @dynamitter 宛にお願いします。

原文: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0119.html

HTML 仕様策定にここ数年 W3C が参加していたのを無視してこれた人は読まなくてオーケー。大量のバグメールが飛んできたけど何でだ？と思った人は続けて読んでね。

当時僕らが公式には “Web Applications 1.0″、裏では “HTML5″ って呼んでた仕様について W3C と共同作業を始めたのは今から数年ほど前 (2007 年頃) だった。僕らは仕様の名前を “HTML5″ と変更し、W3C もそのコピーを公開するようになったんだ。すると程なく、W3C では標準をいくつかの標準に分割したから (つまり、2D Canvas API, Server-Sent イベント、postMessage とかにね)、WHATWG 側でもそれに合わせるよう努力してみたんだ。けれど複数バージョンの仕様があることで混乱し、結局 WHATWG 側では僕が担当するすべてをまとめた、1 つの仕様だけに戻すことにしたんだ。僕らが今 “HTML Living Standard” って呼んでるやつにね。それから数年、この文書と W3C 側のいろんな文書はちょっとずつフォークしていったんだ。WHATWG 標準の冒頭 (訳注: 多分ここのこと) で書いてるようにね。

最近になって、HTML 戦線における W3C と WHATWG の目標もちょっとずれてきた。WHATWG では HTML や関連技術の正確な説明を作り上げることに集中してきた、つまり、バグは見つけたらすぐ [1] 直し、新しい機能は必要になったり使えるようになったら追加し、実装も追いかけてきた。その間 W3C はご立派な W3C 標準化プロセスに従ってスナップショット作りにいそしんできたんだ。そして遂に W3C ワーキンググループの議長達と僕は作業を 2 つに分けることにしたんだ。W3C HTML5, Canvas, Microdata 仕様の執筆に責任を持つ人と WHATWG 仕様のエディタ (僕) は別にしようってね。[2]

W3C と一緒にやっていく中で、僕らは WHATWG 仕様右下のウィジェットで登録されたバグを W3C の Bugzilla システムで管理してきた。W3C は WHATWG 仕様に対して登録されたバグのホストを快く続けてくれていたんだ。これまで W3C と WHATWG の仕様を両方を一人のエディタが担当していたから両仕様のバグを 1 つにまとめて、僕は仕様は 1 つしかないかのように処理してこられた。でもフォークしちゃうと (訳注: エディタが別になると) それは続けられない。だから、W3C の Bugzilla システムで HTML 仕様に登録されていたバグをすべて取り出して複製したんだ。1つは W3C 用に、もう一つは WHAWG 用にね。僕は WHATWG のバグを扱っていき、W3C の新しいエディタ(達) [a] は W3C のバグを扱っていく。もし君が最近大量の “operation convergence” って書かれたバグメールを受け取っていたら、そういうことさ。具体的にどうなるんだってことはこのメールに続けて書くね。

僕にどんな影響があるの？

* WHATWG の仕様にフィードバックを送るなら、このメーリングリスト (whatwg@whatwg.org) に送ってくれるのが一番簡単だよ。

*WHATWG の仕様のバグを報告するなら、WHATWG 仕様に付いてるツールを使ってくれれば適切なコンポーネントを選んでくれる。

*W3C Bugzilla を直接使ったり WHATWG 仕様のバグを検索したいのなら、Bugzilla で “WHATWG” プロダクトを選択してくれ。僕が編集してる仕様のコンポーネントは “HTML” だよ。他のコンポーネントは Anne とか他のエディタが編集してる仕様のためのものだからね。

*Bugzilla にコメントを書いて僕に読んで欲しいのなら、僕に割り当てられてるバグにコメントしているか確認してね。”WHATWG” プロダクトじゃなくて “HTML WG” プロダクトのバグは HTML WG のエディタに割り当てられているもので、多分僕は見ないから。(もちろん僕も W3C 側の変更をできる限り追い続けるけど、個別のバグコメントまでは目を通せないと思うんだ。)

WHATWG HTML 仕様で現在未解決のバグはこのリンクで確認できる:

https://www.w3.org/Bugs/Public/buglist.cgi?product=WHATWG&component=HTML&resolution

フィードバックがどれくらい溜まってるか確認するには、僕はこのグラフを見てる:

http://www.whatwg.org/issues/data.html

“operation convergence” についての詳細:

これまでバグには2つのバケツがあったんだ。(“HTML5 spec” とかいろんなコンポーネントの) W3C 仕様に登録されたバグと、(“other Hixie drafts” コンポーネントの) WHATWG 仕様に登録されたバグがね。その殆どは僕に割り当てられ、コンポーネントなんて気にしてこなかった [3]。

僕は最近 W3C スタッフと協力して 2 つのスクリプトを走らせて、バグを全部複製したんだ。1つ目のスクリプトでは “HTML5 spec” コンポーネントにあったバグを選択して、複製したバグを WHATWG プロダクトに登録して僕に割り当て、元のバグは nobody に割り当てた。2 つ目のスクリプトでは “other Hixie drafts” コンポーネントにあったバグを選択して、”WHATWG” プロダクトに移動させ、”HTML5 spec” コンポーネントに複製し、nobody に割り当てた。今回 nobody に割り当てられたバグはそのうち W3C の HTML5 仕様エディタになる誰かに割り当てられることになるだろう。今後登録されるバグには何も影響しない。これから先に進むため、長期的な計画をどうしていくか、僕はこれからも HTML ワーキンググループの議長達と一緒に決めていく。古い “other Hixie drafts” コンポーネントは無くしたよ。

ここで書いたことは、4月にアナウンスした WHATWG は W3C コミュニティグループ になるって件とは関係ないんだけど、要するに、W3C の HTML ワーキンググループからは独立するけど W3C との協力関係は保たれるってことさ。[4]

最終的な結果としては、HTML Living Standard の策定作業が再び加速され、W3C ワーキンググループと共同作業を始める前のペースを取り戻せることを、僕は期待している。

質問があるなら、僕に直接メールするか、IRC チャンネル (Freenode の #whatwg)で聞いてね。技術的議論の S/N 比を保ちたいから、このメーリングリストでは仕様策定プロセスに関する議論はしないで欲しいんだ。

— 脚注 —
[1] あるいは、見つけてから数ヶ月後にね… 今僕は 6 ヶ月ほど遅れてる。ゴメンね。頑張るよ！ (・・).

[2] http://lists.w3.org/Archives/Public/public-html/2012Apr/0204.html

[3] 詳しく書くと、僕は W3C HTML WG コンポーネントのバグについては “Accepted” や “Rejected” として閉じるブックマークレットを使っていた。HTML ワーキンググループのプロセスで要求される雛形があったからね。”other” コンポーネントのバグについては雛形なんて使わなかった。HTMLWG のプロセスを経る必要があるのは彼らのバグだけだったから。

[4] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Apr/0240.html

[a] 訳者追記: W3C 仕様のエディタについて、Canvas 2D などのエディタは未確定ですが HTML5 のエディタは Travis Leithead, Erika Doyle Navara, Ted O’Connor, Silvia Pfieffer になったようです: http://lists.w3.org/Archives/Public/public-html/2012Jul/0183.html

— Ian Hickson

訳者コメント

今回の件で「WHATWG と W3C が決別して HTML5 がフォークした！」と騒ぐ人もいるかと思いますが、そんな話ではありません。フォークって言葉を強調した記事に釣られないようにしましょう。

プロジェクトやツリー全体がフォークするのではなく、安定バージョンのブランチを切ってブランチ専用のメンテ担当者を割り当てましょうって話が進んでいて、バグ管理もトランクとブランチで分けるようになったんだと理解するのが正しいかと思います。普通の製品開発でも安定ブランチ作りますよね？

Hixie の期待通り再び HTML の仕様策定が加速され、Web がより魅力的なプラットフォームになることを期待しています。(・・).

今週は Firefox 14 がリリースされ、続けて Firefox 15 のベータ版も公開されました。ベータ期間中は安定性や互換性の修正が行われるのみで、基本的には新機能は追加されません。Firefox 15 のリリースは 8/28 を予定していますが、機能がほぼ確定するベータ版リリースに合わせ一足先に主な新機能と改良点をご紹介します。

Firefox 15 の特長

Firefox ではメモリ管理が改善され、特にアドオンを使用したり長時間ブラウジングを続けたときのメモリ使用量が大幅に削減されたり、Incremental GC の実装によりゲームのアニメーションなどが滑らかになるなど、パフォーマンス面で大きな改善が行われています。また、HTML5 と JavaScript で実装した PDF ビューアを同梱し、ブラウザの中で直接 PDF を表示可能になりました (当面ベータ版のみデフォルト有効)。

Web 開発者向けには、JavaScript デバッガ、レスポンシブデザインビュー、レイアウトビューといった新しい開発者ツールが追加され、標準の開発者ツールだけで一通りの Web 開発が行える環境が整いました。Web 標準のサポートについては High Resolution Time, Opus 音声コーデックなどをサポートするほか、次世代 JavaScript で標準化予定となっている関数のデフォルトパラメータや Rest パラメータに対応しました。

前回のバージョンで生まれ変わった Android 版では、続けてタブレット版も生まれ変わります。機能面では標準ブラウザからブックマークと履歴をインポートできるようになったほか、ページ内検索やページ中のテキストコピーに再対応したり、タブの操作性を改善したりするなど要望の多かった機能を実装しています。Web 開発者向けには近接センサーや光センサーのイベントに対応し、新しい Web アプリケーションを開発できるようになりました。

ユーザ向けの新機能・改良点

メモリ管理が改善されます

Firefox ではメモリ管理を改善し、一部のアドオンを使っていると長期間ブラウジングを行っているとメモリ使用量が増加し続ける問題を解決します。

一部のアドオンはタブを閉じてもそのページで使用していたオブジェクトへの参照を維持し続け、メモリが解放されない問題があります。今回 Firefox ではアドオンがページ中のオブジェクトへの参照を保持し続けている場合でも、閉じたタブで使用してたメモリが解放されるシステムを実装しました。これにより例えば Firebug 1.9.1, PicPasso 1.0.1, LoL 1.5, Youtube rating preview 1.03, Enter Select 7, Link Resolve, AutoPager 0.7.1.4 などを使用しているとタブを閉じてもメモリが解放されなかった問題が解決しました。

Firefox 14 と 15 で SiteAdvisor 3.4.1 を使用して 151 ページを開いた状態と、150 のタブを閉じた後の使用メモリ量を比較すると、右の図のようにタブを閉じた後で使用しているメモリは以前の約 1/5 にまで減少していることが分かります。詳しくは MemShrink プロジェクトのレポートをご覧ください。

Incremental GC が実装されました

訂正: 問題が見つかり Firefox 15 ではデフォルト無効となりました。Firefox 16 からデフォルト有効になる見込みです。

Firefox 15 では JavaScript エンジンに Incremental Garbage Collection が実装されました。これによりゲームのように大量のデータを処理し続ける Web アプリケーションが高速かつなめらかに動作し続けるようになりました。

PDF ビューアが同梱されます (リリース版では無効設定)

これまで PDF ファイルは Adobe などが提供するプラグインまたは別のアプリケーションでファイルダウンロード後に表示していましたが、プラグインはしばしばセキュリティホールの原因となっているし、Mac OS などにはプラグインが提供されていませんでした。

そこで Mozilla では PDF を Firefox のエンジンで直接描画できるよう、HTML5 と JavaScript で PDF ビューアを実装する PDF.js プロジェクトを進めてきていました。今回の Firefox ベータ版からはこのプロジェクトの成果が Firefox ベータ版に組み込まれます。但し、この機能はまだ完全ではなく実験的なものであり、すべての PDF ファイルを完全に描画できるわけであはりません。しばらくの間は Firefox のベータ版や開発版でのみ有効にされ、リリース版では無効化されます。リリース版で有効化するには about:config で pdfjs.disabled=false と設定してください。問題を見つけたら バグレポートをお願いします。

PDF.js の実装についての詳細は Mozilla Vision 2012 での講演をご覧ください。

設定画面をタブ内に表示可能になります

Firefox の設定画面は別ウィンドウで開かれますが、タブの1つとして開くことが可能になります。about:config ページで browser.preferences.inContent 設定を true に設定すると設定画面が新しいタブで開かれるようになります。

Web 開発者向けの新機能・改良点

開発者ツールにデバッガ、レスポンシブデザインビュー、レイアウトビューが追加されます

Firefox 標準の開発者ツールに JavaScript デバッガ、レスポンシブデザインサイトの表示を確認するツール、要素を調査するときにボックスモデルのサイズを一目で確認できるビューが追加されます。

JavaScript デバッガではブレークポイントや例外で停止し、関数呼び出しスタック、関数スコープやグローバルスコープの変数などを確認や書き換えしながらステップ実行するといった、基本的な JavaScript デバッグ機能が実装されています。

ステップ実行時には更新された変数がハイライトされたり、configurable, enumerable, writable といった変数のプロパティをツールチップで確認できるなど便利な特徴もあります。一方で一般的なデバッガで提供されているが未実装である機能には、オブジェクトのプロパティ値変更を監視する監視点機能があります。監視点が必要な場合は Object.watch() を利用するか、Firebug などをご利用ください。

レスポンシブデザインビューでは、マルチデバイス対応のサイトを作る際に様々な画面サイズでの表示を簡単に確認できます。指定サイズのウィンドウで表示したときの結果を確認したり、画面を回転して縦横のサイズを入れ替えた表示もボタン 1 つで確認できます。

レイアウトビューは要素の CSS ボックスサイズ(width x height, margin, border, padding)をグラフィカルに表示するビューです。「要素を調査」するときにスタイルビューを開くと右下にレイアウトビューが表示されます。不要なときは右上のボタンをクリックすればレイアウトビューが折り畳まれ width x height だけが表示されます。

Firefox 15 での開発者ツール強化について詳しくは Hacks Blog の記事をご覧ください。Firefox 標準の開発者ツール全般についてまとめたスライドもあります。

High Resolution Time に対応します

High Resolution Time の Performance.now() に対応しました。これにより従来より正確に時間を取得、パフォーマンス測定などが行えるようになります。

Opus Audio Codec をサポートします

Firefox 15 では IETF で標準化が進められている Opus 音声コーデックをサポートします。このコーデックでは MP3, AAC, Ogg などといった既存のコーデックよりも圧縮率が高く、低帯域でも高音質な音楽や通話を実現できます。

Opus は <audio> タグではもちろん、開発版では実装済みの WebRTC の Media Capture and Stream で高速かつ低帯域で高品質な通話アプリケーションを実現するためにも使われます。詳しくは Hacks Blog の記事をご覧ください。

関数のデフォルトパラメータ、rest パラメータに対応します

次世代 JavaScript の標準である ECMAScript 6th で導入される予定の機能を順次実装しています。Firefox 15 では関数の引数定義に使用するデフォルトパラメータや rest パラメータ に対応しました。

Device Storage API をサポートします

写真のギャラリーアプリケーションのように、ファイルを管理するアプリケーションのため Device Storage API を実装しました。ファイルなどバイナリデータの保存には IndexedDB と Device Storage API を用途に応じて使い分けることを提案しています。この機能は Firefox OS 以外では無効になっているため、PC や Android で試す場合には about:config ページで device.storage.enabled を true に設定してください。

な お、類似した目的で提案されている API として Chrome が実装する File System API がありますが、Web アプリケーション向けの API として最適ではないと考えており、今のところ Firefox での実装予定はありません。詳しくは Hack Blog の記事をご覧ください。

Android 版の新機能・改良点

タブレット版も生まれ変わります

Android 版 Firefox は先日ユーザインターフェイスをすべて書き直し、マルチプロセスからシングルプロセスマルチスレッドへと設計を変更し、Android のブラウザで最高のパフォーマンスを実現しました。この生まれ変わった Firefox はスマートフォン限定のリリースとなっていましたが、Firefox 15 ではタブレット版も生まれ変わって再リリースします。

標準ブラウザからのブックマークインポートに対応します

Android 標準ブラウザのブックマークと履歴をインポートできるようになりました。設定画面の一番下にある「Import from Android」という項目をタップして、インポートしたい項目を選択してください。

Firefox が「ブラウザの履歴とブックマークを読み取る」権限を必要とするようになったのはこの機能のためです。

ページ内検索やテキストのコピーに再対応します

Firefox 14 では大幅に高速化して生まれ変わったバージョンを皆さんにいち早くお届けするため、これまでのバージョンでサポートしていた機能が一部未実装になっていました。Firefox 15 では再びページ中のキーワード検索やテキストを範囲選択してコピーできるようになります。

ページ切り替えの操作性を改善します

生まれ変わった Firefox では片手でも操作しやすいように、右上から左下に右手親指で操作しやすいところにメニューやボタンが集められています。しかし、右上の開いているページ数をクリックしてページ一覧を表示したとき、各ページを閉じるボタンは左側にあってページを閉じる操作だけは右手親指ではしにくくなっていました。Firefox 15 では閉じるボタンも右側に移動させるだけでなく、開いているページ一覧で左右にスワイプすることでもページを閉じられるようになりました。

また、開いているページが 1 つだけのときには “＋” を表示して、すぐに新しいページを開けるようになっていましたが、パソコンと同期しているタブ一覧にアクセスするには複数ページを開いている必要がありました。そのため Firefox 15 からは開いているページの数にかかわらず数字を表示し、タップするとページ一覧が開かれるよう統一されました。新しいページを開くときも同じ場所に表示される “＋” を数字に続けてタップするだけで簡単です。

近接センサーや光センサーに対応します

Firefox では Web アプリケーションがネイティブアプリケーション同様、ハードウェアセンサーなどもフル活用できるよう Web API の実装と標準化をリードしています。Firefox 15 では当初 Sensor API として検討され、後に Proximity Event や Light Event として標準化が進められている、近接センサーや光センサーを使用するイベント deviceproximity と devicelight に対応しました。

関連情報

• Firefox 15 for developers

以前のバージョンについて

• Firefox 14 の主な新機能を紹介します
• Firefox 13 の主な新機能を紹介します
• Firefox 12 の主な新機能を紹介します
• Firefox 11 の主な新機能を紹介します
• Firefox 10 の主な新機能を紹介します
• Firefox 9 の主な新機能を紹介します
• Firefox 8 の主な新機能を紹介します
• Firefox 7 の主な新機能を紹介します