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
•