このサイトの記事更新は2019年11月に終了されました。過去記事アーカイブを公開しています。
投稿されたすべてのトピック
Firefox 16 のサイト互換性に関わる修正のまとめ
Firefox 16 の正式版が今日 深夜にリリースされる予定です。可能な限り互換性を維持するよう開発されましたが、他のブラウザとの相互運用性や最新 Web 標準仕様への準拠のため、後方互換性に関わる修正も含まれます。そのような修正点をまとめましたので、動作検証時などにご参照ください。
ここでは後方互換性に影響し得る修正のみ解説します。その他の新機能や変更点については次のページをご覧ください。
- Firefox 16 ベータ版リリースノート
- Firefox 16 for developers (MDN)
- Aurora 16 is out — Unprefixing time ! (Mozilla Hacks)
この一覧に漏れや間違いがあるときはコメント欄でお知らせください。
CSS
多くの CSS プロパティから接頭辞が外れました
- Bug 762302 – [css3-animations] unprefix CSS Animation properties and @keyframes rule
- Bug 762303 – [css3-transitions] unprefix CSS Transition properties
- Bug 745523 – [css3-transforms] Unprefix transforms
- Bug 752187 – Drop prefix for gradients
- Bug 771678 – [css3-values] unprefix calc()
CSS アニメーション、トランジション、トランスフォーム の各プロパティから -moz-
ベンダー接頭辞が外れました。また グラデーション の各関数と calc
からも接頭辞が外れました。グラデーションについては、接頭辞の有無で構文が大幅に変わっていることに注意してください。
接頭辞付きのプロパティや関数を使用する場合は、前方互換性のため、接頭辞なしの形式も必ず併記するようにしましょう。今後、そうした配慮がなされていない CSS は適用されなくなる可能性があります。
トランジションとアニメーションの継続時間に指定した負の値は無視されるようになりました
transition-duration
と animation-duration
の各プロパティに負の値を指定した場合、従来は初期値の 0s
と解釈されていましたが、今後は不正な値として見なされ、宣言自体が無視されます。
matrix()
に指定した長さの値は無視されるようになりました
トランスフォーム関数 の matrix
と matrix3d
について、Firefox はこれまで誤って数値だけでなく長さの値 (例えば 10px
のように単位の付いた値) を受け入れていました。この挙動が仕様に合わせて修正され、長さの値が指定された場合はパースエラーを返すようになりました。
ボーダーによってテーブルセルの高さが変わる問題が修正されました
これまで、テーブルセル (td
要素) の上下に border
や padding
が指定されると、その分セルの高さが縮まって表示されていました。Firefox 16 では、CSS 標準に従うよう、このレイアウト問題が修正されています。実際の例はバグに添付されたテストケースを参照してください。
メディアクエリの解像度が CSS ピクセル単位で扱われるようになりました
CSS3 メディアクエリの仕様が更新され、解像度の単位である dpi
、dpcm
、dppx
が、物理単位ではなく CSS ピクセル単位のドットに相当するようになりました。Firefox の実装もこれに合わせて更新されました。
DOM
いくつかの API から接頭辞が外れました
IndexedDB から接頭辞が外れました。今後は mozIndexedDB
ではなく標準の indexedDB
オブジェクトを使用できます。また、バッテリー、バイブレーターの各 API についても接頭辞が外れています。
Microdata API が実装されました (10/15 追記)
HTML5 の Microdata DOM API が実装され、document
に getItems
プロパティが、element
に itemId
、itemProp
、itemRef
、itemScope
、itemType
、itemValue
、properties
プロパティが追加されました。
Six Apart 社から提供されている Movable Type がこの影響を受けたことが確認されています。各要素に itemId
という独自プロパティを付加していたために一部機能が正常に動作しなくなり、急遽パッチが公開されています。
- Bugzilla-jp Bug 6834 – Movable Typeでの記事作成時にカテゴリを選択しても反映されない
- Firefox 16 でカテゴリおよびフォルダの選択が保存できない
- Rename itemId because cannot work on FireFox16 or later
各要素に独自データを付加したい場合は、独自プロパティの代わりに element.dataset
を使う方法が安全でしょう。文字列型以外のデータも保存できる setUserData
/getUserData
も Firefox には実装されていますが、これらは 廃止予定 であり、WeakMap
で代用可能とのことです。
java
オブジェクトが廃止されました
window.java
と window.packages
の各グローバル DOM オブジェクトが廃止されました。これらのオブジェクトはほとんど文書化されておらず、実際に使われることは非常にまれかと思います。この変更は Firefox 15 で行われる予定でしたが、既存の拡張機能との互換性を保つためバックアウトされていました。
SVG と XPath の例外の種類が DOMException
に統一されました
SVGException
と XPathException
は削除され、DOMException
に置き換えられました。
SmsRequest
は DOMRequest
に置き換えられました
SmsRequest
は、より一般的で同じ属性とイベントハンドラを提供する DOMRequest
に置き換えられました。
select.size
に負の値を指定した場合の挙動が変わります
select
要素の size
プロパティに負の値を与えた場合、従来は例外が投げられていましたが、今後は 0
と見なされます。
CSSNameSpaceRule.type
が正しい値を返すようになりました
CSSNameSpaceRule
の type
プロパティが、CSSRule.UNKNOWN_RULE
(0
) ではなく CSSRule.NAMESPACE_RULE
(10
) を返すよう修正されました。
mozApps.installPackage
が無効化されました
Apps
API の installPackage
関数は、機能の実装が完了するまで削除されることになりました。
その他
MD5 アルゴリズムで署名された証明書は受け入れられなくなります
MD5 ハッシュアルゴリズムは安全でないことから、Firefox 16 以降無効化する措置が取られました。MD5 アルゴリズムで署名された SSL 証明書を使用しているサイトを Firefox で開くとエラー画面が表示されます。便宜的に、ユーザがこのエラーを無視することも可能となっています。
なお Thunderbird でも同様に、メールサーバがそうした証明書を使用している場合はエラーとなり、メッセージの送受信を行えなくなります。ただし Thunderbird 16 では何もエラーメッセージは表示されません。
ユーザエージェント文字列にセキュリティパッチレベルのバージョンまで含まれなくなります
この変更により、例えば予定外の Firefox 16.0.1 がリリースされた場合も、ユーザエージェント (UA) 文字列内のバージョンは 16.0.1
ではなく 16.0
とだけ表記されます。
半角空白の後、全角空白の前で行が折り返されるようになりました
実際の日本語のページについて「Firefox のみレイアウトが崩れる」と指摘があった問題です。他のブラウザと同様に、全角空白の前で行が折り返されるよう修正が行われました。
WebSockets の接続切断処理が最新仕様に合わせて更新されました
コードから close
関数が呼び出された際の切断処理中に onerror
や onclose
イベントが発生しないようにするなど、最新の WebSockets 仕様に合わせて実装が更新されました。
execCommand()
はコマンドが無効の場合 false
を返すようになりました
リッチテキストエディタ で execCommand
関数が呼び出された際に、コマンドが有効でなければ正しく false
を返すようになりました。これまでは常に true
が返っていました。
メディアを巻き戻したときの played
プロパティの値が修正されました
video
/audio
要素を再生し、巻き戻した後に played
プロパティの値を取得すると、巻き戻した位置が返っていました。再生が終わった位置を正しく返すよう実装が修正されました。
リグレッション
Firefox 16 で発生したことが判明しているリグレッションのうち、サイト互換性に影響すると思われるバグは以下の通りです。
- Bug 782729 – Pointer lock does not work on FPS “PlayCanvas” demo — Firefox 18 で修正
- Bug 779399 – Twitter Bootstrap buttons display unwanted horizontal line on hover. — Firefox 17 で修正
- Bug 789122 – Google Presentations are Clipped (zoom-related)
- Bug 779035 – SVG mask is clipped when text zoom is applied
- Bug 797231 – Clip path region is incorrect with direct2d
- Bug 773847 – Selecting to capture a picture for getUserMedia test page fails with an exception thrown on startMedia line 139 — Firefox 17 で修正
- Bug 789747 – Slow and jerky slideshow on iweb.com since Firefox 16
以前のバージョンについて
以前のバージョンについても同様に、後方互換性に関わる修正点をまとめています。
- Firefox 15 のサイト互換性に関わる修正のまとめ — まだ文書化されていません
- Firefox 14 のサイト互換性に関わる修正のまとめ — まだ文書化されていません
- Firefox 13 のサイト互換性に関わる修正のまとめ
- Firefox 12 のサイト互換性に関わる修正のまとめ
- Firefox 11 のサイト互換性に関わる修正のまとめ
- Firefox 10 のサイト互換性に関わる修正のまとめ
- Firefox 9 のサイト互換性に関わる修正のまとめ
- Firefox 8 のサイト互換性に関わる修正のまとめ
- Firefox 7 のサイト互換性に関わる修正のまとめ
- Firefox 6 のサイト互換性に関わる修正のまとめ
- Firefox 5 のサイト互換性に関わる修正のまとめ
Firefox 16 のアドオン互換性に関わる修正のまとめ
[これは Mozilla Add-ons Blog の記事 Add-on Compatibility for Firefox 16 の抄訳です。この記事の公開後に判明した Firefox 16 でウィンドウ読み込みハンドラが呼び出されない可能性 も併せてご覧ください]
Firefox 16 が来週リリースとなります。Firefox 16 の変更点でアドオンの互換性に影響を及ぼす可能性のあるものを以下にまとめました。Firefox 16 for Developers により詳しい情報が載っていますので、こちらも併せてご覧ください。
一般
- 多数の CSS プロパティの接頭辞が外されました。このため、以前書かれた CSS が適用されなくなる可能性があります。接頭辞付きプロパティを使う場合は、前方互換性のため、接頭辞なしの形式も必ず併記するようにしましょう。MDN と Mozilla Hacks にも詳しい情報が載っています。
java
DOM オブジェクトが廃止されました。拡張機能で Java を使っている場合、グローバルjava
オブジェクトを取得するために採用している方法を見直す必要があるかもしれません。また、Java がアドオンに十分対応していないことや、Java プラグインがブロックリストに追加された場合にあなたの拡張機能も影響を受けることを考え、可能であれば Java の使用をやめることを検討すべきでしょう。リンク先のバグに回避策についての情報が載っています。- IndexedDB の接頭辞が外れました。この接頭辞外しも一部のアドオンに影響する可能性があります。
- 署名された拡張機能の証明書が起動時に毎回検証される挙動が廃止されました。今後、デジタル署名されたアドオンの証明書はインストール時のみ検証されます。この変更による影響は特にないと思いますが、自社のアドオンに署名している場合は、いずれにしても気を付けてテストしてみてください。
browser.js
のinit
/shutdown
関数がリファクタリングされました。これはbrowser.js
のBrowserStartup
/delayedStartup
などの関数にパッチを当てているアドオンに影響します。
XPCOM
nsClipboardPrivacyHandler
が使用するプライベートブラウジングモードが、グローバルからウィンドウごとに変わりました。このバグの修正によってnsITransferable
の使われ方が変わりました。このインタフェースはドラッグ&ドロップやクリップボード操作によく使われていますが、今後は使用前に初期化関数呼び出しが必要となります。- Bug 767134 の修正によって一部の
nsIContentPolicy
コンシューマが動作しなくなります。この変更についてはバグのコメント 1 で詳しく説明されていますが、簡単に言えば、nsIContentPolicy
を実装している場合、ロケーションバーに URL が入力されたときにchrome://
URL をリクエスト元引数として取得できなくなります。 - サイクルコレクションの静的初期化処理が削除されました。これは独自の XPCOM クラスにサイクルコレクションを実装しているバイナリアドオンのみに影響します。
新機能
- Firefox コマンドラインが実装されました。これは Web 開発者にとってより便利な機能ですが、このツールは拡張可能なものとして設計されていることから、アドオン開発に活用するクリエイティブな方法があるのではないかと思います。まだドキュメントは用意されていませんが、コードを読む ところから始めることはできます。また、テーマ作者はこの新しい UI に注意すべきでしょう。当該スタイルは
gcli.css
に書かれています。 - OS.File が実装されました。このライブラリはファイルシステムへのアクセスをより一層簡単にするものです。またこれは、これまで一般的にワーカーの使用に関する重要な制限事項であったクロームワーカーに対して提供されます。yoric のブログ記事 に、このライブラリを開発した動機が書かれています。
- 共有モジュール
Identity.jsm
が実装されました。Persona (旧名 BrowserID) が最近 ベータ版へ移行 し、この機能を利用するためのモジュールが Firefox へ統合されました。開発者の皆さんは、どのようなものか調べて、素晴らしい応用作品を作ってください
この一覧に載っていない変更点や間違いを見つけたらコメント欄でお知らせください。もしあなたのアドオンが Firefox 16 で動かなくなった場合は、筆者の方でも調査したいと思います。
AMO に登録されているアドオンの 自動互換性テストと対応バージョンの更新 はもう間もなく行われますので、後ほどメールをチェックしてみてください。
Camera API で写真撮影 – WebAPI の一部
原文: Taking pictures with the Camera API – part of WebAPI (on April 2, 2012 by Robert Nyman)
WebAPI の一部である Camera API を通じて、端末のカメラで写真を撮り、表示中の Web ページにアップロードすることが可能になります。これは、input
要素に type="file"
と accept
属性を指定することで撮影した写真画像の入力を実現しています。
HTML は次のようになります:
<input type="file" id="take-picture" accept="image/*">
ユーザがこの HTML 要素を使用すると、入力する画像をファイルから選ぶか端末のカメラで写真を撮るかの選択肢が表示されます。カメラを選択すると写真撮影モードになります。
写真を撮影した後、その写真を受け入れるか破棄するかを選びます。受け入れると、<input type="file">
要素に送信され、この要素の onchange
イベントが発生します。
写真への参照を取得する
File API の助けにより、撮影した写真や選んだファイルにアクセスすることができます:
var takePicture = document.querySelector("#take-picture"); takePicture.onchange = function (event) { // 写真やファイルへの参照を取得 var files = event.target.files, file; if (files && files.length > 0) { file = files[0]; } };
Web ページに撮影した写真を表示する
撮影した写真 (画像ファイル) への参照を取得したら、createObjectURL を使用して写真を参照する URL を作成し、その URL を画像の src
に設定してください:
// 画像要素を参照 var showPicture = document.querySelector("#show-picture"); // window.URL オブジェクトを取得 var URL = window.URL || window.webkitURL; // ObjectURL を作成 var imgURL = URL.createObjectURL(file); // img src に ObjectURL を設定 showPicture.src = imgURL; // パフォーマンス上の理由から使用済みの ObjectURL を破棄 URL.revokeObjectURL(imgURL);
createObjectURL
がサポートされていない場合は、代わりに FileReader にフォールバックしてください:
// createObjectURL が未サポートの場合にフォールバックする var fileReader = new FileReader(); fileReader.onload = function (event) { showPicture.src = event.target.result; }; fileReader.readAsDataURL(file);
完全なデモとコード例
完全に動作する Camera API デモ のページを作成しました。以下は、このデモで使われている HTML ページと JavaScript ファイルのコードです:
HTML ページ
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Camera API</title> <link rel="stylesheet" href="css/base.css" type="text/css" media="screen"> </head> <body> <div class="container"> <h1>Camera API</h1> <section class="main-content"> <p>A demo of the Camera API, currently implemented in Firefox and Google Chrome on Android. Choose to take a picture with your device's camera and a preview will be shown through createObjectURL or a FileReader object (choosing local files supported too).</p> <p> <input type="file" id="take-picture" accept="image/*"> </p> <h2>Preview:</h2> <p> <img src="about:blank" alt="" id="show-picture"> </p> <p id="error"></p> </section> <p class="footer">All the code is available in the <a href="https://github.com/robnyman/robnyman.github.com/tree/master/camera-api">Camera API repository on GitHub</a>.</p> </div> <script src="js/base.js"></script> </body> </html>
JavaScript ファイル
(function () { var takePicture = document.querySelector("#take-picture"), showPicture = document.querySelector("#show-picture"); if (takePicture && showPicture) { // Set events takePicture.onchange = function (event) { // Get a reference to the taken picture or chosen file var files = event.target.files, file; if (files && files.length > 0) { file = files[0]; try { // Get window.URL object var URL = window.URL || window.webkitURL; // Create ObjectURL var imgURL = URL.createObjectURL(file); // Set img src to ObjectURL showPicture.src = imgURL; // Revoke ObjectURL URL.revokeObjectURL(imgURL); } catch (e) { try { // Fallback if createObjectURL is not supported var fileReader = new FileReader(); fileReader.onload = function (event) { showPicture.src = event.target.result; }; fileReader.readAsDataURL(file); } catch (e) { // var error = document.querySelector("#error"); if (error) { error.innerHTML = "Neither createObjectURL or FileReader are supported"; } } } } }; } })();
Web ブラウザのサポート
- Camera API は現在、Android 端末上の Firefox と Google Chrome でサポートされています。
- createObjectURL は、Firefox と Google Chrome、Internet Explorer 10 以降でサポートされています。
- FileReader は、Firefox と Google Chrome、Internet Explorer 10 以降、Opera 11.6 以降でサポートされています。
未来
WebRTC (ブラウザ間で音声と動画、データのリアルタイム通信をサポートしています) と navigator.getUserMedia
のアプローチにより、いくつもの主要な Web ブラウザでこれらの機能を目にすることができるでしょう。詳しい情報は、Firefox の Web Platform Roadmap をご覧ください。
しかし今は、写真の撮影とキャプチャを楽しんでください!
WebTelephony API と WebSMS API – WebAPI の一部
原文: WebTelephony API and WebSMS API – Part of WebAPI (on March 1, 2012 by Robert Nyman)
以前、Mozilla’s Boot to Gecko – The Web is the Platform と Gaia, Mozilla’s user interface for Boot to Gecko で議論され明らかになったように、Web はとてもパワフルなプラットフォームになりつつあります! そこで、私たちの WebAPI イニシアチブから、WebTelephony と WebSMS の 2 つのエキサイティングな API を紹介したいと思います。
WebTelephony
基本的な電話機能へのアクセスは、単純に navigator.mozTelephony
を通して行うだけです。このオブジェクトへの参照を取得すれば、電話をかけたり受けたりできるようになります。以下は簡単なコード例です:
// Telephony オブジェクト var tel = navigator.mozTelephony; // 電話がミュートになっていないか確認 (read/write プロパティ) console.log(tel.muted); // スピーカが有効か確認 (read/write プロパティ) console.log(tel.speakerEnabled); // 電話をかける var call = tel.dial("123456789"); // 通話のためのイベント call.onstatechange = function (event) { /* 状態に使われる値: "dialing", "ringing", "busy", "connecting", "connected", "disconnecting", "disconnected", "incoming" */ console.log(event.state); }; // 上記のイベントに対応する関数 call.onconnected = function () { // 通話が接続された }; call.ondisconnected = function () { // 通話が切断された }; // 呼び出しを受ける tel.onincoming = function (event) { var incomingCall = event.call; // 呼び出し回数 console.log(incomingCall.number); // 呼び出しへの応答 incomingCall.answer(); }; // 通話を切断する call.hangUp(); // 呼び出しを繰り返し、状態の変更に応じた動作を行う tel.oncallschanged = function (event) { tel.calls.forEach(function (call) { // Log the state of each call console.log(call.state); }); };
Telephony は、Gaia の dialer と ホーム画面から利用可能です。
WebSMS
携帯電話のもう一つの中心的な機能は、SMS メッセージの送受信です。以下のコードでどのように行うかを示します:
// SMS オブジェクト var sms = navigator.mozSMS; // メッセージ送信 sms.send("123456789", "Hello world!"); // メッセージ受信 sms.onrecieved = function (event) { // メッセージを読む console.log(event.message); };
ハックと貢献
これらの API とその内部の動作の探求に興味がある方は、Mozilla の Boot to Gecko のユーザインターフェース (Gaia) を調べることをお勧めします。Gaia に含まれる dialer.js ファイルと sms.js ファイルを調べてください。
また、Web 技術のスキルをスマートフォンの開発やカスタマイズのために役立てたい方は、遠慮せずに Gaia の開発に協力してください!
VS Express 2012 for Desktopリリース
modbuilders.jpに投稿しましたので、リンク貼っておきます。
VS Express 2012 for Desktopリリース
http://modbuilders.jp/vc11e-released/
今回のExpressは64bit版ビルドできます。
Windows版のIMEのコードのログをとる方法 (TSF版)
以前、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
の数値をとことん大きな値に変更してください。数値の単位はミリ秒です。そうすれば、シンプルなログを取得することができます。
Battery API の使い方 – WebAPI の一部
原文: Using the Battery API – Part of WebAPI (on February 7, 2012 by Robert Nyman)
端末やコンピュータでバッテリー残量を検出することで、現在の状態をユーザに知らせる助けになります。Mozilla の WebAPI には、この機能を提供する Battery API があります。
バッテリーへのアクセス
はじめに、battery オブジェクトにアクセスしましょう:
var battery = navigator.mozBattery;
プロパティ
端末のバッテリーの充電レベルを検出するために、いくつかのプロパティが提供されています:
- Battery level
- 現在のバッテリー残量を確認します。0 から 1 の間の値を返します。
- Battery charging
- 端末またはコンピュータが充電中かどうかを表す真偽値を返します。
- Battery chargingTime
- バッテリーの充電が完了するまでの残り時間を秒単位で返します。充電中である時に使用可能です。
- Battery dischargingTime
- バッテリーが空になるまでの残り時間を秒単位で返します。充電中でない時に使用可能です。
// バッテリー残量をパーセントで取得します
var batteryLevel = battery.level * 100 + "%";
// 端末が充電中かどうかを調べます
var chargingStatus = battery.charging;
// 充電完了までの時間です
var batteryCharged = battery.chargingTime;
// バッテリーが空になるまでの時間です
var batteryDischarged = battery.dischargingTime;
イベント
バッテリーの状態変更を検出する 4 つのイベントが使用可能です:
- levelchange
- バッテリー残量が変化したことを検出します。
- chargingchange
- 充電中にプラグが外された、またはプラグが挿され充電開始したことを検出します。
- chargingtimechange
- 端末の充電時間が変化したことを検出します (充電中の時)。
- dischargingtimechange
- 端末のバッテリーが空になるまでの時間が変化したことを検出します (充電中でない時)。
<code>battery.addEventLister("levelchange", function () { // 端末のバッテリー残量が変化した時のコード }, false); battery.addEventListener("chargingchange", function () { // 端末の充電が開始された、または充電が解除された時のコード }, false); battery.addEventListener("chargingtimechange", function () { // 端末の充電時間が変化した時のコード }, false); battery.addEventListener("dischargingtimechange", function () { // 端末のバッテリーが空になるまでの時間が変化した時のコード }, false);</code>
端末のサポート
Battery API は、次の OS のFirefox Beta でサポートされています:
- Android (Firefox Aurora) (訳注: 記事執筆時の Aurora)
- Windows
- Linux (UPower がインストールされたディストリビューション。最近のものは同梱)
今のところ、Mac OS X 上の実装作業は行われていません。スキルのある方の 貢献を歓迎します!
デモとコード
基本的な Battery API のデモ とソースコードを用意しました。ソースコードは、GitHub 上の Battery API リポジトリ にあります。
ご使用の端末で期待した結果が得られないときは、原因を究明するために バグを報告 してください。この機能は実験段階にあるため、製品で使用する準備はまだできていません。
Vibration API の使い方 – WebAPI の一部
原文: Using the Vibration API – Part of WebAPI (on January 26, 2012 by Robert Nyman)
Mozillas WebAPI 活動の一部として、Vibration API をすべての端末でサポートするための作業をしています。
Vibration API は、ゲームやアプリなどで端末を振動させることにより、ユーザに通知できるようにすることを意図しています。この API は、ネイティブのバイブレータにアクセスし、振動させる時間の長さを伝えます。
コード例
これを行う方法はとても単純です。この例では、引数に振動させる長さを与え、ミリ秒単位で指定します:
navigator.mozVibrate(1000);
振動をコントロールする他の方法には、振動と静止を切り替えて振動パターンを指定する方法があります。リストの奇数位置 (1 番目と 3 番目) では振動時間、偶数位置 (2 番目と 4 番目)では静止時間を指定します:
navigator.mozVibrate([200, 100, 200, 100]);
振動を停止したいときは、mozVibrate
メソッドの引数に 0 または空のパターンを渡して呼び出すだけです:
navigator.mozVibrate(0);
navigator.mozVibrate([]);
試してみよう!
今すぐ試してみたい方は、Firefox 11 になる予定の Firefox Aurora で実験することができます。現在は、バイブレーションをサポートしている端末 (ほとんどの Android 版の Firefox) でのみ動作します。
注記: Android 端末でバイブレートのフィードバックをオンに設定した場合、バイブレーションがキャンセルされる可能性があります。
デモ
コードを理解するために必要な小さなデモを用意しました。このコードを試した感想を教えてください。
編集: 私たちは、実装の名前を一時的に Vibrator API にしていましたが、これは悪い印象を与えていたため、Vibration API に変更しました。この API の詳細は、W3C Vibration API draft にもあります。
WebAPI 活動についての詳細
原文: More details about the WebAPI effort (on August 29, 2011 by Jonas Sicking)
私たちが望んだとおり、新たにアナウンスした WebAPI 活動 (和訳) には、興味深いものが数多くあります。そのため、私たちが行いたいことと、私たちの目の前にある課題について、より詳しく説明しなければならないでしょう。
目標
この活動の目標は、Web の可能性を広げる API を作成することです。私たちは、Web にいくつかの能力が欠けているというだけで、人々にプロプライエタリなプラットフォームを開発する道を選んでほしくないのです。
主な活動は、少なくとも初期には、端末に接続されたハードウェアへのアクセスを可能にし、データを端末に格納したり利用可能にすることです。ハードウェアに対しても、人々が Web プラットフォームを使えるフルレンジのハードウェアを作りたいと考えています。カメラなどの共通のハードウェアから、滅多に使われない USB 駆動の Nerf キャノンまで。また、Bluetooth や NFC などの通信ハードウェアも利用可能にしたいと考えています。
端末に格納されるデータについて、もっともよく議論されるデータは、連絡先とカレンダーです。これは、データの読み込みと書き込みの両方の機能が含まれます。私たちは、Web プラットフォームが格納された連絡先の列挙とそれらの詳細の読み込みの両方をできるようにし、連絡先の追加と削除もできるようにしたいと考えています。つまり、Web プラットフォームが Web ページを作成できるようにしたり、Web アプリでユーザが連絡先リストを管理できるようにしたいのです。同じことが、カレンダーのイベントや、端末に格納された他の形式のデータについても言えます。
セキュリティとプライバシー
このような種類の API がまだ Web プラットフォーム向けに開発されていないのは、これらがセキュリティとプライバシーに影響することが大きな理由の一つです。はっきり言って、あらゆる単独の Web ページに対して自分の連絡先リストやカレンダーをいじれるようにしたくはありません。また、USB デバイスの接続時にコマンドを発行できるようにすると、すべての人のコンピュータがすぐにゾンビ化される結果をもたらすでしょう。
そのため、これらの API を開発するときは、常にそれぞれに見合ったセキュリティモデルを開発しなければなりません。例えば、現在 Geolocation 機能で行っているように、単純にユーザに使用許可を求めるのも良いでしょう。他に、セキュリティに影響する恐れがあるところやユーザに危険性を説明するのが難しいところでは、より良い解決策を用意しなければなりません。
どのようなセキュリティモデルを構築すべきか、私たちにはまだ分かりませんが、API を数百万人のユーザに提供する前に、信頼できるセキュリティの解決策を持つ計画があることを、特に強調しておきたいと思います。
Robert O’Callahan が Web アプリケーションの許可設定 についての本当にすばらしい記事を投稿しています。
標準
Mozilla は常に Web 標準への力強いコミットをしています。この姿勢が変わることはありません! 私たちが開発している API はすべて、ブラウザと端末の両方に対して標準化と実装を行うという目標を持って開発されています。
しかし、標準を良い標準にすることは重要です。これは実験を伴います。Web にとって新たな領域やセキュリティに敏感な領域においては特にそうです。
標準化機構は、研究をするのに良い場所ではありません。これは、先に標準化機構の外で実験と研究を行いたい理由です。しかし、常にオープンであり、常にフィードバックを求めています。また、API 名に接頭辞を付けて、これらが実験的であり、標準化されたら変更する (接頭辞を削除する) ことを明らかにしています。
私たちの考えがより良く理解され、良い API が作られたら、仕様の提案書を作成し、W3C の Device API グループや WAC および WHATWG などのワーキンググループに提出する予定です。
私たちはこのプロセスを通して、他のブラウザベンダや Web 開発者など、他の興味のある団体と接触をします。これは、通常の研究の一環であり、API を良い API にするための活動です。
Mozilla は、常にオープン Web を保つ、良いスチュワードであり続けます。私たちは、Mozilla 独自の Web プラットフォームを作成することに興味はありません。私たちは、オープン Web プラットフォームを前進させることに興味があるのです。
高レベル vs. 低レベル
API 設計でよく問題になることの一つに、高レベルの API と低レベルの API のどちらを作るべきかということがあります。例えば、低レベルの USB API なのかカメラ向けの高レベルの API なのか?
これは、どちらにも長所と短所があります。高レベルの場合は、私たちが、より開発者に親切な API を作れることを意味します。また、ページが予期しない USB コマンドを発行しないようにできるため、より良いセキュリティモデルを提供することもできます。また、ユーザの許可なしにプライバシーに敏感でないアクセスも提供できます。しかし、高レベルの API は、開発者が、私たちがサポートを追加した種類のデバイスにしかアクセスできないことを意味します。そのため、Nerf キャノンの API を追加するまで、開発者にデバイスを操作する手段はありません。
一方で、低レベルの USB API を開示することは、それらの足りない API を私たちが追加する必要が無く、接続された任意の USB デバイスを Web ページが操作できることを意味します。しかしながら、この場合は、開発者が手作業で USB プロトコルの詳細とデバイスごとの違いを調べる必要があります。
私たちが計画しているアプローチ方法は、ユーザにとって最善の、高レベルと低レベルの両方の API を作成し、API を使用する適切な動機を人々に与えることです。しかし、最も重要な点は、低レベル API を早く提供して Mozilla が革新のための致命的な通り道にないことを確かにすることです。時が経てば、理に適った高レベルの API を追加できます。
参加するには
Mozilla において、すべての計画はオープンに行われます。事実、私たちはあなたの助けによって成功することができるのです! 議論を継続するために、すべてのコミュニケーションを新しい mozilla.dev.webapi 議論フォーラムを使って行います。これは、メールやニュース部ループ、 Web ベースの Google グループ UI を通して参加できることを意味します。
メーリングリストの購読: https://lists.mozilla.org/listinfo/dev-webapi
他の手段: http://www.mozilla.org/about/forums/#dev-webapi
私たちは、irc.mozilla.org サイト上の #webapi IRC チャンネルも利用しています。
進捗状況は Wiki ページで確認できます: https://wiki.mozilla.org/WebAPI
Web プラットフォームの次のステージを構築するため、あなたのご参加をお待ちしております!
開発者募集中
編註: 言及するのを忘れていました。私たちは、WebAPI API チームで働くフルタイムのエンジニアも募集しています。募集要項を確認して申し込んでください。
WebAPI の紹介
原文: Introducing WebAPI (on August 23, 2011 by Robert Nyman)
Mozilla は、WebAPI を導入して基本的な HTML5 に対応した携帯を 3 から 6 か月以内に提供したいと考えています。
現在の状況
今日の状況は、オープン Web とネイティブ API の間に明確な区別があり、どのように構築されなければならないかも区別されています。多くの開発者が気付いているように、私たちには、Web ブラウザやオペレーティングシステム、端末にまたがって、特定の端末やベンダだけに依存しない一貫した API が必要です。私たちは、Web を次のステップへ進める手段を必要としています。
WebAPI とは何か?
WebAPI は、Mozilla による活動であり、オペレーティングシステムに依らずに、すべての Web ブラウザで動作する一貫した API 提供して、ブラウザや端末の間の溝を埋めます。仕様のドラフトと実装のプロトタイプを用意し、標準化のためにそれらを W3C に提出する予定です。ここでは、セキュリティはとても重要な要因です。これは、既存のセキュリティ基準 (Geolocation 機能のように、ユーザに許可を求めるなど) を混ぜ合わせたものになるか、セキュリティを確保する新しい代替機能になるでしょう。
直近のタイムフレームでは、次の API を構築しようとしています:
- ダイヤル: Telephony と Messaging API, Contacts API
- アドレス帳: Contacts API
- SMS: Telephony と Messaging API, Contacts API
- 時計
- カメラ: Camera API, Filesystem API
- ギャラリー: Filesystem API (FileReader と FileWriter を結合したものになるでしょう)
- 電卓
- 設定: Device Status API, Settings API
- ゲーム: Accelerometer API, Mouse Lock API
- 地図: Geolocation API, Contacts API
協力するには
すばらしい意見を持つ数多くの有能な人々がいることを私たちは知っています。ぜひ、次のページやサイトを通して協力してください:
- WebAPI プロジェクトページ の情報を追う。
- WebAPI メーリングリスト に参加する。
- IRC: irc.mozilla.org の #webapi ルーム。
- bug 67392 のバグから始め、助けが必要な依存関係にあるバグを見つける。
開発者の雇用
私たちは、Web API のために働く、数名のフルタイムのエンジニアを雇用します。募集要項を読んで応募してください。