Mozillaは、Add-ons in 2017 | Mozilla Add-ons Blogにおいて、Firefox 57のリリース（2017年11月28日：米国時間）に伴い、デスクトップ版ではWebExtensionsベースの拡張機能だけを読み込む措置を執る旨を明らかにした。XUL／XPCOMベースやAdd-on SDKベースの拡張機能（レガシー拡張機能）は、一切利用できなくなる。この措置を確実なものとするため、Mozilla Add-ons（AMO）では、Firefox 53のリリース（2017年4月18日：米国時間）に伴い、新規の拡張機能を登録する場合にWebExtensionsベースでないと受け付けなくなる。 現時点でのスケジュールは、Add-ons/2017 - MozillaWikiに詳しい。それによれば、Firefox 53のリリース時点で具体的に実施される措置は、AMOに

Chromatic Pixel『Sketch Day』でStephen Horlander氏がFirefoxのUIに関する新たなスケッチを公開している。以前『方向性を定めつつあるFirefox 3.7/4.0の新UI』で紹介した内容とはやや異なっており、興味深い。 これまでの計画では、Windows版のFirefox 3.7からメニューバーが省かれる代わりに、Internet Explorerと同じように「ページ」と「ツール」のボタンが設けられ、従来のメニューは整理されてどちらかに収まるはずだった。ところが、今回のスケッチでは、メニューがグループごとに階層化され、1つのボタンから呼び出す方式になっている。 そのボタンは、戻る／進むのボタンの左隣に置かれ、明らかにFirefoxのアイコンをかたどっている。ここで思い出されるのは、Alex Faaborg氏が「ツール」を「Firefox」と呼ん

Boom Swagger Boom『64-bit Firefox for Mac OS X Up and Running』によれば、Mac OS Xの64bit環境でFirefoxの開発版（Minefield/3.7a1pre）が動作するようになったようだ。先ごろリリースされたMac OS X 10.6 Snow Leopardは、64bit対応が大きく進んでおり、Firefoxとしても対処が求められていたといえよう。今回の成功は、その第一歩として意義がある。 重大な問題がなお残っているため、現時点でのビルドの公開は控えるとのこと。また、今後さらに64bit版に必要なパッチをチェックインし、たくさんのコードを書き換えねばならないそうだ。とはいえ、Firefox 3.7がMac OS X 10.4のサポートを外すとなると、代わりに10.6の64bit環境をサポートすべきとの声が強まることが考

Firefox 3.5のアイコン改訂に携わったデザイナーのStephen Horlander氏いわく、現行のWindows版Firefoxのデザインにはいろいろ問題があるという。たとえば、Aero Glassへの対応は最小限にとどまっており、メインツールバーのアイコンには一貫性がなく、タイトルバーからコンテンツ表示領域までの幅が大きくて、その中にたくさんの要素がゴチャゴチャと並んでいる。 Horlander氏を中心に、FirefoxのUIデザイナーであるAlex Faaborg氏とAlexander Limi氏の両名が加わり、Windows版のUIを見直そうというのが、Firefox Sprintsの一環となるプロジェクト、『Windows Theme Revamp』だ。主要メンバーが集まっているだけでなく、Firefox Sprints自体、成果が出ればそのまま本体に取り込む位置づけなの

これまでプレビュー版が公開されてきたUbiquity 0.5だが、もうすぐ正式版がリリースされるようだ。それに合わせて、Ubiquity開発者で新パーサを担当されたmitchoさんが、日本語による解説動画を公開した（『Ubiquity 0.5 日本語紹介ビデオ』）。 Ubiquityに関する動画は、これまでたいてい英語によるものだったので、日本語での解説は貴重だ。当ブログでも引用させていただくことにする。 今夜リリースされる Ubiquity の最新版、0.5 に備えて日本語で Ubiquity のスクリーンキャストを作ってみました。 Ubiquity 0.5 は特に多言語化を重視したリリースで、 Ubiquity 内蔵のコマンドが日本語とデンマーク語で使えるようになっています。是非インストールしてみてください！ Ubiquity 0.5 日本語紹介ビデオ from mitcho on V

MozillaWikiにFirefoxのUIチームが『Perceived Performance』というページを作っている。Firefox.nextの体感速度を引き上げるためのアイデアをまとめたもので、検討中の項目にすぎないとはいえ、どれも採用される可能性のあるものばかりだ。そこで、現在挙がっているアイデアを紹介しておきたい。 読み込まれないページのタイムアウトを早める。 再起動時のデフォルトとして、現在セッションの復元で使用しているメニューを表示させる（メッセージなどは変更して）。 メモリ使用量を監視し、たくさんのタブを開きすぎているときは警告する。 システムトレイに常駐させる機能（Mozilla Suiteにあったものを復活）。 スロバーの動きを速くする。 Mac OS X版のスクロールモデルをWindows版とLinux版にも実装する（Bug 462809）。 リアルタイム戦略ゲーム

Firefoxが他のWebブラウザと差別化を図り、継続使用率（初回起動後30日を経過しても使用を継続しているユーザーの割合）を高めるために、アドオンが不可欠の要素であるという認識は、Mozilla関係者の間で広く共有されつつある。 そして、現在のトレンドは、一定のテーマに沿ってアドオンをグループ化し、セットで提供することによって、ユーザーの利便性を向上させるとともに、多様なアドオンに触れる機会を増やすところにある。 その試みの一つとして、Mozilla Add-ons（AMO）の「Fashion Your Firefox」が挙げられる。ユーザーの関心やWebでの活動をベースに、Mozillaが9つのカテゴリーを設けて、各カテゴリーに3〜8個程度のアドオンを並べたものだ。たとえば、「News Junkie」のカテゴリーには、『Forecastfox』『Wizz RSS News Reader

Mozilla製品全体で1万2千以上、Firefoxだけでも7000以上が存在するといわれるアドオン。そのバリエーションをさらに、はるかに豊かにするべくMozillaが打ち出したのが、Jetpackプロジェクトだ。Mozilla Labsが大々的にアナウンスし、多くのメディアで取り上げられたので、当ブログをお読みのみなさんであれば既にご存じのことと思う。 しかし、Jetpackプロジェクトの成果がFirefox.next（3.5の次のバージョン）に統合されると述べたものが見当たらなかったのは不思議だ。以前『Firefox.nextで「軽い」アドオンが加わりそう』で紹介した「拡張機能 2.0」こそが、今回発表されたJetpackである。したがって、アドオンとしてのJetpack（以下Jetpack）は、About:tabと同様にプロトタイプの側面をもち、Firefox.nextの開発プロセス

ブラウザのユーザーインターフェイス（UI）を表示するプロセスと、Webコンテンツを表示するプロセスを分離する―moz.dev.planningで発表されたのはそんな計画だ。 Mozilla Wikiの『Content Processes』にプランが記載されている。それによると、UIの応答性を高め、安定性を向上させ、マルチコアのマシンでパフォーマンスを上げることが当初の目標だという。目標どおりなら、コンテンツの表示でビジー状態になってもメニューを開けるとか、クラッシュが起きてもプログラム自体は生きている場合があるとかいったことが実現する。また、最近はマルチコアのPCが大半だし、OSもマルチコアをサポートしているから、多くのユーザーがパフォーマンスアップの恩恵を受けられるだろう。 計画は4つのフェーズに分けられているが、フェーズ1のゴールが2009年7月15日、フェーズ2のゴールが2009年1

最近GoogleからMozillaに移籍し、FirefoxのUIチームに所属するAlexander Limi氏が、「The future of tabs」というブレインストーミング・セッションへの参加を関係者に呼びかけている。 そこでの問題意識は、たくさんのページで同時に作業するための手段としてタブを使うのは制約が大きくなってきている、というものだ。いかにしてこの問題に対処するかを考えようというのがセッションの主旨である。 ささやかな動きではあるが、FirefoxのUIチームに所属する人物が旗を振っている点に意義がある。Limi氏のコンセプトは『Firefox.nextでタブをサイド側へ』で扱った内容と通じるものがあり、Mozilla LabsのAza Raskin氏の個人的なアイデアという段階から、実現に向けて一歩前進したように見える。

Mozilla CorporationのJosh Aas氏（Gecko開発チーム所属）がmozilla.dev.planningに『Mac OS X 10.4 Support in Gecko 1.9.2 (Round 2)』というスレッドを立てた。同氏は、その中でMac OS X 10.4（以下10.4）をGecko 1.9.2のサポート対象から外すべきと主張している。 Gecko 1.9.2はFirefox.next（Firefox 3.5の次のバージョン）の基盤となるレンダリングエンジンである。したがって、この主張はFirefox.nextのサポートに関して述べているに等しい。既報のとおりFirefox.nextはWindowsについてXP SP2以降をサポートすることにし、XP SP1／無印およびWindows 2000のサポートを外す方向で議論が進められているが、Mac OSでも

Firefox 3.5は、バックエンドに当たるGecko 1.9.1の開発が遅れる一方、それ以外のフロントエンド部分では順調にBlockerバグが潰されている。Beta 4の投入に伴うスケジュール変更により、開発チームの一部には余裕すら生まれてきた。 そこで、Beta 4に間に合うようにフロントエンドの機能を追加しようという試みが"Code Sprints"である。短距離走のように全力疾走で必要なデザインやコードを構築していくイメージだ。内容は雑多で、新しく企画されたものもあれば、Beta 2前にいったん切られたものが復活したケースもみられる。 小幅な変更ではあるが、成果が出た場合はFirefox 3.5に確実に取り込まれる点が大きい。WHATWG 5のlocalStorageを実装するかどうかで揉めているのと比べると、扱いの差は明らかだ。なお、Beta 4に間に合わなければFirefox

Firefox.next（3.5の次のバージョンを便宜上こう呼ぶ）では、新規タブを開いたときに、空白ページではなく有用なタスクを追加したページを開くようにしようという計画がある（『Firefox 3.2のタブ機能をさわりだけ』参照）。Mozilla Labsは、これまで温めてきたコンセプトを具体化する実験的なアドオンを公開した。ただ、利用にはFirefox 3.1のβ版が必要だ。 実際に導入してみて気づいたことも含め、その機能について簡単に紹介しよう。 Quick-access Bar 以前"Quick-access Strip"と呼ばれていたものだが、画面右端にサムネイルが縦に並ぶことから、バーに改称された。なぜ右端なのかといえば、ユーザーの中心視覚からあえて外れた場所に置くことで、操作の邪魔にならないようにするためである。 サムネイルは7つあり、最初の時点で自動的にWebページにアクセ

気が早すぎるのはわかっている。採用が決まるのはずっと先のことだ。重々承知のうえで、Firefox 3.2（この名称も仮のもの）に追加される三つのタブ機能について、メモしておく。いちおう、どれも根拠はある。 タブプレビューパネル 3.1では完成度が不十分として外されてしまった機能である。タブバー右端にある「タブの一覧表示」でパネルが表示され、サムネイル形式でプレビュー画面が並ぶ。一覧から不要なタブを削除できるほか、検索でタブを絞り込むことも可能だ。また、［Ctrl］＋［Tab］キーを押すと帯状のパネルが表示され、プレビューを確認しながらタブを切り替えられる。 開発総責任者自ら新しいデザインを提案しており、実際その案に沿った開発が進められている。Firefox 3.2でほぼ採用されるとみていいだろう。 タブバーのツールバー化 3.1でタブバーが常に表示されるようになったことにともない、この機能

Firefox 3.1では、最新の高速化技術が惜しげもなく投入され、現行のFirefox 3.0.xから体感できるレベルでスピードアップが図られている。今回はその主要な技術を紹介する。 TraceMonkey TraceMonkeyは、FirefoxのJavaScriptエンジンであるSpiderMonkeyを拡張する技術で、Just-In-Time (JIT) コンパイラという機能によって、JavaScriptの実行速度を大幅にアップさせるものだ。最近では、GmailやGoogleマップのようなJavaScriptを多用するWebサービスが続々と登場しているため、この技術のもつ意義は大きい。コンテンツの表示が目に見えて速くなるのだから。 元になったのは、カリフォルニア大学アーバイン校（UC Irvine）で開発された"Trace Trees"という技術である。もともとMozillaでは、