Open Bug 529477 Opened 15 years ago Updated 2 years ago

Provide a unique-per-session id for a tab in a tabbrowser

Categories

(Firefox :: Tabbed Browser, defect)

x86
Windows XP
defect

Tracking

()

People

(Reporter: johnjbarton, Unassigned)

References

Details

(Whiteboard: [firebug-p3])

A tab in a tabbrowser is a visual anchor for the user and a container of windows. Tools like Firebug need unique tag for a tab, to be able to insure that we can get back to the correct tab. Now that tabs can move between windows and across the tab any index is trouble. The linkedpanel id is what we use now, but Boris advises that this is fragile. One concrete use case is for out-of-process tools that need to refer to a tab known to their in-process counter part. We don't have any requirements on the id value other than unique. A solution that works well for jsd is "tag", ie tab.tag is an integer that is just the number of instances ever created in a session. http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/c24d77b1222f8b3f#
Whiteboard: [firebug-p3]
In particular, linkedPanel is NOT copied on tab move across windows, iirc...
Component: DOM: Core & HTML → Tabbed Browser
Product: Core → Firefox
QA Contact: general → tabbed.browser
(In reply to comment #0) > that we can get back to the correct tab. What does this mean?
(In reply to comment #2) > (In reply to comment #0) > > that we can get back to the correct tab. > > What does this mean? For tabs aTab and bTab, (aTab.tag === bTab.tag) means that (aTab === bTab) always.
Can you describe your use case? I tried to figure out what you're using getTabIdForWindow for, but failed to find something meaningful.
1) To associate a Firebug context with an nsIDOMWindow before we can access the window: http://code.google.com/p/fbug/source/browse/branches/firebug1.5/content/firebug/net.js#299 Some time after this we will discover a new nsIDOMWindow in that tab, then we track the window. 2) To determine that a window is not bound to a tab: http://code.google.com/p/fbug/source/browse/branches/firebug1.5/content/firebug/net.js#4092 There are other calls, but they seem to fall in to these two categories.
(In reply to comment #4) > Can you describe your use case? I tried to figure out what you're using > getTabIdForWindow for, but failed to find something meaningful. ...failed to find... means: "my search came up empty"? How are you searching? or "the code does not make sense"?
(In reply to comment #5) > 1) To associate a Firebug context with an nsIDOMWindow before we can access the > window: > http://code.google.com/p/fbug/source/browse/branches/firebug1.5/content/firebug/net.js#299 > Some time after this we will discover a new nsIDOMWindow in that tab, then we > track the window. That code seems to live in a browser window, it doesn't seem to deal with multiple browser windows. How does the fact that tabs can move between windows matter here? > 2) To determine that a window is not bound to a tab: > http://code.google.com/p/fbug/source/browse/branches/firebug1.5/content/firebug/net.js#4092 You can use getBrowserForDocument for that, can't you? (In reply to comment #6) > ...failed to find... means: "my search came up empty"? How are you searching? > or > "the code does not make sense"? Google code search didn't structure the results in a useful way, and I gave up after a dozen results that were just produced debug output.
(In reply to comment #7) > (In reply to comment #5) > > 1) To associate a Firebug context with an nsIDOMWindow before we can access the > > window: > > http://code.google.com/p/fbug/source/browse/branches/firebug1.5/content/firebug/net.js#299 > > Some time after this we will discover a new nsIDOMWindow in that tab, then we > > track the window. > > That code seems to live in a browser window, it doesn't seem to deal with > multiple browser windows. How does the fact that tabs can move between windows > matter here? We use linkedpanel now; Boris says we should not. That's why I opened the bug. Note that the original request includes the out-of-process use case, even though it is not in our code now. > > > 2) To determine that a window is not bound to a tab: > > http://code.google.com/p/fbug/source/browse/branches/firebug1.5/content/firebug/net.js#4092 > > You can use getBrowserForDocument for that, can't you? > > (In reply to comment #6) > > ...failed to find... means: "my search came up empty"? How are you searching? > > or > > "the code does not make sense"? > > Google code search didn't structure the results in a useful way, and I gave up > after a dozen results that were just produced debug output. Looks like the service at http://www.google.com/codesearch?hl=en does not search in firebug source code.
I would like to chime in and say that a unique tab id would be extremely useful for add-ons that spice up the tabbrowser, especially if that id were also stored with the nsISessionStore service. Some add-ons already assign their own unique ids to tabs, most prominently Tree Style Tab for maintaining parent-child relationships across sessions. I am following a similar pattern for tab grouping in Vertical Tabs. As of Bug 347930, tabs are no longer anonymous nodes so they could simply be assigned an 'id' attribute. This would allow easy access to tabs via id, and of course imply that the id is unique within a window. Uniqueness across windows could be guaranteed on top of that. Transferal of ids between windows as implied by John could be done as well, though possibly at the expense of not being able to use the 'id' attribute. (Depending on whether this would mean that a tab's 'id' attribute would have to be changed for this or not.) It would probably be better to dispatch an event when a tab is moved between windows instead so that extensions can do whatever they need to do to react. As this would simplify my own code a lot, I'd be willing to help with the implementation.
Is this still a valid RFE?
I suppose this can be marked as resolved. There is now tabs.id exposed via the SDK: https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/tabs#id
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.