Closed
Bug 584263
Opened 15 years ago
Closed 15 years ago
Need a way to notify changing of tab's visibility
Categories
(Firefox :: Tabbed Browser, enhancement)
Firefox
Tabbed Browser
Tracking
()
RESOLVED
FIXED
Firefox 4.0b4
People
(Reporter: yuki, Unassigned)
References
()
Details
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
Reporter | ||
Comment 1•15 years ago
|
||
Can I use setter for "hidden" property of each <tab> element?
Comment 2•15 years ago
|
||
(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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 3•15 years ago
|
||
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.
Comment 4•15 years ago
|
||
Can we WONTFIX this, then?
Reporter | ||
Comment 5•15 years ago
|
||
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.
Comment 6•15 years ago
|
||
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?
Blocks: 585855
Comment 7•15 years ago
|
||
Sounds like it. I suppose we could add TabHidden/TabUnhidden...
Target Milestone: --- → Firefox 4.0b3
Updated•15 years ago
|
Target Milestone: Firefox 4.0b3 → ---
Comment 8•15 years ago
|
||
(In reply to comment #7)
> Sounds like it. I suppose we could add TabHidden/TabUnhidden...
Bug 585855 is doing this.
Comment 9•15 years ago
|
||
Fixed by bug 585855: TabShow/TabHide events are now fired on visibility changes.
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: dev-doc-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b4
Updated•15 years ago
|
Keywords: dev-doc-needed
You need to log in
before you can comment on or make changes to this bug.
Description
•