I think this should be nullable: https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/dom/webidl/Window.webidl#552
Very much so, given how it's handled in
Though it looks a bit spooky for chrome code to poke at a window in that state?
It's not really that hard. As an example, if you are poking a window from an iframe that was removed from the DOM, it's in that state.
I wish we got JS stacks from crash-stats; something like https://crash-stats.mozilla.org/report/index/b3f3dfc0-d2fc-4daf-be3d-9e8d40191120 would be legible with those. As it stands, what I can see is that we are firing
DOMContentLoaded, which queues a Promise resolution or rejection, which then runs the Promise handler, which then calls
PrecompiledScript::ExecuteInGlobal (and note, that at this point if the global is the window involved it could already have had its
FreeInnerObjects called by some other
DOMContentLoaded listener!) and then the chrome script pokes at
Bug 1577498 seems like it could be the culprit?
Well, it's definitely in the regression range from comment 12.
So, we can definitely make
getWindowGlobalChild() nullable, but then consumers need to check for null and deal with it, or at least check that they are OK with exceptions. Now luckily there just aren't that many consumers...
Tomislav, can any of the consumers added in bug 1577498 run at a point after the window's docshell has been torn down, do you know?