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)

x86
All
defect

Tracking

()

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
Well, this isn't any slower than using the publicly available getBrowserForDocument, right? There is no accompanying warning for that function.
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.
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.
We shouldn't do this. We do not want to encourage people to call this and we should try to avoid it ourselves.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.