マッピングはnsIChromeRegistry
componentによって実行され、すべてのマニフェストファイルを処理し、chrome://
のURLが解決される規則を作成します。これらのルールは明らかに露出していません。なぜなら、これらのルールは、明らかに予想していたものよりも複雑であるからです。例えば。 content
instructionは、クロムレジストリにchrome://foo/content/
で始まるURLを解決する方法を指示します。レジストリは個々のファイルではなく接頭辞のみを認識します。 localesとskinsの処理は似ていますが、複数のロケール/スキンがあり、URLがどのように解決されるかは、ブラウザの現在のロケール/スキンによって異なります。最後に、override individual URLsに可能性があり、例えば、それらを他のchrome://
のURLにリダイレクトすることが可能である。
だからあなたが持っているすべてはchrome://
URLを解決し、あなたに別のURL(file://
、jar:
あるいは別のchrome://
URL)を与えるnsIChromeRegistry.convertChromeURL()です。
プライベートのプロパティがnsChromeRegistryChrome
classの場合、そのクラスにパッチを当てることによって、物事は異なるでしょう。あなたが興味を持っているメンバー変数はmPackagesHash
です。ハッシュキーはパッケージ名で、値はPackageEntry
です。上書きを含むmOverrideHash
もあります。このような何かが(コードはもちろんの未テストです)動作するはずです:
mOverrideTable.EnumerateRead(&PrintOverride, nsnull);
PL_DHashTableEnumerate(&mPackagesHash,
&nsChromeRegistryChrome::PrintPackage,
nsnull);
...
PLDHashOperator
PrintOverride(nsIURI* key,
nsIURI* uri,
void* closure)
{
nsCString keySpec;
nsresult rv = key->GetSpec(&keySpec);
if (NS_SUCCEEDED(rv))
{
nsCString spec;
rv = uri->GetSpec(&spec);
if (NS_SUCCEEDED(rv))
printf("override %s %s\n", keySpec.get(), spec.get());
}
return PL_DHASH_NEXT;
}
PLDHashOperator
nsChromeRegistryChrome::PrintPackage(PLDHashTable *table,
PLDHashEntryHdr *hdr,
PRUint32 number,
void *closure)
{
PackageEntry* package = static_cast<PackageEntry*>(entry);
nsCString spec;
nsresult rv = entry->baseURI->GetSpec(&spec);
if (NS_SUCCEEDED(rv))
printf("content %s %s\n", entry->package.get(), spec.get());
nsTArray<nsCString> locales;
entry->locales.EnumerateToArray(&locales);
for (PRUint32 i = locales.Length(); i > 0 ;) {
i--;
nsCOMPtr<nsIURI> uri = entry->locales.GetBase(locales[i], nsProviderArray::EXACT);
rv = uri->GetSpec(&spec);
if (NS_SUCCEEDED(rv))
printf("locale %s %s %s\n", entry->package.get(), locales[i].get(), spec.get());
}
nsTArray<nsCString> skins;
entry->skins.EnumerateToArray(&skins);
for (PRUint32 i = skins.Length(); i > 0 ;) {
i--;
nsCOMPtr<nsIURI> uri = entry->skins.GetBase(skins[i], nsProviderArray::EXACT);
rv = uri->GetSpec(&spec);
if (NS_SUCCEEDED(rv))
printf("skin %s %s %s\n", entry->package.get(), skins[i].get(), spec.get());
}
return PL_DHASH_NEXT;
}
編集を:Firefoxの28の通り、今より良い方法があります。 Bug 890545が(まだ文書化されていない)nsIComponentManager.getManifestLocations()
メソッドを導入した場合、chrome manifest fileのURIをリストしたnsIArrayインスタンスを返します。だから、そのようなことは、すべてのマニフェストファイルのテキストを取得するために働くだろう:
var locations = Components.manager.getManifestLocations();
for (var i = 0; i < locations.length; i++)
{
var uri = locations.queryElementAt(i, Components.interfaces.nsIURI);
var request = new XMLHttpRequest();
request.open("GET", uri.spec, false);
try
{
request.send(null);
parseManifest(uri, request.responseText); // Something for you to implement
}
catch(e)
{
Components.utils.reportError(e);
}
}
それでも、マニフェストを解析することで、manifest、contentとoverrideライン、特に、そのシナリオの中で自分自身を行う必要がありますものです - すべて特にフラグを正しく考えると、まったく単純な作業ではありません。
ありがとうございました。私はnsChromeRegistryを調べました。私はMozillaがマッピングを管理するためにHashtablesとArraysの組み合わせを使用していると思います。私が言おうとしたのは、これらのデータ構造からすべてのマッピングのリストを取得できるかどうかです(すべてのクロムがマップされた後、実行時にデータ構造を照会します)。 ChromeListという名前のアドオンがありました。残念ながら、新しいFirefoxではうまくいきません。 – Anton
@Anton:この拡張機能はマニフェストを "手動で"解析するため、クロムレジストリの内部構造にもアクセスできません。 –
ええ、私は知っています。しかし、私はFirefoxのソースコードにいくつかのデバッグコード(パッチではない)を導入しようとしています。だから、私はそれらの内部データ構造を理解する必要があります。 – Anton