Latest topics 近況報告

ウィンドウにフォーカスするとタブの色が変わる（Colors of tabs is changed when the window is focused/unfocused!） - Jul 07, 2009

Q

The minor bug is the changing of the background color of the tree bar. In the screen shot included you can see that it is light grey. But when I change focus to Firefox the tab becomes dark grey and all the tabs darken too.

（他のバグ報告と併せて）もう1つ些細な問題として、ツリー表示されたタブバーの色が上げられます。このスクリーンショットではタブは明るいグレーで表示されています。しかしFirefoxのウィンドウにフォーカスすると、タブが暗いグレーで表示されるようになり、他のタブの色も暗くなります。

A

Do you talk about the changing of tab colors caused by focusing/unfocusing of Firefox window? Then, it is not a bug, but a design. The "Metal" theme (one of built-in theme of TST) is designed for Mac OS X. In the platform, any window which have no focus is shown with paled colors.

Firefoxのウィンドウにフォーカスしたりフォーカスを外したりした時の色の変化についての指摘であれば、それはバグではなく仕様です。ツリー型タブの組み込みテーマの1つである「Metal」はMac OS X用にデザインされており、Mac OS Xではフォーカスを持たないすべてのウィンドウは薄い色で描画されます。（つまり、その挙動に併せてタブの色が変わるというわけ。）

WindowsやLinuxだと確かに違和感あるか……

Vista-aeroとツリー型タブの共存（Vista-aero theme with Tree Style Tab） - Jul 06, 2009

Q

It seems to collide with a Firefox Theme: Vista-aero. Is there a chance to fix this?

（ツリー型タブは）Vista-aeroというテーマと衝突するようです。この問題は解決されますか？

A

Vista-aero modifies internal structure of Firefox too much, so, it is too hard to make Tree Style Tab compatible with the theme. I cannot take much time for the task. Instead, I recommend you to choose another theme which provides only appearance, not other features including buttons beside tabs.

Vista-aeroはFirefoxの内部構造を激しく変更するので、ツリー型タブをそのテーマと同時に動くように修正するのは非常に困難です。そのための時間を割く事が私にはできません。代わりに、タブの横のボタンなどの余計な機能を提供しない、単に見た目だけを変更するテーマと組み合わせて使う事をお勧めします。

テーマへの特別な対応は、あっさり解決できる場合を除いて、なるべくしない方向です。

タブのフォーカスをホイールスクロールで切り替える（A new option to move focus of tabs by wheel scrolling is required.） - Jul 06, 2009

Q

One of the simplest features that I miss however is the possibility to scroll through the tabs using the mouse wheel. This is soooo convenient, try it out :-) TabKit, for example, includes this one and it adds so much to the browsing experience that I would never want to surf the web without it.

タブの上でホイールをスクロールしてタブのフォーカスを切り替える機能が欲しいです。

A

Sorry, I have no plan adding the feature, because I hope to keep Tree Style Tab as simple as possible. This policy is based on reflection on my past mistakes about a too fat addon, Tabbrowser Extensions. I recommend you to use TST with other tiny addons providing the feature...

ツリー型タブを可能な限りシンプルに保ちたいので、そのような機能を加える予定はありません。このポリシーは、過去の肥大化したアドオン「タブブラウザ拡張」の開発における失敗についての反省に基づいています。私は、そのような機能を提供する他の小さなアドオンと一緒にTSTを使う事をお勧めします。

ツリーに関係ない機能の追加要望には基本的にこう回答してます。

「このツリーを閉じる」（A new button "Close This Tree" is required.） - Jul 06, 2009

Q

One improvement I would like to see is an icon on the tab to close the entire tree, instead of having to right click and select "Close this tree".

メニューから「このツリーを閉じる」を選ぶ代わりに、ツリー全体を閉じるためのボタンが欲しいです。

A

Did you try the action, clicking on "close" button when the tree is collapsed? Closing of the parent tab with collapsed children will close the entire tree by one action.

ツリーを閉じた状態でタブの「閉じる」ボタンをクリックしてみましたか？　この操作でツリー全体を閉じる事ができます。

Q

I have the options set to always have my tabs always expanded. It saves a few clicks... and I have plenty of screen real estate. So my tabs are never collapsed.

私はすべてのツリーを常に展開した状態にする設定にしています。なので、ツリーを閉じる事ができません。

A

Hmm, OK, I realized what you are suffered from. However, I think I shouldn't add new buttons anymore into each tab because there are too less spaces...

If you told about a new toolbar button, then, this will help you:

TreeStyleTabService.removeTabSubTree(gBrowser.selectedTab);

By another addon which provides customizable toolbar buttons or customizable shortcuts, you can do "close this tree" by the code.

タブの中があまりに狭いので、これ以上ボタンを追加するべきではないと私は思います。代わりに、カスタマイズ可能なツールバーボタンやキーボードショートカットを提供する他のアドオンでこのコードを使うと、現在のツリーを閉じる事ができます。

読み返してみるとなんともチンプンカンプンで的外れな回答だと思った。

部分的なサムネイルって便利なんだろうか - Jun 16, 2009

Reinventing tabs for the browser · Alexander Limiに、A full thumbnail screenshot of a page is not really useful in identifying the page, especially if the page is mostly text.（ページ全体のスクリーンショットのサムネイルは、ページを判別するのには実際の所便利ではない。特に、そのページのほとんどがテキストである場合は。）とあったので、試しに情報化タブのサムネイル表示機能について、ページの端から一定のピクセル数の部分を切り出してサムネイルにするモードを加えてみた。

理屈の上では、各Webサイトはページの左上にブランドロゴのようなものを置いている場合が多いから、この方が視認性が高まる、って事らしいんだけど……単純に慣れの問題なのか、あんまり視認性が上がったような気がしない。もしかしたらサムネイルがそもそも小さすぎるからなのかもしれない（32×32程度のサムネイルだったら、全体の縮小だろうが一部の縮小だろうが大して変わらない）。

本当のところを言えば、端から固定で何ピクセルなんていう取り方じゃなくて、人の視覚を引き付ける特徴的な要素がある部分を切り取る形にできれば、それが最良なんだろうけど（そうしないと、例えばこのページだったら左上を切り取ると真っ黒なサムネイルになるけど、全体を引いて見た印象はブルー、というちぐはぐなことになる）……そんな事僕の頭じゃできませんわ。

AMOのコレクション機能を使ってみた - Jun 10, 2009

AMOを見たらリニューアルされてて、好きなアドオンを集めたリストを公開できる「コレクション」という機能が加わってたので、さっそく使ってみた。

PiroがFirefoxで常用してるアドオン :: Firefox Add-ons

デスクトップ百景の時のリストのアップデート版といった感じ。AMO上に無い物を入れられないため、いくつか抜けがある。

アドオン開発用ツール集 :: Firefox Add-ons

デスクトップ百景の時の物のうち、アドオン開発用の物だけ。プラスいくつか。

タブブラウザ拡張3 :: Firefox Add-ons

メタパッケージはAMOに置けないので、作ってみた。

PiroがThunderbirdで常用してるアドオン :: Thunderbird Add-ons

Ubuntu上のThunderbirdで利用してるアドオン。他に自分で作ったパッチも入れている。

リストアップされたアドオンをボタン一発でまとめてインストールできる機能だとばかり思ってたんだけど、そういう機能はなくて、入れたかったらいっこいっこ個別にぽちぽちインストールしないといけない。これは面倒すぎる。なんで一括インストールできるようにしなかったんだ？　方法はいくつかあるだろうに。

nsIHttpProtocolHandlerに対するプロキシとなるXPCOMコンポーネントを実装してみた - Jun 08, 2009

ローカルプロキシっぽいことをローカルプロキシを立てずにやろうとして挫折したことのまとめを書いたら、thorikawaさんが別のアプローチを提示してくださったので、その方向で頑張ってみた。

結論から言うと、URIの置き換え（特定のURIにアクセスしようとした時に、別のURIのリソースの内容を返す）についてはできるようになった。成果はUxU 0.6.0に組み込んである。ただし、他のアドオンとの競合の可能性があるので、初期状態では機能を無効にしてある。

実装がどうなっているかはGlobalService.jsの中のProtocolHandlerProxy、HttpProtocolHandlerProxy、HttpsProtocolHandlerProxyの各クラスを参照のこと。thorikawaさんのエントリに挙げられている課題は、一応解決されているはず。

thorikawaさんによるコードからの違いは以下の点だ。

変更点1：元のコンポーネントが実装しているインターフェースは全部備えることにした

一つは QueryInterfaceの部分で、QueryInterfaceの部分を置換前のXPCOMに丸投げしてしまっているので、その後の個別の処理も全て置換前XPCOMで行われてもよいはずです。だけど実際にはnewURI,newChannelといったメソッドは置換後のXPCOMのものが呼び出されます。

QueryInterface()は、実はメソッドの返り値を見るまでもなく、メソッドを実行した時点でそのラッパーオブジェクト自体が変更される。なので、そのせいじゃないかと思う。例えば

var pref = Cc['@mozilla.org/preferences;1']
            .getService(Ci.nsIPrefBranch);
var value = pref.getBoolPref(...);

このコードは

var pref = Cc['@mozilla.org/preferences;1']
            .getService();
pref.QueryInterface(Ci.nsIPrefBranch);
var value = pref.getBoolPref(...);

と書いてもちゃんと動く。後者のような使い方をされている限りは、QueryInterface()で何を返していようと関係ない、ということではないのかなあ。

C++で書かれたコンポーネントの中ではdo_QueryInterface()という関数？がよく使われているようで、こいつが中で何をやってるのかまでは僕にはよく分かってないけど、上記の例の前者ではなく後者に相当するものなんだったら、引用部のような現象が起こるのではないかと思う。

ということでそういう場合に備えて、ProtocolHandlerProxyクラスは、コンポーネント「{4f47e42e-4d23-4dd3-bfda-eb29255e9ea3}」が備えているすべてのインターフェースを実装しておくようにした。具体的には、nsIHttpProtocolHandler、nsIProtocolHandler、nsIProxiedProtocolHandler、nsIObserver、nsISupports、nsISupportsWeakReferenceの各インターフェース。といっても、やってることとしてはやっぱり単に元のコンポーネントに処理を丸投げしてるだけなんだけど。

変更点2：プロパティとしてアクセスされる情報を、prototypeの方に定義するようにした

またもう一つは、このサンプルでも正常に動作しないサイトがいくつかあること。AJAXを多用しているサイトでも基本的には問題なく動くのですが、たとえばGMailにアクセスするとなぜか簡易版HTMLが表示されてしまいます。もしかすると上記の問題と関連しているのかも知れません。

これは推測だけれども、HTTP_USER_AGENT等が正常に送られなくなっていたせいではないかと思われる。

ちゃんと調べたわけではないんだけど、Webページ内のスクリプトのnavigator.userAgentの値や、HTTPの通信の際に送られるユーザエージェント名の文字列は、コントラクトIDが@mozilla.org/network/protocol;1?name=httpであるコンポーネントがnsIHttpProtocolHandlerインターフェースを通じて返す値を元に生成されているらしい。

然るに、thorikawaさんによるサンプルコードのコンポーネントにはnewChannel()などのメソッドは定義されているけれども、nsIHttpProtocolHandlerが持つはずのuserAgent等のプロパティは定義されていない。XPConnect経由でこのコンポーネントにアクセスすると、undefinedが文字列にキャストされて空文字として返ることになる。その結果、サーバに送られるUA文字列も空っぽになってしまう。つまりサーバから見たら未知のUAとなってしまう。GMailにアクセスするとなぜか簡易版HTMLが表示されてしまうのは、未知のUAに対しては簡易版HTMLを返すようにGMailが作られているからではないかと僕は推測している。

変更点1で書いた話を実施するにあたって、当初はこれらのプロパティもgetterとして定義してみてたんだけど、実際に動かしてみると、期待通りには動かなかった。具体的には、Webページ内のスクリプトからnavigator.userAgent等にアクセスしようとすると、セキュリティの制限により前述のgetter関数を実行できない、というエラーが出る。

なので、getter関数を使うことは諦めて、ProtocolHandlerProxyクラスのプロトタイプに、単純な文字列や数値の定数プロパティとしてそれらを設定しておくようにした。general.useragent.* 系の設定の変更を動的に反映しないといけないので（ここでgetterを使えないのが痛い）、とりあえず今のところは、それらの設定の変更を常時監視して、変更があればその都度ProtocolHandlerProxyクラスのプロトタイプの定数プロパティの値を更新するようにしている。

変更点3：https:なURIに対しても働かせるようにした

この実装では、ProtocolHandlerProxyをスーパークラスとして、HttpProtocolHandlerProxy、HttpsProtocolHandlerProxyという2つのサブクラスを定義することにした。これらの違いは単にコントラクトIDだけ。（まあ、モジュールを登録する時にしか使わない情報なので、サブクラスにするまでもなかったんだろうとは思うけど……）

変更点4：このコンポーネントを使うかどうかをユーザが設定できるようにした

コントラクトIDが@mozilla.org/network/protocol;1?name=httpであるコンポーネントを入れ替える事を考えた時に、一番問題になるのはおそらく、同じ事をしようとするアドオンが2つ以上あった時のことだと思う。テストケース内でリクエストされるURIをリダイレクトするためだけに、いつもコンポーネントを入れ替えた状態にしておくというのは、無駄にリスクを高めるだけのような気がする。なので、必要な時にだけ機能を有効化できるようにしてみた。

当初は、NSGetModule()が返すモジュールのregisterSelf()メソッドの中でregisterFactoryLocation()している箇所を、設定値を見て必要に応じスキップするようにすればいいだろうか、くらいに考えていた。でも2つの理由でこれはうまくいかなかった。

1. コンポーネントを登録する処理が走る段階では、プロファイルが初期化されていないので、ユーザが設定を有効にしているのか無効にしているのかが分からない。
2. コンポーネントの登録はUxUをインストールまたはアップデートした後に1回行われるのみなので、ユーザが設定を変更しても即座には反映されない。

1の問題をもう少し具体的に書くと、例えばこのコンポーネントの有効無効をextensions.uxu.protocolHandlerProxy.enabledといった名前の設定で切り替えるようにしようと思っても、NSGetModule()が返すモジュールのregisterSelf()メソッドが実行される段階ではまだユーザプロファイル内に保存された設定値が読み込まれていないため、その段階でextensions.uxu.protocolHandlerProxy.enabledの値を取得しても常にデフォルト値（＝false）となってしまう、ということ。

これを回避するためにUxUでは、設定値ではなくファイルを使うことにした。プロファイル内に「.uxu-protocol-handler-proxy-enabled」という名前のファイルがあればコンポーネントを有効に、ファイルがなければコンポーネントを無効に、という風に、ファイルの有無を真偽値型の設定代わりに使うようにしている。泥臭いというか非効率的というかすごく馬鹿っぽいというかそんな気がするけど、これ以上にいい方法を僕は思いつけなかった。

2の問題は、1を解決できたとしても発生する。Firefoxは利用可能なXPCOMコンポーネントのデータベースをプロファイル内にcompreg.datとxpti.datとして保存しているようで、これらのファイルを生成する時にNSGetModule()が呼ばれるんだけれども、毎回起動時にこのデータベースを作り直していたら無駄が大きすぎる。ということで、アドオンが追加・削除された時などの「コンポーネントの一覧に変更があった可能性がある」場合にだけ、有効なコンポーネントの一覧のデータベースが作り直されるらしい。UxU的には、プロトコルハンドラの乗っ取りのON/OFFを切り替えた後に必ずこのデータベース再作成の処理を走らせないといけない、でもそれができてない、ということだ。

で、これも似たような方法でアッサリ解決した。Firefoxはユーザプロファイル内に「.autoreg」という名前のファイルがあると（ファイルの有無しか見ないので、内容は何でもいい。空ファイルでよい。）、必ずcompreg.datとxpti.datを再作成する。なので、ユーザが設定を変更したらそのタイミングで「.autoreg」を作成してやり、次に起動した時には設定の変更が確実に適用される（コンポーネントが有効かあるいは無効化される）ようにした。

んで

これだけごちゃごちゃと妙なことをやっておいて、できることといったら単にURIをリダイレクトするだけなんだよね。ショボっ！

プラットフォームのデフォルトの文字エンコーディングを取得する方法を調べようとして挫折したことのまとめ - Jun 06, 2009

ソース表示タブの障害として、「外部のテキストエディタを使う設定にしてる時に、Windowsのアカウント名が日本語だったりするとファイルを開けない」という報告を受けた。それを修正しようとして挫折した。以下はそのまとめ。

Webページのソースをテキストエディタで開く処理について

当該機能は実はソース表示タブ自身が提供しているわけではなく、Firefox 2以降くらいからFirefox自体に元々備わっている隠し設定のための設定UIを提供しているだけで、実際の処理はFirefox本体の物に丸投げしている。具体的にはviewSourceUtils.jsのopenInExternalEditor()とかそこら辺。

ただ、Firefox本体のこのコードは国際化のことをきちんと考えられていないようで、テキストエディタの実行ファイルのパスに日本語の文字などが含まれているとダメという既知のバグがある（原因はgetExternalViewSourceEditor()の中でgetCharPref()で取得したパス文字列をUTF-8バイト列からUCS2のUnicode文字列に変換していないせい）。なのでソース表示タブではこの部分に動的にパッチを当てる形で問題を回避するようにして、もう少し実用に耐えるようにしようとしてみている。

今回の問題の原因は、エディタの実行ファイルではなく、開こうとしている対象のファイルのパスの扱いにある。

Firefoxは、ソースを表示しようとしている対象がローカルのファイルだとそれをそのまま、Web上のファイルであればそれをダウンロードしたテンポラリファイルを、エディタに渡そうとするんだけど、どうもその時にnsIProcessのrun()メソッドで渡す引数がUCS2のままなのがいけないらしい。試しに自分の環境（Windows Vista日本語版）で試したところ、引数のeditor.run(false, [path], 1);とか書かれてる箇所で渡されてるパス文字列をnsIScriptableUnicodeConverterあたりでShift_JISに変換してやったらうまく動いた。IDL定義ではstringの配列としか書かれてないけど、ここはプラットフォームごとのデフォルトの文字エンコーディングにしておかないといけないようだ。

実験段階で明らかなように、nsIScriptableUnicodeConverterで適切なエンコーディングに変換してやれば問題は解決できる。残る問題は、じゃあ一体どのエンコーディングに変換すればいいのか、ということだ。

設定UI上にエンコーディング選択用のドロップダウンリストを付けるという手もあるけど、ユーザにそんな事を意識させるのはダサイ。なるべくなら自動で判別できるようにしておきたい。ということでその方法を模索してみた。

nsIFileのnativePathから辿ってみた

現在のFirefoxでは、ローカルファイルはnsIFileインターフェースで処理されている。このIDL定義を見ると、プラットフォームのデフォルトのエンコーディングでのパス文字列をそのまま保持しているとおぼしきnativePathプロパティの定義には[noscript]と書かれていて、JavaScriptからはアクセスできないようになっている。実際、試してみても無理だし。

ちなみに、昔おそらくnsIFileの代わりに使われていたと思われるnsIFileSpecだとnativePathには[noscript]が付いてない。なので、これを使ってやればいいか？と思ったけど、リンク先のソースの位置を見ると分かる通りこれは既に廃止されたモジュールで、今のFirefoxのバイナリには入ってないっぽい。インスタンスを作ろうとしてもエラーになる。

nsIFile/nsILocalFileを実装してるWindows用のコード（nsLocalFileWin.cpp）のGetNativePath()の定義を見ればヒントを掴めるんじゃないか？と思ってみてみたら、CopyUnicodeToNativeという関数？が使われてた。コードが書かれてるnsNativeCharsetUtils.cppを見てみると……おおお、なんか答えっぽい物があるぞ。ifdefでプラットフォームごとに関数の中身の定義をそれぞれ変えてて、例えば頭の方を見てみると、Mac OS XとBeOSでは単純にUTF-8に変換してるという事が分かる。

ただ、下の方に書いてあるWindows用とUnix/Linux用の処理は、見ても訳が分からんかった……単純にこのエンコーディングに決め打ち、という訳にはいかないみたいで、ここからさらに色んな所のコードを見に行かなきゃいけないようだったので、この時点で挫折した。

nsIScriptableUnicodeConverter関係から辿ってみた

nsIScriptableUnicodeConverterはエンコーディング名を指定してUCS2との間で相互変換するものだけど、その時に「プラットフォームのデフォルトのエンコーディング」を指すようなキーワードがあったりしないしないか？と思って、そっち関係のコードも見てみた。

nsICharsetConverterManager.idlとかnsUConvModule.cpp見てて、どこをどう辿ったのか忘れたけど、GetDefaultCharsetForLocale()というメソッドがnsIPlatformCharset.hで定義されているという所まで辿り着いた。

メソッド名から見て、ロケールを指定しないといけないようだけど、それさえなんとかなればこれでいけるか？　と思ってこれにJavaScriptからアクセスできないか試してみたけど、ダメだった。Components.classes['@mozilla.org/intl/platformcharset;1']にはアクセスできるんだけど、QueryInterface(Components.interfaces.nsIPlatformCharset)してみたら「そんなインターフェースねえよ」と怒られてしまった。検索してみても、どうもC言語用のコードしか無いみたい。

結論

無理でした。以上。

C（C++？）を書けるようになって、上で辿り着いたメソッドの実行結果を返すだけのコンポーネントでも書けば、サクッと解決できるのだろうか。もう勉強するしかないのか？

おまけ：文字コード選択のUI

コンテキストメニュー拡張で使ってるけど、文字コードを選択するドロップダウンリストは以下のようにすれば作れる。

<menulist id="charset"
  label="(choose an charset)"
  datasources="rdf:charset-menu"
  ref="NC:DecodersRoot">
  <template>
    <menupopup>
      <menuitem uri="..."
        label="rdf:http://home.netscape.com/NC-rdf#Name"
        value="..."/>
    </menupopup>
  </template>
</menulist>

ただし、XULにこれを書いただけだと空のリストになってしまう。onloadとかそこらへんでCc['@mozilla.org/observer-service;1'].getService(Ci.nsIObserverService).notifyObservers(null, 'charsetmenu-selected', 'other');とすればポップアップの中身が生成される。設定ダイアログで使う時なら、その後でpreference要素のvalueを見るなどして、前回の選択状態を復元してやる必要がある。

「英語（辞書アシスト検索）」モードは、英和辞書で検索する機能ではない - May 28, 2009

ローマ字入力で日本語ページ内の検索を可能にする「XUL/Migemo」拡張 - SourceForge.JP Magazine

さて、もう一つの検索方法である「英語（辞書アシスト検索）」であるが、これは英単語を入力するとその対訳となる日本語の単語が検索されるというモードだ。なぜか筆者の環境ではうまく機能しなかったのだが、一応使い方を説明しておく。

そんな機能実装した覚えないんですけど……

英語モードは、僕が正式にXUL/Migemoを引き継いだ後に行った大改造において、将来的に日本語だけでなく中国語や韓国語などのIMが必要な他の言語に対応できるよう、言語依存の主要モジュールを差し替え可能にした時に、日本語特有の処理（ローマ字入力を平仮名に変換するなどの処理）を含まないプレーンなモジュールの実装例として用意した物だ。

Firefox自身の通常の検索機能と比較して、このモードで具体的に起こる変化としては、「ext」まで入力した時点で「extension」「extend」等の英単語が強調表示されるようになる、という感じなんだけれども……これってぶっちゃけ無意味なんだよね。

• 日本語では、入力した文字列（ローマ字）とページ内のヒット箇所（仮名漢字交じり）の文字列とが一致しない。「kanj」と入力した段階で登録済み単語の「漢字」にヒットしてくれれば、総キータイプ数が少なくなる。→メリットがある！
• 英語では、入力した文字列とページ内のヒット箇所とが原則として一致する。なので、補完が無くても元々キータイプ数は最小で済む。→メリットが無い！

あとは、発音記号付きのアルファベット等を区別せずに検索できるようになるけど、それとて日本語用のエンジンに既に包含されている機能だし。

強いて言えば、日本語とかローマ字とか全然興味がないし必要も無いという英語圏のユーザの人が、Safari風の強調表示だけ利用する時に、ほとんど何も余計なことをしないから邪魔にならない……ということくらいだろうか。英語モードのメリットは。とにかく、「これこれこういう凄いことができるようになる」といった類の意義は皆無だ。そのモードを作った本人が言うんだから、間違いないよ。

Trunkでデフォルトのテーマから削除されたThrobberの画像の代替 - May 25, 2009

くでんさんが報じておられる通り、Bug 418003 - Firefox is packaging unneeded images and iconsによって、過去に使われていたもののもう使われていない画像がデフォルトのテーマからまとめて削除された。Trunkでは既にそのようになってるけど、Firefox 3.5もそうなるんだろうか。だとしたら例によって「何でこんなギリギリになってからやるわけ？」と愚痴りたくなるわけですが。

削除されたファイルの一覧はMercurialのコミットログを見ると分かる。行の頭に「-」が付いている物が、削除されたファイルという事になる。

自分がアドオンの中で流用していて影響を受けるのは、「読み込み中」の状況を示すためのアイコンとして使っていたThrobber-small.gifだ。Throbber.png、Throbber.gif、Throbber-small.pngも一緒に削除されたので、これらを流用してる人は代わりのアイコンを参照するようにしないといけない。

これらのThrobber画像は、半透明のアニメーション画像に差し替える関係でFirefox 3.0の時点から既に使われなくなっていた。また、これらの新しいThrobber画像は16×16サイズのものしか用意されていないので、大きいサイズの画像が必要な場合は自作するか古いバージョンからぶっこ抜くしかない。

16×16については、以下のChrome URLで参照できる。

• chrome://global/skin/icons/notloading_16.png（アニメーション無し）
• chrome://global/skin/icons/loading_16.png（アニメーションあり）

少なくとも今の時点では、Windows用、Linux用、Mac OS X用のいずれも同じパスで参照できるようだ。

ユーザが別のテーマを選択している場合もこの画像を参照したければ、以下のようにjarファイルの中のパスを直接指定する必要がある。

• jar:resource:///chrome/classic.jar!/skin/classic/global/icons/notloading_16.png
• jar:resource:///chrome/classic.jar!/skin/classic/global/icons/loading_16.png