if tab element is anonymous but tabpanels element is explicit then linkedPanel fails

NEW
Unassigned

Status

()

Core
XP Toolkit/Widgets: XUL
8 years ago
8 years ago

People

(Reporter: surkov, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
Currently linkedPanel on tab element is treated either as ID (if tab is explicit node) or as anonid (if tab is anonymous node). Since tabs element can live outside of tabbox element then tabs and tabpanels elements can be defined in different scopes, for example tabs element can be anonymous content of some XBL binding and tabpnales element can be explicit content (or be defined in different binding). In this case linkedPanel will be treated as pointing to anonid and therefore no chance to find tabpanels element. 

I'm not sure if anything can be done here to improve this. But probably it's worth to get attention.

Comment 1

8 years ago
The current code looks at the binding parent of the tab to see whether the panel is anonymous. It seems to me that it would make more sense to look at the binding parent of the tabpanels element.

For instance both the tabmail bindings used by Thunderbird and SeaMonkey uses anonymous tab elements but an explicit tabpanels element. Because the current code sees the tab is anonymous it looks for the linked panel in the tabmail anonymous content, but it's not there. (Note that I'm not sure that the appropriate tabbox properties are hooked up to allow the tabs to automatically find the panels and vice versa, so this might still need to be fixed.)
You need to log in before you can comment on or make changes to this bug.