Hatena::Groupmoz-addon

hogezilla RSSフィード

当ページに書かれているコードは、修正BSDライセンスのもと、再頒布して頂いて構いません。

 | 

2011-12-11

動的なchromeURLの追加 - 2

| 18:33 | はてなブックマーク - 動的なchromeURLの追加 - 2 - hogezilla

前回はComponents.manager.addBootstrappedManifestLocationについて書いた。が、

と指摘されたとおり、本に既に書いてあるものだった。

しかし、pdf.jsの拡張機能版のソースコードを見ていて気付いたのだが、もうひとつやり方があった。

startup関数で

function startup(aData, aReason) {
  let manifestPath = 'chrome.manifest';
  let manifest = Cc['@mozilla.org/file/local;1']
                   .createInstance(Ci.nsILocalFile);
  try {
    manifest.initWithPath(aData.installPath.path);
    manifest.append(manifestPath);
    Cm.QueryInterface(Ci.nsIComponentRegistrar).autoRegister(manifest);
    Services.prefs.setBoolPref('extensions.pdf.js.active', true);
  } catch (e) {
    log(e);
  }
}

としている。

pdf.js では、pdfファイルをハンドリングするために、nsIContentHandlerXPCOMで登録しているが、これが、上記コードで出来ているのだ。

少し試してみたところ、

  • components
  • contract
  • resource

は無事登録できていた。

しかし──やはりというべきか──、overlayはできなかった。

他は試していないが、Components.manager.addBootstrappedManifestLocation()よりは使えるものが多く有用そうだ。

ただし、注意点として、登録はできても解除はできそうにない。

NS_IMETHODIMP
nsComponentManagerImpl::AutoUnregister(nsIFile* aLocation)
{
    NS_ERROR("AutoUnregister not implemented.");
    return NS_ERROR_NOT_IMPLEMENTED;
}
http://mxr.mozilla.org/mozilla-central/source/xpcom/components/nsComponentManager.cpp#1578

対応表

たぶん以下の様な感じ。overlaystyleはどちらも無理ではないかと思う。

DirectiveaddBootstrappedManifestLocationautoRegister
manifest
binary-component×
interface×
component×
contract×
category×
content
locale
skin
overlay××
style××
override
resource×

piro_orpiro_or2011/12/11 21:11再起動が要る普通のアドオンでこのAPIを使うのはいい(ほとんど意味はなさそうですが……)のですが、bootstrap.jsがあるアドオンでは、少なくとも今の時点では絶対に使ってはいけないテクニックだと思います。
本書の中でも散々口を酸っぱくして書いていますが、Firefoxのプロセスを再起動しなくてもアドオンを追加・削除・更新できるのが特徴のはずのBootstrapped Extensionsで非可逆的な変更を行うのは御法度だと自分は考えていますので、pdf.jsはだいぶ筋の悪い事をやっていると言えると思います。

teramakoteramako2011/12/12 13:01それは登録はできても解除がまだ実装されていないから、という意味でしょうか。
それともcomponentやresourceを使うこと自体が良くないということでしょうか?

トラックバック - http://moz-addon.g.hatena.ne.jp/teramako/20111211
 |