Thunderbird本体［omni.ja］内にある［messengercompose.xul］において［cloudAttachmentLinkManager.js］を読み込んでいますが、自作のJSファイルを読み込むように変更したい考えています。
変更方法として［omni.ja］内のXULファイルを直接変更するのではなく、自作のアドオンで変更したいと考えています。
XULファイルのJSファイル読み込み定義を削除することは可能でしょうか。
（自作のアドオンで対象のXULをoverlayし、自作のJSファイルを追加することは出来ています。）

■対象ファイル
C:\Program Files\Mozilla Thunderbird\omni.ja\chrome\messenger\content\messenger\messengercompose\messengercompose.xul

■対象箇所［messengercompose.xul］
<script type="application/javascript" src="chrome://messenger/content/messengercompose/cloudAttachmentLinkManager.js"/>
→上記のJSファイル読み込み定義を削除したい。

■動作環境
［OS］Windows 7 Professional 32bit SP1
［MUA］Thunderbird 24.2.0
［Addon］Dropbox for Filelink 1.0.1

_________________
Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0

「アドオンで対象のXULをoverlay」というのは、
Tbが、C:\ ... \omni.ja\ ... \messengercompose.xul というファイルを、chrome://messenger/ ... /messengercompose.xul というURLで持ってきたものにオーバーレイ、であり、
このXULオーバーレイにおいて、この「chrome://messenger/ ... /messengercompose.xul 」というURLに対応するリソースの探索順を変えるとか、リソースの探索場所を上に追加する、というようなことはできなかった？
それができないと、アドオンで、Tbの標準のhogehoge.xul/.jsをコピーして書き換えたものをアドオンのhogehoge.xul/.jsに入れておいて、アドオンのhogehoge.xul/.jsを使わせる、というようなことができないから、できそうに思えますが。
それと、chrome://～/...の探索は、固定された一つの場所ではなくて、chrome://～に対応する複数の定義の上からもってくるのでXULオーバーレイやアドオンが成立する、という風に思っていたのですが...

Tbのmessengercompose.xulがsrc="chrome://messenger/ ... /cloudAttachmentLinkManager.jsで持ってくるものを、自分のアドオンのcloudAttachmentLinkManager.jsにし、その中で、TbのcloudAttachmentLinkManager.jsの中の全てのロジックやfunctionを思い通りに書き換える、とか、
chrome://messenger/ ... /messengercompose.xul で持ってこられるものを、自分のアドオンの中のmessengercompose.xul にさせて、その中の<script>でロードするものを好きなように書き換える、
というようなことができるようにはなっていない？

windowの定義でロードされるhogehoge.jsで定義しているfunction文は、window.function名というJavaScriptのグローバル変数になりますし、
あるオブジェクトのプロパティーとして定義している～=function() ...ならば、そのあるオブジェクト.プロパティ名になりますから、
自分のアドオンの中で、そのwindow.function名やオブジェクト.プロパティ名の内容を自分で定義したfunctionオブジェクトで置き換えれば、
TbのJSコードを自分のもので置き換えることができます。
Tbのhogehoge.jsをロードした時に実行される部分を停めることはできないですが。

それに、cloudAttachmentLinkManager.js がやっていることは、
gCloudAttachmentLinkManager というオブジェクト(コンポーザーウィンドウのwindow.gCloudAttachmentLinkManager というJSのグローバル変数)を定義し、そのプロパティーに各種のfunctionを定義し、gCloudAttachmentLinkManager というオブジェクトの中の何かを、addEventListnerでEventListnerとして登録しているだけです。
「cloudAttachmentLinkManager.jsのソース」
ですから、そのEventListnerをremoveEventListnerで殺し、window.gCloudAttachmentLinkManagerというオブジェクトの中身を書き換え、自分のEventListnerを登録してしまえば、TbのcloudAttachmentLinkManager.jsを書き換えたのと同等になります。
TbのcloudAttachmentLinkManager.jsがロードされて、自分のアドオンに制御が渡ってくる前に、Tbのwindow.gCloudAttachmentLinkManagerを使って他の誰かが実行した部分のキャンセルはできませんが、
compose-window-init、compose-window-close, compose-send-messageのイベントリスナーを登録しているだけだから、最初のcompose-window-initが発生するまでは誰も何もしないわけで、コンポーザーウィンドウでアドオンがロードされる方がほぼ確実に先になるように思えます。
gCloudAttachmentLinkManager.init.bind(gCloudAttachmentLinkManager)の.bindが何者なのか不明なので、正確なところは不明ですが。

JavaScriptコードの置き換えでは、これが一番簡単で楽だから、このほうが一般的じゃないかな？
TbのcloudAttachmentLinkManager.jsが定義したものを置き換えてしまう、というような手法ではダメだったので、TbのcloudAttachmentLinkManager.jsをロードさせないようにしたい、なのですか？

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

捕捉です。

chrome://messenger/... というURIとC:\ ... \omni.ja/messenger\...のようなリソースの関係は、chrome.manifestファイルで指定するのですが、
Tbのchrome.manifestで定義してある「content messenger リソースのパス」(packagename=messenger)が既にある時に、アドオンのchrome.manifestでも同じpackagenameを指定して「content messenger アドオン内のリソースのパス」とした時にどうなるかは、MDNのドキュメントのいくつかをざっと眺めた程度では、よくわかりませんでした。
「XUL_Overlays」、「Manifest_Files」、「Chrome_Registration」
同じpackagenameを指定すると、置き換えなのか、上か下に追加して順番に見てくれるのか、エラーで拒否されるのか...
上に追加ならば、既にあるリソースの一部だけを上書きできることになるし、新規にchrome://messenger/... /hogehoge.xulで指定するリソースを追加できるんだけど...

「packagename」ですから、ユニークなpackagenameでないと、エラーではじかれるか、良くて置き換え、のような気がします。
置き換えだと、結局、C:\ ... \omni.ja/messenger\...の全部をアドオンの中にコピーして必要なものだけを書き換えておく、ということになって、アドオンの形にする余計な手間がかかる割には「アドオンとしてインストールできる」以外のメリットは何も無いから、omni.jaをUNZIPして書き換えてまたZIPしておく、の方が返って楽ですね(^^)

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

追記です。

function名.bind()は、functionのクローンを作ってくれるものでした。
「Global_Objects/Function/bind」
クローンのfunctionの中で参照する this が、確実に、そのクローンのfunctionをプロパティーとして持った親オブジェクト、になるから、EventListnerなどでは「現時点のthisとは何か」など、余計なことを考えずに済んで、便利そうです（Creating a bound function セクション参照）。

でも、Tbが、addEventListner(あるイベント, あるオブジェクトのfunctionのクローン, true/false) でリクエストしたListnerを、
アドオンで、removeEventListnerで殺そうとした時、そのイベントに対するどのListnerなのかを、どう指定すればいいのか...
全く同じ「コンポーザーウィンドウ」からのリクエストになるから、別のクローンを作ってremoveEventListnerを出せばOK？

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

追記です。

ある特定のListnerが起動された時に、Listner自身がarguments.caleeを指定してremoveEventListner、という方法が紹介されていました。
「Removing anonymous event listeners in JavaScript」
そのEventListnerのコードの中に最初から書いていないとダメなので、今回のケースには使えないですが、参考までに。

W3C DOMにおける、イベントハンドラーの登録・登録解除に関するこういった問題は既に認識されているようです。
「Which event handlers are registered?」
MSの実装だと、EventHandlerは、コピーではなく参照なので、そのfunctionオブジェクトの中のコードを書き換えれば済むみたいなのですが、
JavaScriptの拡張のfunction.Prototype.bind()で作られたAnonymous Functionのイベントハンドラーを殺すのは、容易ではなさそうです。

コンポーザーウィンドウでロードされるメインのxulを、
chrome://messenger/ ... /messengercompose.xul というファイルからアドオン内のmessengercompose.xul なり hogehoge.xul に変えて、Tbのスクリプトをロードさせない、ということ自体は、上位のXUL上の定義を変えればできるのですが、
上位のXULを書き換えると色々ややこしいことも起こりそうだし、長いmessengercompose.xul をコピってメンテ、は、後が面倒そうだし、他のアドオンとのバッティングなども簡単に引き起こせそう...

chrome://messenger/ ... /messengercompose.xul では、幸いなことに、<stringbundleset id="stringbundleset"> とid指定のものが、cloudAttachmentLinkManager.jsのscriptの前にあります。
「messengercompose.xulのソース」
messengercompose.xul のオーバーレイで、id=stringbundlesetの前にアドオンのscriptを挿入し、
その中で、cloudAttachmentLinkManager.jsのロードが実行されてしまう前に、そのscriptオブジェクトのsrc属性を、アドオン内のhogehoge.jsに変えてしまう、
あたりになるかな。
script文にもID属性を付けていてくれると、XULオーバーレイでscriptの置き換えも簡単にできるはずなんですけどね。

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

追記です。

何をどうしたいがために「cloudAttachmentLinkManager.jsのJSファイル読み込み定義を削除したい」のかがわかりませんが...

cloudAttachmentLinkManager.jsをコピって、それをちょこちょこっと書き換え、それをコンポーザーウィンドウに追加しただけでは、
「それをちょこちょこっと書き換え版」が実行される前にオリジナルによってリクエストされた、オリジナル版のfunctionのクローンの3つのイベントハンドラーは必ず実施されますし、オリジナルのinitのイベントハンドラーが一回は起動されますから、オリジナル版のinitというfunctionのクローンによって、thisを指定してaddEventListnerやRegistStateListnerなどが実行されます。

行いたいことは、gCloudAttachmentLinkManagerというグローバルオブジェクトはそのままで、そのプロパティーなどを書き換え、
その上に、addEventListnerやRegistStateListnerによる制御の流れも好きなように変えて自分の思い通りの流れにしたいのですか？

普通、アドオンで行いたことは、この流れの中で、ある時点で処理される内容を変える、というようなことではありませんか？
それならば、問題は、「cloudAttachmentLinkManager.jsが何をどうやっているかを無視して、
cloudAttachmentLinkManager.jsをコピって、それをちょこちょこっと書き換えて、それを追加した」ということにあります。
アドオンでは、各添付に対して実行されるgCloudAttachmentLinkManagerのプロパティーのfunctionの中身を書き換え、必要ならば、新規にfunctionをgCloudAttachmentLinkManagerのプロパティーとして追加しておく、くらいにとどめ、コピーしたのでそのまま残っているJSファイルのロード時のaddEventListnerなどは実行しない、というのが、普通ではないですか？
この場合、gCloudAttachmentLinkManagerのプロパティーであるfunctionにおいては、thisはgCloudAttachmentLinkManagerというオブジェクトになる、ということに注意しないといけないですが。
：、

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

追記です。

cloudAttachmentLinkManager.jsのinit:の中でやっている、addEventListner(～,this,～)が、windowのイベントだしイベントハンドラーのthisはwindowのはずで、指定するものは、functionオブジェクトかソースコードのはずで、実行されるのはこのinit:というfunctionのクローンだからthisは標準中の標準のはずなので、どうにも解せなかったのですが、「MOZ DEVのAdding_an_Event_Listener」を見て、納得。
XULの要素だとほとんど全てにoncommand()があって、これがデフォールトとして使われる、ということか、
イベントごとにイベントハンドラーが決まっていてそれぞれのイベントハンドラーをメンバーに持つオブジェクトを指定、というのが、各種のEvent Notificationの標準手法で、addEventListnerでも同じこと、
ということみたいです。
RegisterStateListnerは、「4つのイベントハンドラーをまとめて」だから、わかるんですけどね。

コードを書いている人は、そこらをわかった上で意図的に書いているんでしょうかね。
普通、addEventListnerでは明示的にfunctionであるとされているものを指定すると思うし、addEventListnerとRegisterStateListnerで、同じオブジェクトをListnerに指定する、というようなことは、あまりしないと思うんだが...
最初に実行されるソースの一番下のaddEventListnerでは、function.bind()を使うためということもあるとは思うが、明示的に特定のfunctionのクローンを指定しているんだし...
windowオブジェクトには全部のイベントハンドラーがあるんだから、何も気にしないでいつもwinoowを指定、というのもありですけど...
でも、function.bind()の使い方や、uninit:でのremoveEventLstnerやUnRegisterStateListnerでのthisの使い方をみると、ちゃんとわかった上で書いているんでしょうね。

さて、そうなると、init:は変えても意味無し。
でも、init:がキックされてその中でRegisterStateListner(～,this,～)が実行されるのは、アドオンのhogehoge.jsが読み込まれて実行された後だから、
NotifyComposeFieldsReady, ComposeProcessDone, SaveInFolderDone, NotifyComposeBodyReadyのイベントハンドラーとして、アドオンが書き換えたものを使わせるのは簡単。
オリジナルはそのままにしておいてアドオンのイベントハンドラーで追加処理をする、というのも容易。
必要なら、アドオンでcompose-window-initハンドラーを追加しておけば、init:のオリジナルを変えても意味はないにせよ、追加の処理は可能。

uninit:も、書き換えてもオリジナルが実行されるが、オリジナルでも問題はないはずだし、必要なら、アドオンでcompose-window-closeハンドラーを追加しておけば、追加の処理が可能。

問題は、compose-send-messageの時のオリジナルのsend:のクローンの動作。
オリジナルのsend:のクローンの動作を変えることはできなくて、アドオンがcompose-send-messageハンドラーを追加しても、オリジナルのsend:のクローンが実行されてしまっているので、アドオンのcompose-send-messageハンドラーではどうしようもない、ということが起こり得る。

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

余談です。
前のコメントを書いていて、ふと思ったこと。

mail.compose.max_recycled_windows=0ならば、コンポーザーが閉じられるとwindowがなくなるからいいんだけど、
mail.compose.max_recycled_windows>0だと、コンポーザーウィンドウは隠されるだけで、window自体はなくならない。
その時に、あのコードで、Anonymous Functionを指定したイベントハンドラーが、本当にちゃんと消されるのか...
コンポーザーウィンドウのオープンクローズを繰り返すと仮想メモリーサイズが無限に増えていくとか、コンポーザーウィンドウのオープンクローズを繰り返すと遅くなる、といった問題の原因は、ああいったコードによるものなんじゃないか...

記憶が正しければ、送信のあとコンポーザーウィンドウが隠され、次回リユースされた時に、~.xulは再ロードされたはず。
となると、uninit:できちんとAnonymous FunctionのEventListnerが殺されない限り、～.jsのロードで実行されるaddEventListner(...,あるfunctionのクローン,...)によって、windowのEventListnerが無限に増えていく...

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

訂正です。

コードをちゃんと見てなかった...(^^;
bindで、thisがgCloudAttachmentLinkManagerになるように指定してありました。
window.addEventListener("compose-window-init",
gCloudAttachmentLinkManager.init.bind(gCloudAttachmentLinkManager), true);
でも、やっぱり、init:の中のaddEventListnerで、functionオブジェクトではないthis==gCloudAttachmentLinkManagerを指定しているのは、ちょっと気色悪い...

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

現時点の結論。

コンポーザーウィンドウに chrome://messenger/content/messengercompose/messengercompose.xul 以外のものをロードさせる、という手段はなさそうです。

コンポーザーウィンドウのオープンは、
nsMsgComposeService.cpp の「 nsMsgComposeService.cppのnsMsgComposeService::OpenComposeWindowWithParams 」で行っているのですが、
新規ウィンドウでは「C++ソースの#define DEFAULT_CHROME "chrome://messenger/content/messengercompose/messengercompose.xul" 」で定義されたURLが指定されますし、リサイクルウィンドウは、URLがDEFAULT_CHROME、で判定されています。
この DEFAULT_CHROME をJavaScriptからダイナミックに変えるインターフェースは用意されていないようですし、設定するオプションもありません。

となると、messengercompose.xulに対するXULオーバーレイしかないのですが、
<script>にidが指定されていないので、XULオーバーレイを使ってcloudAttachmentLinkManager.js を他のもので置き換えることはできません。
idがあっても、<script>の置き換えはしてくれないかもしれません。

つまり、
■対象箇所［messengercompose.xul］
<script type="application/javascript" src="chrome://messenger/content/messengercompose/cloudAttachmentLinkManager.js"/>
→上記のJSファイル読み込み定義を削除したい。
に対する回答は、「XULオーバーレイを利用して行うことはできません」

アドオンで何かをしようとした時の障害は、
cloudAttachmentLinkManager.jsがロードされた時に実行されるaddEventListenerによってイベントハンドラーが登録されてしまうことなので、
それをremoveEventListenerで殺すことができさえすればいいのですが、
イベントハンドラーが、function.Prototype.bind()によって作られたAnonymous Functionなので、殺すためにはgetEventListeners()のような機能が必要になります。
この機能のためには、W3C DOM3 の EventListenerListが必要なのですが、これは、まだどのブラウザーも実装していない、という新しいものです。
従って、現時点では、cloudAttachmentLinkManager.jsによって登録されたイベントリスナーを停止することはできません。

以上により、現時点でできることは、
(A) omni.jaをUNZIPしてmessengercompose.xulから<script>を除去してZIP。
(B) <script> にもInsertBeforeが使えるのなら、InsertBeforeを利用してcloudAttachmentLinkManager.jsよりも前にアドオンの<script>を置かせ、その中で、cloudAttachmentLinkManager.js用のDOMのscript要素の属性を書き換えるなどして、cloudAttachmentLinkManager.jsのロードを阻止。
(C) cloudAttachmentLinkManager.jsによって登録されたイベントリスナーによる制御の流れを素直に受け入れて、変更したい処理の部分だけを置き換え、
必要ならば、自分自身のイベントリスナーを追加して、cloudAttachmentLinkManager.jsのオリジナルのイベントリスナーの後処理という形で必要なロジックを実行する。
のいずれかになります。

変更したい処理の部分だけの置き換えは、至極単純。

_generateLink: function(aDocument, aContent, aHref) の置き換えで、オリジナルのコードを実行してから、自分自身のコードを実行する例。

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

訂正です。

XULオーバーレイを使って、コンポーザーウィンドウに chrome://messenger/content/messengercompose/messengercompose.xul 以外のものをロードさせる、という手段は、ありました。
「chrome.manifestのoverride」を使えば、不可能ではありません。
ただし、書いてあるように、recursiveには適用されないですし、複数のアドオンが指定した時に最終的にどうなるかは、多分制御できないでしょう。
ある企業用にカストマイズしたThunderbirdを作る、というような、「Thunderbirdの書き換え」的なことのために用意されているのだと思います。

自分のアドオンだけがmessengercompose.xulに対するoverrideを使っていること、および、messengercompose.xulの上位のリソースに対してoverrideが行われていないことが保証されている場合には、「omni.jaをUZIPして～/hogehoge.xul を書き換えてZIP」の代わりにoverrideを使えます。
バージョンによってmessengercompose.xul の内容が変わらない場合には、複数のバージョンのTbでのテストとか途中でのTbのバージョンアップの時などに手間がかからず、便利かもしれないですね。
ただし、あるアドオンによるoverrideがどのタイミングで適用されるのか不明なので、他のアドオンによるoverlayとバッティング、ということは起こるかもしれません。
overrideは他の全てのoverlayに優先するというのが普通であろう、と思いますけど。

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

追記です。

「messengercompose.xulをoverride可能」とは言っても、大元のソースを見ればわかるように、Tbのomni.jaの中のmessengercompose.xulは、コンパイル時のオプションによって、少なくとも対象OSによって、内容が変わります。
従って、アドオンで行う場合、少なくとも「対象OSの数 × バージョンによって異なるmessengercompose.xulの数」だけのmessengercompose.xulを、アドオンの中に持つ必要があります。
overlayだとリソースに対する行の追加か行の置き換えだけですから、OSやTbのバージョンによって影響を受けないものだけにすれば、一つのリソースだけ定義、で済むんですけどね。
ご注意を。

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

また訂正です。

「JSファイル読み込み定義を削除したい。」にひきずられて、<script>を消すことばかり考えてしまった...(^^;
今回の件については、TbのcloudAttachmentLinkManager.js を、overrideを使って自分のアドオンの中のもので置き換えてしまえばすむ話、でした。
これなら、OSやバージョンに関係なくなるし。

「omni.jaをUNZIPしてhogehoge.fooを書き換えてZIP」の代替策は、
packagename = NoCloudManager として、アドオンのchrome.manifestに以下のように書いておいて、
アドオンの中にcontent/cloudAttachmentLinkManager.jsを入れておく。
ファイル名は、なんだって構わない。

～.xulの中の<script>の、overlayによる置き換えは、IDがあってもできないみたいだし、
messengercompose.xulをoverrideで置き換えるなんて、普通はやらないだろうし、
アドオンの名前を「SophisticatedCloudAttachmentLinkManager」とでもしておいて、
どこかに「TbのcloudAttachmentLinkManager.jsを置き換えている」とでも書いておけば、
他のアドオン開発者からの文句はほぼ来ないでしょうし、
gCloudAttachmentLinkManager というグローバル変数の名前を変えてしまえば、
gCloudAttachmentLinkManager を参照しているアドオンは動かなくなるから、
他のアドオンとのバッティングの問題もなくなる(^^)

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

またまた訂正です。

テスト結果の誤認があったようで...
あの指定では、どうも置き換えてくれないようです。
jsファイルのoverrideは効かないとか、絶対パスでないといけない、といういう問題に引っかかっているとか、コンポーザーのようなロードのされ方だとダメとか、かもしれないので、もう少し調べてみます。
アドオン作成の手法としては「制御の流れはオリジナルにまかせ一部のロジックだけを書き換え」が正攻法であることには変わりはないですが。

_________________
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36