Open
Bug 1105450
Opened 10 years ago
Updated 2 years ago
Expose tabbrowser.xml's _getTabForContentWindow as public, with caveats
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
NEW
People
(Reporter: mconley, Unassigned)
Details
We should expose _getTabForContentWindow to outside consumers. jaws brings up the rationale in [1].
If we do this, we'll need to document that _getTabForContentWindow is potentially expensive with e10s with lots of tabs, and should be used sparingly.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=963358#c27
Comment 1•10 years ago
|
||
Well, this isn't any slower than using the publicly available getBrowserForDocument, right? There is no accompanying warning for that function.
Reporter | ||
Comment 2•10 years ago
|
||
I suppose? I guess I just look at that loop, and it's iterating a bunch of CPOWs, and I shudder - because that's a lot of potential sync IPC traffic. I think callers should know about that, since CPOWs are kind of subtle.
Comment 3•10 years ago
|
||
No disagreement, but we have quite a few paths that callers already hit this code. So I don't see the hold-up with making this path quicker to get to, since it's resultant is an already usable and meaningful object by the callers.
Comment 4•10 years ago
|
||
We shouldn't do this. We do not want to encourage people to call this and we should try to avoid it ourselves.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•