Looks like frame construction gets confused about where the frame for the tabpanel goes.... In particular, the problem is that the XBL inserts a spacer at the beginning of the child list of the <tabs> and that in nsCSSFrameConstructor::ContentInserted we call nsCSSFrameConstructor::FindPreviousSibling to find the previous sibling. But we use aIndexInContainer as the place to start looking, and our index in the content iterator is actually one larger (because of the anonymous content XBL inserted). See the XXX comment before the FindPreviousSibling() call in ContentInserted(); that's biting us here, basically.
I think the best thing to do here would be to make GetInsertionPoint() return not only the insertion point but also the index of the content in the insertion point.... That would replace aIndexInContainer for the following manipulations, then. Alternately, we need to fix FindPreviousSibling() to not start with aIndexInContainer, since that can end up bogus. Thoughts?
A hack(?) would be to wrap the tabs <children> with <hbox>, which has the added side-effect of making ordinal on <tab>s work as expected (since consumers don't have to understand the spacers on the ends of the <tabs>). Of course, doing that causes crashes (why wouldn't it? eXtremely Unstable Languages are the best!), so I'm not going to pursue cleaning up the theme to look right.
(In reply to comment #6) >A hack(?) would be to wrap the tabs <children> with <hbox> Unfortunately this stops the tabs from flexing properly, so it's no use.
I'm pretty sure setting .collapsed instead should mitigate these problems (at least some of them).
Fixed by checkin for bug 307394. Checked in test.