Jan 24, 2009
安全なタブの取得方法
前のエントリでも触れてるけど、Firefox 3.1ではタブでない要素がタブバーに入る可能性が出てきたので、安全なタブの取得方法を色々考えてみた。
まず、すべてのタブのリスト。
function getTabs(aTabBrowser) {
return aTabBrowser.ownerDocument.evaluate(
'descendant::*[local-name()="tab"]',
aTabBrowser.mTabContainer,
null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
null
);
}
var tabs = getTabs(gBrowser);
for (var i = 0, maxi = tabs.snapshotLength; i < maxi; i++) {
alert(tabs.snapshotItem(i).label);
}
配列でないと困る時はこう。
function getTabsArray(aTabBrowser) {
var tabs = getTabs(aTabBrowser);
var array = [];
for (var i = 0, maxi = tabs.snapshotLength; i < maxi; i++) {
array.push(tabs.snapshotItem(i).label);
}
return array;
}
特定のタブの「次のタブ」。
function getNextTab(aTab) {
return aTab.ownerDocument.evaluate(
'following-sibling::*[local-name()="tab"][1]',
aTab,
null,
XPathResult.FIRST_ORDERED_NODE_TYPE,
null
).singleNodeValue;
}
特定のタブの「前のタブ」。
function getPreviousTab(aTab) {
var tabs = aTab.ownerDocument.evaluate(
'preceding-sibling::*[local-name()="tab"]',
aTab,
null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
null
);
return tabs.snapshotItem(tabs.snapshotLength-1);
}
preceding-sibling
軸を使った時の返り値のノードの並びは軸方向の出現順ではなく文書順になるので、注意がいる。
function getPreviousTab(aTab) {
return aTab.ownerDocument.evaluate(
'preceding-sibling::*[local-name()="tab"][1]',
aTab,
null,
XPathResult.FIRST_ORDERED_NODE_TYPE,
null
).singleNodeValue;
}
タブの個数、最初のタブ、最後のタブも。
function getTabCount(aTabBowser) {
return aTabBrowser.ownerDocument.evaluate(
'count(descendant::*[local-name()="tab"])',
aTabBrowser.mTabContainer,
null,
XPathResult.NUMBER_TYPE,
null
).numberValue;
}
function getFirstTab(aTabBowser) {
return aTabBrowser.ownerDocument.evaluate(
'descendant::*[local-name()="tab"][1]',
aTabBrowser.mTabContainer,
null,
XPathResult.FIRST_ORDERED_NODE_TYPE,
null
).singleNodeValue;
}
function getLastTab(aTabBowser) {
return aTabBrowser.ownerDocument.evaluate(
'descendant::*[local-name()="tab"][last()]',
aTabBrowser.mTabContainer,
null,
XPathResult.FIRST_ORDERED_NODE_TYPE,
null
).singleNodeValue;
}
こういう時自分はついついXPathを使ってしまうんだけど、速度的にはどうなんだろう。ちゃんと計測してないから分からない。Array.slice(gBrowser.mTabContainer.childNodes).filter(function(aNode) { return aNode.localName == 'tab'; })
とかの方が普通に速かったらごめんなさい。
- ご使用に注意 - Mozilla Flux
- 今日のナイトリー - Another 朝顔日記
- Firefox 3.1のタブがぐちゃぐちゃに... - alice0775のファイル置き場 - Yahoo!ジオシティーズ
childNodes
を参照してるコードがヤバイというのはホントに酷い話だなあと思うけど、Google ChromeやIE7以降と同じユーザ体験を実現しようと思ったらどっかの時点でこれには手を出さなきゃいけなかった訳で、もうみんな腹括って粛々と受け入れるしかないんじゃないかと思うんだなあ僕は。
追記。例によってきっとガン無視されるだろうけどバグ立ててみた。
追記。どうやら僕が立てたバグに関しては杞憂だったみたい……そもそもこのエントリに書いた話も今回の修正以前から潜在的にはあった問題のようだし。むしろヤバイのはalice0775氏が着目してる問題で、実際のノードの並び順と表示される順番とが食い違うことがあるようだ。この手の問題は僕も過去にXBLで色々試してた時に遭遇して、諦めて「こういう事はしない」という風に自分ルールで決めた記憶がある。バックアウトするのもいいけど、そもそもこれはXBLの匿名内容のレイアウトに絡む根深い問題に起因してるようなので、ここらで誰かが本気出して低層の所を直してくれないことにはどうにもならん気がする。
26日追記。「実際のノードの並び順と表示される順番とが食い違う」件は、新しいNightlyを試したら再現しなくなった。僕の全面的な勘違いだったのか、それとも別の所で修正されたのか…… あとgetBrowser().mTabContainer.selectedIndex プロパティと getItemAtIndex メソッドじゃあダメなのかな
と言われたので調べてみたけど、現状のgetItemAtIndex()
はchildNodes.item()
のエイリアスに過ぎないようなので、やはり万全を期すなら別の手(このエントリに書いたような)を考えておいた方がいい気はする。
wikieditish message: Ready to edit this entry.