自己レスです。

そもそもやりたかったのは、browser自体は通常のブラウザとして使い、tabbrowser内のひとつのタブ内でbrowser,canvas,scrollbarの要素を自由に配置することでした。
stackタグがFirefox3.6の時にはうまく動いておらず（確認不足かもしれませんが）、他に自由に配置する方法として、以下のような構成としていました。
1)Firefox-tabbrowserタグ
　2)xulファイル
　　　-browserタグ
　　　-canvasタグ
　　　-scrollbarタグ

＞現状の実装方針では回避が必要になっているため、contentAreaClickメソッドを実装する方式を取りたいと思います。

と一旦は決めましたが、2)XUL内のbrowserでもともとのbrowserの動作をさせようとすると、1)で実装されている機能を2)のbrowserに全て盛り込まなくてはいけなくなります。（HistoryやBookmarkの管理など、contentAreaClickもそのひとつ。）
物量的に非常に大きくなってしまうので、そもそも実装方針は正しいのかと考え直したところ、解決策が見つかりました。

Firefox4.0でstackを改めて試してみると、うまく動作したため、stack内のbrowserをheight,width,top,leftの位置情報を変更し、stackの子要素としてcanvas,scrollbarを追加して、階層構造を取り除きました。
1)Firefox-tabbrowserタグ
　　>stack
　　　-browserタグ（既存）
　　　-canvasタグ（追加）
　　　-scrollbarタグ（追加）


結果として、本トピックであげた質問は1)tabbrowserのbrowserを利用することで発生しなくなり、またその他のセッションヒストリなどの問題にもぶつかることはありませんでした。
　⇒総論として、アドオンでtabbrowser内のbrowserにXUL（browser含む）を読み込ませるともろもろ大変となる。stackを活用した方が良い。

本トピックでのご回答により、当初よりも少ない労力で目的のアドオンを作ることができました。FixScrollという名称でレビュー申請を出しているところではございますが、皆様のサポートをいただき無事リリースできたことの報告とお礼を申し上げたいと思います。

どうもありがとうございました。

Piroさん

ご回答ありがとうございます。
確認対象が明確になり、非常に助かりました。

＞端的に言うと、仕様上の制限による避けられない問題だと考えられます。

現状の実装方針では回避が必要になっているため、contentAreaClickメソッドを実装する方式を取りたいと思います。

元々のcontentAreaClick()を読んでみたところ、targetが_topや_parentだと処理が分岐するような箇所を見つけられませんでした。実際に<a>タグのtargetが_selfのときと_topのときで動かしてみましたが、処理内容は全く一緒に見えました。handleLinkClick（）はtargetが_selfでも_topでも同じ動作となりました。
　⇒contentAreaClick()がreturn true;した後の処理（何が処理されているのかはJSレベルでは読み取れない）で、_topや_parentで分岐されているようでした。（Piroさんのコメントの後半部分に書いてある内容が推測されます。）

ということで、以下の内容で影響範囲を小さくするようにつくりこもうと思います。
①_targetが_topか_parentのとき、
　contentAreaClickの中で、return true;後に処理される部分に相当する部分を自前で実装
②それ以外
　既存の処理のまま

＃まさかのPiroさんからの回答でテンションあがってしまいました。お忙しい中のご対応ありがとうございます。

端的に言うと、仕様上の制限による避けられない問題だと考えられます。
どうしてもこの問題を回避したいという場合には、handleLinkClick()やcontentAreaClick()に相当する実装を自分で持つようにして、キャプチャリングフェイズでクリック時のイベントを捕捉してtarget属性の処理を自前で行うようにするしかないと思います。（その後event.stopPropagation()/event.preventDefault()すれば、Firefox自身が行うはずだった処理をキャンセルできます。）

いつの時点からかは分かりませんが、サブフレーム内のbrowser要素は固有のセッションヒストリを持てないようになってしまっています。そのため、タブの中に読み込んだXULファイルの中にあるbrowser要素に対してはgoBack()できず、あくまでその親にあたるタブのbrowserのgoBack()を呼ばないといけません。
targetの処理もおそらくこれと同様で、typeがcontent/content-primaryなbrowserの中に読み込まれた内容に対しては、type="content"のようなXUL特有の特別なルールも適用されなくなってしまうのだと思われます。

現在、Firefoxのアドオンを作成しております。
下記の解決のためのアドバイスをくださいませんか。

Firefox4.0のtabbrowserで読み込んだxulファイル内の<browser>に読み込んだHTMLファイルのリンクtargetが"_top"もしくは"_parent"のときに、xulファイルを上書きして読み込まれます。
【初期構成】
1)Firefox-tabbrowserタグ
　2)xulファイル-browserタグ
　　3)HTMLファイル-aタグ（targetが_top）

【現状のリンククリック後の構成】
1)Firefox-tabbrowserタグ
　2)HTMLファイル(リンク先)

これを以下の動作にする方法を現在調査中です。良い方法があれば教えてくださいませんか。

【希望するリンククリック後の構成】
1)Firefox-tabbrowserタグ
　2)xulファイル-browserタグ
　　3)HTMLファイル(リンク先)


tabbrowser内ではなく、OpenDialogで該当のxulファイルを開いた場合は希望する動作をしていました。tabbrowser内で動作させると、上記のような動きとなります。
http://stackoverflow.com/questions/5463429/prevent-target-top-from-taking-over-ui-in-mozilla-chromelessが本質問と一番近い内容となっておりますが、browserのtypeをcontent,content-primary,content-targetableのどれにしても同じ動作になりました。
おそらく、tabbrowserがリンククリック時の動作を横取りして、xulを上書いていてると想定しています。

■具体例
Firefox4のtabbrowser
　⇒test.xulを読み込み

・test.xul
<window>
<browser id="testBrowser" type="content-primary" />
</window>

【browser内で読み込むHTML例】
<a href="http://www.google.co.jp" target="_top">link</a>