1585950 - Add a method for getting BrowserParent* from CanonicalBrowsingContext

Status: RESOLVED INACTIVE

(Core :: DOM: Navigation, enhancement, P2)

Description

[Henri Sivonen (:hsivonen)]

It appears that CanonicalBrowsingContext can only report its associated ContentParent. Those CanonicalBrowsingContexts that represent top-level Web content or the content top-most under an out-of-process iframe boundary logically map to BrowserParents, too.

There should be a way to obtain that BrowserParent.

(Use case: IME and keyboard routing combined with mouse-changed focus, since we route those via BrowserParent rather than ContentParent. It might be possible to switch over to ContentParent, but I don't really want to make that level of change to IME code again.)

How would I go about finding the BrowserParent given a CanonicalBrowsingContext?

Comment 1

[Henri Sivonen (:hsivonen)]

I guess I'll add a field instead of trying to navigate the object graph.

Comment 2

[Henri Sivonen (:hsivonen)]

https://searchfox.org/mozilla-central/rev/35cc00a25c4471993fdaa5761952bd3afd4f1731/dom/ipc/WindowGlobalParent.cpp#350 looks like it overwrites the process id anyway just in case even when we aren't moving to the in-process case.

Is that the only place where a CanonicalBrowsingContext can transition from being the top-most browsing context in an out-of-process iframe into being in an in-process iframe? How do I detect the case where a previously-out-of-process CanonicalBrowsingContext becomes an in-process one and needs to lose its BrowserParent association without getting a new one?

Comment 3

[Henri Sivonen (:hsivonen)]

Attachment: Bug 1585950 - Add a method for getting BrowserParent* from CanonicalBrowsingContext.

Comment 4

[Nika Layzell [:nika] (ni? for response)]

As we chatted on IRC, this should be possible to get with GetCurrentWindowGlobal()->GetBrowserParent() :-). In addition, we should probably hold off on landing a patch touching the process switch code until I get enough time to land bug 1576714.

It would probably be worthwhile adding an explicit GetBrowserParent() on CanonicalBrowsingContext which does that dance for you to avoid confusion in the future.

Comment 5

[Chris Peterson [:cpeterson]]

Roll some unfixed bugs from Fission Milestone M4 to M5

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732

Comment 6

[Chris Peterson [:cpeterson]]

Future because this helper function doesn't block Fission MVP.

Comment 7

[Henri Sivonen (:hsivonen)]

I have a case in the parent process where I have a BrowsingContext that I know to be out-of-process. I then call Top() on that BrowsingContext and GetCurrentWindowGlobal() on what Top() returned (the BrowsingContext it returned is also out-of-process). I get nullptr. What does that mean? Is there a more robust way to get BrowserParent from an out-of-process BrowsingContext?

Comment 8

[Andreas Farre [:farre]]

So I guess that the BrowsingContext might've been discarded, or the WindowGlobalParent destroyed. Otherwise every CanonicalBrowsingContext should have a current WindowGlobalParent. Or maybe if we're changing the remoteness status. In any case, getting the BrowsingParent the way you describe is the correct way.

Comment 9

[Henri Sivonen (:hsivonen)]

Or maybe if we're changing the remoteness status.

In what situation can a top-level BrowsingContext change remoteness?

Comment 10

[Andreas Farre [:farre]]

I think that doing a window.open('b.com') from a.com will create a new BrowsingContext in the a.com process, and then switch it to the b.com process on loading.

Comment 11

[Henri Sivonen (:hsivonen)]

I was able to proceed without this.