Add BrowsingContext::GetParentCrossChromeBoundaryInParent
Categories
(Core :: DOM: Core & HTML, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox77 | --- | fixed |
People
(Reporter: hsivonen, Assigned: nika)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
I have on multiple occasions encountered code that if simply rewritten from nsIDocShellTreeItem to BrowsingContext fails a bunch of mochitest-browser-chrome tests.
I have left the old code path in place for the chrome process.
The easiest way to get rid of nsIDocShellTreeItem in those cases would be to introduce a method on BrowsingContext that in content processes behaves like GetParent and in the chrome process, if GetParent would return nullptr for a Web content BrowsingContext instead returns the embedder chrome BrowsingContext.
| Assignee | ||
Comment 1•5 years ago
|
||
Updated•5 years ago
|
Comment 3•5 years ago
|
||
| bugherder | ||
| Reporter | ||
Comment 4•5 years ago
|
||
Was it intentional to put this on CanonicalBrowsingContext instead of BrowsingContext per comment 0?
| Assignee | ||
Comment 5•5 years ago
|
||
Yes. It's not possible to cross the content/chrome boundary in content processes, which means that this method would be misleading or useless in content processes, so I only included it on CanonicalBrowsingContext.
| Reporter | ||
Comment 6•5 years ago
|
||
I agree that it could be misleading, but it wouldn't be useless when the goal is to pass existing mochitest-browser-chrome tests that expect otherwise the same kind of walk to walk across the XUL boundary in the chrome process and not to in the content processes.
| Assignee | ||
Comment 7•5 years ago
|
||
Cases like that seem uncommon and specialized, and the behaviour could be easily performed at such call-sites, by doing something like:
RefPtr<BrowsingContext> parent = bc->GetParent();
if (!parent && XRE_IsParentProcess()) {
parent = bc->Canonical()->GetParentCrossChromeBoundary();
}
Description
•