User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.2.8) Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.2.8) Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8 https://bugzilla.mozilla.org/show_bug.cgi?id=582116 By this bug, APIs to control visibility of set of tabs become available. This API modifies the value of "hidden" attribute of tabs. "hidden" is based on CSS's "display:none", and changing of "display" property breaks DOM structure of the element. So, some addons have to re-initialize the tab when it becomes visible from invisible. Another case, some tab-related addons don't want to observe hidden tabs to save system performance. To start/stop observation of tabs automatically, we need an event which notifies changing of tab's visibility. For this purpose, "DOMAttrModified" is too generic. Reproducible: Always

Can I use setter for "hidden" property of each <tab> element?

(In reply to comment #0) > This API modifies the value of "hidden" attribute of tabs. "hidden" is based on > CSS's "display:none", and changing of "display" property breaks DOM structure > of the element. So, some addons have to re-initialize the tab when it becomes > visible from invisible. What do you mean by "re-initialize"? Styles will be applied automatically, but it won't be synchronously. What parts are you relying on being initialized?

I'm very sorry, I misunderstood the effect of hidden="true" (display:none) on two points. 1) Because <browser/> element was completely broken after changing hidden attribute true to false, I thought that any XUL element are broken by the attribute. 2) Because moving of tabs does modify the DOM structure, some addons such dynamically inserts custom DOM elements (canvas for thumbnail, etc.) have to re-initialize the moved tab by TabMove event. I confused hidden="true" with this.

Can we WONTFIX this, then?

I don't think so because this still there: > Another case, some tab-related addons don't want to observe hidden tabs to save > system performance. To start/stop observation of tabs automatically, we need an > event which notifies changing of tab's visibility. For this purpose, > "DOMAttrModified" is too generic.

The bookmark all tabs context menu item changes state based on TabOpen/Close notifications, so hiding all but one tab results in it not being correctly grayed out. Bug 585855. Should we be using a notification to track that?

Sounds like it. I suppose we could add TabHidden/TabUnhidden...

(In reply to comment #7) > Sounds like it. I suppose we could add TabHidden/TabUnhidden... Bug 585855 is doing this.

Fixed by bug 585855: TabShow/TabHide events are now fired on visibility changes.