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

原文:Windows on ARM Users Need Browser Choice Too
過去8年間、ユーザーと開発者は快適なデジタルライフを過ごすことのできるように、ブラウザの選択肢を与える Windows プラットフォームを楽しんできました。これは常にそうであったわけではありません。 Firefox  が2004年に登場する前、ブラウザはただ1つ Windows – Internet Explorer のみでした。2005年から2009年にかけては、ただ IE と Firefox だけが Windows プラットフォームにおいて意味のあるシェアを築いていました。選択肢はさらに Chrome の登場に伴って増加し、今日ユーザーは様々なブラウザを選択することができます。 かつてそのような状況があったことを想像するのは難しいこととなりました。不幸なことに、 ARM 版 Windows の迫るリリースとマイクロソフトの Windows 8 Metro に対するブラウザの実践は、ユーザーと開発者にブラウザ選択の自由が与えられない、招かれざるデジタル暗黒時代への回帰を示しています。

Firefox学生マーケティングチーム（以下　学生マーケ）主催の勉強会を行い
「Add-Onは使っているけど、Add-Onの開発は未経験。興味を持っているけど、どうしたらいいかわからない！」
そんな学生を対象としたAdd-On勉強会を学生マーケで開き、少しでもFirefoxへの興味を持ってもらいたい。
勉強会を広く開催するにあたってまずは、テストとして、学生マーケの友人等を招待し、勉強会を開催しました。

＜趣旨＞
Add-On開発初心者に向けて、開発環境の構築～実際に自由な発想でAdd-Onを作ってみる。

講師：EnsekiTT あっきー
参加者：５人
お持ちいただいたもの：ノートPC持参

Twitter:#gakumoz

まずは講師のEnsekiTT君から、環境設定について。

メンバーが作成したハンドアウトが役立ちました。

参加者もJS初心者～Python,Rubyでの開発経験者まで様々でしたが、実際に導入が
終わって開発の時間には、黙々とコーディングしたり、講師に質問したり。

実際に作成された、Add-On達

小川さん
名前：わさびちゃん
概要：アドオンバーのアイコンをクリックするとわさびちゃんが表示されるアドオン

伊納さん
ハンドルネーム：legokichi
名前：ネガポジ反転
概要：ページを問答無用でネガポジ反転します

野田さん
名前：click 2 play mod
概要：click to play使用時にブロックした要素名を表示するアドオン

EnsekiTT
名前：dragANDtweet
概要：Webページ上で気に入ったフレーズをドラッグ＆ツイートするアドオン
フレーズが長い場合の短縮と任意のハッシュタグと、フレーズ位置にフォーカスする機能をつけたいところ

最後は、アンケートを書いていただき、集合写真を撮って終了しました。

＜アンケート集計結果＞
普段使う言語:JS 2,C 2,C++ 2,C#,php,Ruby,あまり開発しない 2
難しかった：適度だった＝2:3
興味分野：WebDev,App開発

＜反省点＞
・時間はもう少し長め５時間程度？
・比較的簡単なアイデアやソースのサンプル・見た目におもしろいアドオン等　のサンプルの用意
・講師１人あたま２人がベスト（３人が限界？）
・成果のアウトプットの仕方

もう一度、もう少しオープンに人を募って開催してみて、そのフィードバックを踏まえ
実際に開催していこうという予定となっております。

講師や、協力してくださる方も絶賛募集中です！
お問い合わせは、こちらまでお願いいたします。
campusreps@mozilla-japan.org

今回の資料

学生アドオン勉強会テキスト

作成:あっきー

作成EnsekiTT

[この記事はThe Denのブログ記事 Happy Birthday Firefox! の訳です。
2012年11月9日は2004年にリリースされたFirefoxの8歳の誕生日です！]

(画像: フォクすけ at Facebook )

お誕生日おめでとう、Firefox！

今から8年前の今日に、Firefox 1.0はリリースされました。 — そして今では世界中のとても多くの人々に選ばれているブラウザになりました。お祝いするために、私達はあなたに認識していただきたいのです — 私達はWebが全ての人に対してオープンであり続けるために、そしてFirefoxを最も安全で、最も速く、最もセキュアなブラウザにできるように努めているからだということを。ありがとう！

[これは Mozilla Add-ons Blog の記事 Add-on Compatibility for Firefox 17 の抄訳です]

Firefox 17 が 11 月 20 日の日本時間深夜にリリースされます。Firefox 17 の変更点でアドオンの互換性に影響を及ぼす可能性のあるものを以下にまとめました。Firefox 17 for Developers により詳しい情報が載っていますので、こちらも併せてご覧ください。

General

• __exposedProps__ が default-safe に変更されました。この変更に関してはしばらく議論が行われてきました。詳しくは アドオンのオブジェクトをコンテンツへ安全に露呈させる方法 をご覧ください。
• enablePrivilege が廃止されました。この機能はしばらく前に廃止予定・非推奨となり、Firefox から徐々にコードが削除されてきました。もはや期待通りには動作しませんので、もし使用している場合は代替策を検討してください。
• XHR.onuploadprogress が削除されました。このプロパティは非標準であったため削除されました。代わりの方法は XMLHttpRequest のドキュメントをご覧ください。
• javascript.options.xml.content が初期設定で無効化されました。これによってコンテンツの E4X が完全に無効化されることになります。E4X も削除されることが決まっており、使用すべきではありません。
• ソースの保存による関数オブジェクトの toString が実装されました。もしアドオンのコードで eval や function.toString を使って既存の関数を上書きしている場合、この変更によって動作しなくなる可能性が高いでしょう。いつものことですが、そうした方法はできる限り避けることを推奨します。
• 署名済み拡張機能の証明書が初回起動時のみ検証されるようになりました。デジタル署名されている拡張機能の証明書は、従来 Firefox の起動時に毎回検証されていましたが、今後はインストール時に 1 回だけ検証されるようになります。
• onbeforeunload、onunload、onpagehide でダイアログを表示できなくなりました。alert、confirm、prompt の使用が制限されます。Web サイトがユーザをそのページに無理矢理とどまらせようとする場合があり、そうした状況を防ぐための措置です。
• 存在しない WeakMap キーを追加しようとしたときに例外が投げられるようになりました。これは WeakMap を使っている場合のみ影響します。

XPCOM

• 新しい nsIFilePicker::ShowAsync メソッドが追加されました。nsIFilePicker::Show は廃止予定となったため、代わりにこの非同期メソッドを使用してください。
• checkLoadURI() と checkLoadURIStr() が削除されました。代わりに checkLoadURIWithPrincipal() を使用してください。
• メッセージマネージャがセンダーとブロードキャスターに分離されました。これによってメッセージの送受信方法が変わり、nsIChromeFrameMessageManager インタフェースは削除されました。
• JavaScript-global-constructor オブジェクトがウィンドウ参照を渡されるようになりました。あなたのアドオンでグローバルコンストラクタを登録し、なおかつ引数を取っている場合は、このバグに目を通した方が良いでしょう。
• GetCodebasePrincipal の呼び出し元が正しい data jar を使うよう更新されました。この修正によって getCodebasePrincipal の関数名が一時的に変更されたため、ベータ期間中に一部のアドオンが動作しなくなりました。変更は取り消されたので、コードに変更を加える必要はなくなりました。

新機能

• トップレベル XUL ウィンドウがサイズ制限に対応しました。これによって、トップレベルの XUL ウィンドウでも minwidth、minheight、maxwidth、maxheight が使えるようになります。
• サイトアイコン (favicon) から最も代表的な色を抽出する機能が実装されました。これは面白く、おそらく役に立つものと思われます。新しいインタフェースは mozIColorAnalyzer といいます。

その他、Firefox 16 で判明した 読み込みハンドラの問題 が Firefox 17 で修正されています。

この一覧に載っていない変更点や間違いを見つけたらコメント欄でお知らせください。もしあなたのアドオンが Firefox 17 で動かなくなった場合は、筆者の方でも調査したいと思います。

AMO に登録されているアドオンの 自動互換性テストと対応バージョンの更新 は来週行われますので、後日メールをチェックしてみてください。

原文: HTML5 mythbusting on November 1, 2012 by Chris Heilmann

HTML5 の実用性を巡って昨今繰り広げられている議論は、多くの間違った憶測に基づいています。それは、一度言われてからずっと繰り返されている、そして多くの場合正しいのかどうかまったく検証されていない、HTML5 に関する誤解につながっています。

HTML5 は遅い？

HTML5 の問題について話したがる人たちが必ず主張することと言えばパフォーマンスです。ここでの一番の問題は、そうした比較のほとんどがリンゴとナシの比較に過ぎないという事実を見落としている点です。

HTML5 アプリとネイティブアプリのパフォーマンスを比較することは、オーダースーツと既製品のスーツを比較するようなものです。もちろんオーダースーツは手袋のように体になじみ、見た目は素晴らしいですが、もし後でそれを売りたい、あるいは誰かに譲りたいと思っても、残念ながら難しいでしょう。他の人にも同じようになじむとは限らないからです。

ネイティブアプリとはまさにそういうもので、特定の環境と目的のために開発、最適化され、その状態に固定されるものなのです。これに関しては後ほど詳しく述べたいと思います。

一方 HTML5 は、その定義にも書かれているように、環境、ディスプレイ、あるいは技術とは独立して動作する Web 技術です。Web 上で成功するため柔軟性を最大限に備えています。そして Web もその定義通り解釈すれば、すべての人のために存在するのであって、非常に高価なハードウェアを購入する余裕があり一企業によって管理された固定環境に縛られることもいとわない、少数の恵まれた人たちのためだけのものではありません。

ネイティブアプリは端末やプラットフォームごとに一から開発しなければなりませんが、HTML5 アプリなら、スマートフォンからタブレット、デスクトップまで、ひとつの製品で対応できます。また、想定画面サイズや機能を固定せずユーザ環境をチェックして適宜対応することも可能であり、新しい携帯電話を買えない人たちを閉め出さなくても、より高速な最新端末を使用している人たちのユーザ体験を向上させられます。

一方でネイティブアプリは、多くの場合アップグレードを求めてきます。エンドユーザは新たなハードウェアの購入を強いられ、さもなければ製品自体を手に入れられません。柔軟性という観点から見れば HTML5 アプリは見事な役割を果たしており、逆にネイティブアプリはユーザを特定のハードウェアに依存させ、購入する余裕のない、あるいはあえて避けたいアップグレードが提供された場合、行き場を失わせることになります。その最たる例は、最近話題となった iOS 上での Apple 独自地図アプリへの移行です。多くのユーザが不満を抱え Google マップを使い続けたいと思っていますが、それは不可能です。

HexGL — WebGL ベースのレースゲーム

HTML5 は、デスクトップではパフォーマンスの点でネイティブアプリに十分勝る能力を備えており、スクロールのパフォーマンス、動画の即時解析・編集、さらには 超高フレームレートでのフル 3D ゲームの実行 や 高速レースゲーム の実現まで見る限り、パフォーマンスに関する問題がどこにあるのか自問しなくてはなりません。

その答えはハードウェアアクセスです。HTML5 アプリは、iOS や Android 向けに開発されたモバイルハードウェア上では二級市民として扱われており、最高のパフォーマンスを得られる部分にはアクセスできません。iOS の Web ビューは、ネイティブアプリと変わらない原理を用いているにもかかわらず、同じように高速に動作することを OS によって妨げられています。Android では、標準ブラウザがモタモタしているのに比べて、Chrome も Firefox もブラウザがどれほど高速に動作するかを証明しています。

Android の標準ブラウザは、長期間改良されることなく Web の進化を妨げる脅威となっていた 90 年代の Internet Explorer を思い起こさせます。思えば、それこそまさに Mozilla と Firefox が誕生したきっかけでした。

要するに HTML5 は砂利道でも運転できるよう設計された F1 レースカーですが、今はまだ回避するすべのない多くの重荷を OS によって課されている状態と言えるでしょう。

HTML5 はカネにならない？

HTML5 はオープンな Web 技術をベースとした技術の集合体です。HTML5 はマネタイズモデルを持ち合わせていないという見方は、Web がマネタイズできないというのと同じことです (広告で支えられているニュースサイトにそうした論調の記事が載った場合、特に皮肉っぽく聞こえます)。

閉鎖的なアプリマーケットは、一見すれば自社製品を売るのに簡単な方法と思われますが、その成功には多くの誇張表現があり、実際のところ閉鎖的なマーケットでひとつのアプリを売って生計を立てられている開発者はほんの一握りです。アプリマーケットでの発見性や検索性がますます低下していく中、素早く見つけられること、そしてマーケット内の検索結果で 1 ページ目に載ることが最重要課題となり、多くの開発者はひとつのアプリを集中して開発する代わりに同じようなアプリを量産しています (例えば、話す犬、話す猫、話すロバ… といった具合で)。

ネイティブアプリを揃えた閉鎖的なマーケットが開発者にとって実際にデメリットであると言えるのはこのためです。アプリは Web 上での住所 (URL) も持たず、マーケットの外から見つけることはできません。作ったアプリはひとつずつ別々のマーケットに手作業で登録する必要があり、またそれぞれの審査と登録のプロセスに従わなければならず、製品の機能停止を避けてアプリを簡単に更新する方法はありません。

HTML5 アプリは Web 上にあって URL を持ち、Adobe PhoneGap Build のようなツールでパッケージ化すれば iOS や Android 向けのネイティブアプリに変換することも可能です。その逆は不可能です。

長期的な視点に立った場合、開発者にとってより最適な戦略は何かという問題が提起されるでしょう。マーケット側の独断でいつでも製品を取り下げられる可能性のある特定の閉鎖的な環境に賭けるか、あるいは世界的でオープンな配布ネットワークを通じてアプリを提供しつつ閉鎖的なマーケットもカバーするか、です。

Android と iOS のマーケットにある多くのアプリは実際、HTML5 で書かれ PhoneGap で変換されたものですし、Financial Times が自社アプリを HTML5 で開発し、ネイティブアプリより多くの収益を上げているというニュースは大きな話題となりました。最近でも New York Times が同様に Web アプリ化を行うと発表しています。

HTML5 はオフラインで使えない？

HTML5 は Web 技術の集合体であることから、使用中ずっとオンラインでいなければならないと思い込んでいる人たちがいるようですが、そうした考えは完全に間違っています。HTML5 アプリでは、コンテンツをオフラインに保存しておく方法がいくつもあります。最も簡単な方法は、すべてのモダンブラウザが対応している Web Storage API です (ただし特別な例として Opera mini は除きます。このブラウザはクラウドサービスを通じてコンテンツを受信しており、独自のストレージツールを備えています)。また、Internet Explorer 以外の全ブラウザが対応している アプリケーションキャッシュ を使えば、アプリ自体をオフラインに保存しておけます。Web Storage API が提供する機能以上に複雑なデータを保存したいときは (Chrome と Firefox が対応している) IndexedDB か (iOS と Safari が対応している) WebSQL を使用できます。Lawnchair のような、互換性の問題を回避し開発者の使い勝手を高めるライブラリも公開されています。

HTML5 には開発環境がない？

よく言われる懸念のひとつに、HTML5 には開発者向けのツールが不足しているという点が挙げられます。不思議なことに、そのような声を開発者自身から聞くことはありませんが、自社の開発者に効率を上げる方法を考えさせる代わりにソフトウェアを購入することで解決したいと考える経営陣などからはそうした意見も耳にします。

HTML5 開発は基本的には Web 開発であり、驚くほど実用的な開発環境が整っています。繰り返しになりますが、本質的な問題は Web にまつわる誤解です。どこでもまったく同じに見えて同じように動作する製品を開発するのではありません。それは Web 本来の強みを奪おうとする考え方です。真の Web アプリとは、どのような環境でも動作しつつ、主要なプラットフォームではより優れたパフォーマンスを発揮する製品です。そのため、開発環境は特定の万能な製品ではなく一連のツールということになります。何を開発するかによって、その中からいくつでも選べるのです。もちろんひとつだけでも構いませんが。

Web がメディアとして大きな成功を納めているのは、開発者でなくても自由にコンテンツを公開できるためです。ブログプラットフォーム、CMS、あるいは OS に付属しているシンプルなテキストエディタを使って HTML ページを書き始められます。開発者としてのキャリアを積むにつれ、気に入ったツールをたくさん見つけ、それらに慣れ効率性を高めていくことでしょうが、ひとつの定番ツールというのは存在しません。Visual Studio や Eclipse のような統合開発環境 (IDE) を好む開発者もいますし、Dreamweaver のような WYSIWYG スタイルのエディタを求める人たちもいます。ただ Web 開発者の多くはテキストエディタかコマンドラインを使っているでしょう。秀丸、Jedit から、Vim、Emacs に至るまで、それらはすべて実用的なツールであり、実際に多くの開発者が Web コンテンツを開発するため日常的に使用しています。

デバッグやテストについても、最近ではツールが充実してきています。私たちが作り、エンドユーザ必ず目にするソフトウェア、つまり Web ブラウザも、デバッグ環境やテスト環境を兼ねているからです。変更箇所をリアルタイムで確認し直接編集可能な Firebug アドオン を追加できる Firefox をはじめ、Opera には Dragonfly、Safari や Chrome には開発ツールが付属しており、今やすべてのブラウザに開発者用の機能が多数搭載されています。Firefox の新しい開発ツール はさらに進んでおり、単なるデバッグ環境を超え、それ自体開発者が自分のニーズに応じて拡張可能なツール群として設計されています。

今では リモートデバッガ機能 まで提供されています。つまり開発者は、自分の開発マシン上で、モバイル端末上で動作しているアプリケーションに直接変更を加えられます。スマートフォン向けに開発し、それを端末に転送して、インストールし、テストし、間違いを見つけて… といった作業の繰り返しはもう不要です。これにより開発期間が劇的に短縮されるでしょう。

Firefox のリモートデバッガ機能

視覚的な環境を求める開発者が増える中、Adobe が最近 Edge スイート を公開しました。これは WYSIWYG スタイルによる HTML5 アプリ開発を実現するツールとサービス群で、例えば Photoshop からドラッグ＆ドロップで画像を配置するといったことも可能です。Edge Inspect は複数端末での同時テストを効率化し、PhoneGap Build を使えば HTML5 アプリを iOS や Android 向けのネイティブアプリとしてパッケージできます。

配布とパッケージに関して言えば、Google がつい最近 Yeoman プロジェクトを公開しました。これは、Web 開発者が Web 製品をアプリケーションとしてパッケージ、配布する手間を大幅に削減するもので、高速な動作を実現する機能まですべて備えています。

結局のところ、HTML5 はプラットフォーム中立であることから、決まった開発環境というのはありません。それが Web というものであり、自分に最も合ったツールを選べば良いのです。

ネイティブアプリにできず HTML5 にできること

HTML5 にまつわる誤解の多くは、突き詰めると、あるプラットフォームに特化して開発されテストされたアプリと、そのプラットフォームにも対応しているアプリとの比較だったという点に集約されるでしょう。競艇用モーターボートとホバークラフトの速度比較のように、同じ予測可能な結果になるのと似たようなものです。より興味深い質問を挙げるとすれば、開発者やエンドユーザにとって HTML5 を素晴らしいものにしている要素は何か、つまりネイティブアプリができないこと、あるいはしないことは何かということです。

• 一度書けばどこでも動く — HTML5 アプリは、ブラウザ内、タブレット上、そしてデスクトップで実行でき、iOS や Android に対応するネイティブコードへ変換することも可能です。その逆は不可能です。
• Web を通じた共有 — HTML5 アプリは URL を持っていることから、Web を通じて共有したり Web 検索で発見できたりします。マーケットに足を運んで、混み合い限られたスペースの中から探す必要はありません。一方、他の Web コンテンツを宣伝するのと同じ方法がここでは使えます。より多くの人たちがあなたのアプリを気に入ってリンクすれば、それに伴って Web 検索の順位が上がり見つけやすくなるでしょう。
• 合意されたマルチベンダー標準に基づく技術 — HTML5 は現在の Web を形成している様々な企業の共同成果であり、開発者が不満を持つ方向へ傾く可能性のある、単独企業によって規定された仕様ではありません。
• 大勢の開発者 — 近年 Web 開発に何らかの形で携わった人たちは誰でもアプリを開発する準備ができていると言えます。もはや小さく専門的なコミュニティではありません。
• 消費ツールと開発ツールは同じもの — まず最初に必要なものは、テキストエディタとブラウザだけです。
• 小規模で部分的な更新が可能 — ネイティブアプリを更新するには、アプリケーション全体を再度ダウンロードする必要があります (例えば Angry Birds の新バージョンは 23 MB あり、それを 3G 接続でダウンロードする人もいます)。HTML5 アプリならデータを必要なだけダウンロードしオフラインに保存することができ、その上更新もはるかに簡単です。
• シンプルな機能のアップグレード — ネイティブアプリはインストール時にハードウェアへのアクセス許可を求め、後からそれを変更することができません。あらゆるアプリがあらかじめ様々なアクセス許可を求めてくるのはそのためです (これはもちろんプライバシーやセキュリティに関わるリスクとなります)。HTML5 アプリは、ハードウェアやデータへのアクセス許可を、必要なときに更新や再インストールなしに求めることが可能です。
• 様々な環境への適応 — HTML5 アプリは、レスポンシブデザインを使って、コードに変更を加えることなく環境ごとに最適なユーザ体験を提供できます。デスクトップからスマートフォンへ、あるいはタブレットへ、それぞれに別々のアプリをインストールすることなくスムーズに移動できます。

ネイティブアプリでこうしたことが可能か考えてみてください。

ハードウェアからの締め出しを破り、マネタイズを簡単にするために

HTML5 が開発者にとって未だ確実な選択肢となっていない理由は、上述したハードウェアからの締め出しという問題によるところが大きいでしょう。iOS 端末では WebKit 以外のエンジンを搭載したブラウザの提供が許可されておらず、カメラやアドレス帳、バイブレーション、通話、テキストメッセージへのアクセスも HTML5 に許可されていません。それらはすべて、開発者にとってモバイル端末を面白いものにし、アプリにとって必須の機能と言えます。

このような問題を解決するため、Mozilla はいくつかの企業と共同で一連の API を開発し、標準化された方法による端末へのアクセス手段を定義してきました。これが Web API と呼ばれるものです。この API を使用すれば、あらゆるブラウザがハードウェアへのアクセス許可を安全な方法で取得することが可能となり、締め出しを破れます。

Web API を実装した最初の環境が Firefox OS で、来年には端末が出荷される予定です。Firefox OS では、ネイティブアプリと同じようにハードウェアへのアクセス権を持った HTML5 アプリを提供できます。開発者はハードウェアへ直接アクセスすることが可能であり、そのためより高速で、また重要なことにより小さなアプリを開発できるのです。エンドユーザにとってのメリットは端末が非常に安くなるということで、Firefox OS は、例えば最新の Android へアップグレードできない非常に低スペックのハードウェアでも動作します。

マネタイズに関して言えば、Mozilla は独自の HTML5 アプリ向けマーケットプレイス を開設しようと取り組んでいます。ここでは単に HTML5 アプリを登録できるだけでなく、単純な Web 検索でも発見可能となります。エンドユーザがアプリを簡単に購入できるよう、モバイルキャリアと提携し通話料と併せて請求する仕組みも整えようとしています。これによって、クレジットカードを持たないユーザでもアプリを購入し、モバイル Web 革命に参加できます。

HTML5 の実用性はどのぐらいか？

全体的に見れば HTML5 は急速に成長しており、アプリ開発者にとって非常に面白く信頼できるプラットフォームとなりつつあります。取り除かなければならない大きな障壁はハードウェアアクセスですが、Web API の標準化作業や PhoneGap のようなツールによって、従来考えられていたよりはるかに問題は小さくなってきています。

上で述べたネイティブアプリを超える HTML5 のメリットは、プラットフォームごとに別々のコードを書く時間を費やす代わりに、HTML5 アプリ開発に取り掛かるだけの十分な理由となるはずです。たとえ対応したいのがひとつの特定のプラットフォームだけで、HTML5 を選択する必要がなくても、そうした決定について HTML5 の問題のせいにするのは的外れでしょう。

HTML5 開発はプラットフォームやブラウザとは独立したものです。そうした考えを受け入れられない場合、その可能性に自ら制約を課していることになります。歴史的に、閉鎖的なプラットフォームは浮かんでは消えてきましたが、Web は今でも力強さを増しながら、世界中の膨大な数のユーザにリーチすること、そして誰かに許可を求めたり複雑な開発環境をインストールすることなく開発を始めることを可能にしています。これこそ多くの人たちが Web 上で何かを始めてきた大きな理由であり、今もそれは変わりません。そして Web では誰も閉め出されることはありません。さあ、あなたも HTML5 アプリ開発に挑戦してみましょう。

原文:Knowing about choice matters, when millions are asked to select a browser | The Mozilla Blog

※この記事は既に内容が古く、記事中の役職等が現在のそれと違う場合があります。

※本記事で触れている Open To Choice は既に終了したキャンペーンです。

今週、 Mozilla は Open To Choice キャンペーンを開始しました。欧州の web ユーザーの間で、インターネットにアクセスするソフトウェアやサービスについて正しく情報を伝えられたうえで選択することがいかに重要か、その認知を高めることを目標としています。このキャンペーンは32か国で約2億の人々が、彼らのオンライン体験の代理人の役割を果たす web ブラウザの積極的な選択を求められるようになる(訳注、 BrowserChoice のリリース)のと同時にスタートします。

Open To Choice は Mozilla CEO の John Lilly と 代表 Mitchell Baker が、欧州委員会とマイクロソフトの生んだ”より多くの人がオンライン上の生活をコントロールすることを支援する重要な指標である”画期的なブラウザ選択画面 Browser Choice に対して送った公開書簡から始まりました。公開書簡はより深い理解、つまり今日のブラウザの決定的な重要性について説明すること、選択肢を与えるだけでなく正しい情報をもとに選択できるように教育を施すことを求めています。

John Lilly が公開書簡となぜブラウザを選択することがそこでま重要なのかについて解説した動画をごらんください (外部サイト、全編英語)

今後数週間は Opentochoice.org はブラウザの基本に関する情報をさらに発信していき、 Web 上の選択肢の重要性について語り合うためのハブとなっていくことでしょう。

ぜひ公開書簡を読んで、 http://www.opentochoice.orgの会話に参加してみてください。

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までに提供することができるでしょう。

[これは Mozilla Add-ons Blog の記事 Possible window load handler failures in Firefox 16 の抄訳です]

アドオンの互換性問題が最近になって Firefox 16 に見つかりました。Firefox 16 だけでなくそれ以上のバージョンにも影響し、現在 Mozilla の開発者が調査を進めています。

その問題とは、多くのアドオンが依存しているウィンドウ読み込みイベントハンドラが特定の状況で呼び出されないというものです。既に分かっていることは、この現象は、ポップアップウィンドウが開かれており、なおかつ新しいウィンドウ内のドメインがそのウィンドウを開いたドメインと異なる場合に限って発生するようです。大半のアドオンのスクリプトは読み込みハンドラの呼び出しに依存していることから、その多くは新たに開かれたポップアップウィンドウでは動作しないという状態になっています。詳しくは Bug 799348 をご覧ください。

今のところ、私たちはこのバグの影響は非常に軽微であると考えています。そのため、予定外の Firefox 16.0.1 を提供するだけの十分な理由がない限り、Firefox 17 まで修正は行いません。もしあなたのアドオンが影響することが分かりましたら、コメント欄でお知らせください。

[訳注: 問題が発生するのは window.addEventListener("load", func, false) のような典型的なコードのようです。原文やバグのコメントによれば、Adblock Plus や InstantFox Quick Search などが影響を受けるとの報告があります]

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