1981758 - Crash in [@ mozilla::dom::syncedcontext::Transaction<T>::Commit | mozilla::dom::BrowsingContext::SetOpenerPolicy]

Status: NEW

(Core :: DOM: Navigation, defect, P3)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Not a new signature, fixed once before in bug 1834864. 800 crash reports from 300 installs for Firefox for Android 141.0.x so far.

Olli, please triage this.

Crash report: https://crash-stats.mozilla.org/report/index/ccd0ed21-3bf9-4181-9611-282090250807

MOZ_CRASH Reason:

CanSet failed for field(s): OpenerPolicy

Top 10 frames:

0  libxul.so  MOZ_CrashSequence(void*, long)  mfbt/Assertions.h:253
0  libxul.so  MOZ_Crash(char const*, int, char const*)  mfbt/Assertions.h:381
0  libxul.so  mozilla::dom::syncedcontext::Transaction<mozilla::dom::BrowsingContext>::Comm...  docshell/base/SyncedContextInlines.h:103
1  libxul.so  mozilla::dom::BrowsingContext::SetOpenerPolicy(nsILoadInfo::CrossOriginOpener...  docshell/base/BrowsingContext.h:300
2  libxul.so  mozilla::dom::Document::StartDocumentLoad(char const*, nsIChannel*, nsILoadGr...  dom/base/Document.cpp:3654
3  libxul.so  nsHTMLDocument::StartDocumentLoad(char const*, nsIChannel*, nsILoadGroup*, ns...  dom/html/nsHTMLDocument.cpp:349
4  libxul.so  nsContentDLF::CreateDocument(char const*, nsIChannel*, nsILoadGroup*, nsIDocS...  layout/build/nsContentDLF.cpp:323
4  libxul.so  nsContentDLF::CreateInstance(char const*, nsIChannel*, nsILoadGroup*, nsTSubs...  layout/build/nsContentDLF.cpp:0
5  libxul.so  nsDocShell::NewDocumentViewerObj(nsTSubstring<char> const&, nsIRequest*, nsIL...  docshell/base/nsDocShell.cpp:8102
5  libxul.so  nsDocShell::CreateDocumentViewer(nsTSubstring<char> const&, nsIRequest*, nsIS...  docshell/base/nsDocShell.cpp:7863

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 AArch64 and ARM crashes on release

For more information, please visit BugBot documentation.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

nika, you might have some of this still in your mind.
If not, give this back to me.

Comment 3

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

The condition which is failing here is this one: https://searchfox.org/firefox-main/rev/d683b2b2ed86192b3a87150c21fc51ba02a93142/docshell/base/BrowsingContext.cpp#3377-3390

bool BrowsingContext::CanSet(FieldIndex<IDX_OpenerPolicy>,
                             nsILoadInfo::CrossOriginOpenerPolicy aPolicy,
                             ContentParent* aSource) {
  // A potentially cross-origin isolated BC can't change opener policy, nor can
  // a BC become potentially cross-origin isolated. An unchanged policy is
  // always OK.
  return GetOpenerPolicy() == aPolicy ||
         (GetOpenerPolicy() !=
              nsILoadInfo::
                  OPENER_POLICY_SAME_ORIGIN_EMBEDDER_POLICY_REQUIRE_CORP &&
          aPolicy !=
              nsILoadInfo::
                  OPENER_POLICY_SAME_ORIGIN_EMBEDDER_POLICY_REQUIRE_CORP);
}

Effectively it appears we are attempting to set the opener policy on a BrowsingContext in a way which is changing it either from OPENER_POLICY_SAME_ORIGIN_EMBEDDER_POLICY_REQUIRE_CORP to non-OPENER_POLICY_SAME_ORIGIN_EMBEDDER_POLICY_REQUIRE_CORP or vice-versa. This is rejected as this particular opener policy flag corresponds to us isolating the BrowsingContextGroup into a different BCG, and we shouldn't be able to mix the opener policy flags.

Some notes:

• In the crash we are currently within an isolated content process (webCOOP+COEP), which makes me think that perhaps we're trying to un-set the OPENER_POLICY_SAME_ORIGIN_EMBEDDER_POLICY_REQUIRE_CORP opener policy on the BrowsingContext.
• We don't enter the code to set the opener policy unless the channel is a nsIHTTPChannelInternal, meaning that this must be a HTTP load.
• On the stack, the caller of nsDocumentOpenInfo::OnStartRequest is in JS, and higher up the stack the callback is being performed in response to a load from a nsJARChannel.
• The two above points combine to suggest that we're loading either the PDF.js viewer or the JSON viewer, both of which use a stream converter implemented in JS to replace the normal HTTP channel response with a file loaded from the Omnijar.

---

TL;DR I think it's probably worth investigating whether we hit this crash in various situations involving loading a PDF or JSON file in a toplevel BrowsingContext which is cross-origin isolated using the COOP and COEP headers. There is a chance that we're missing some check or another in that case, and end up improperly isolating them.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit BugBot documentation.

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hey Olli, can you please continue investigating based on comment 3? Thank you.