> 14754 [NNNNN] WARNING: NS_ENSURE_SUCCESS(EnsureScriptEnvironment(), nullptr) failed with result 0x80040111: file docshell/base/nsDocShell.cpp, line 4607 0x80040111 is NS_ERROR_NOT_AVAILABLE. This warning  is rather widespread across tests, it is most frequent during mochitest-browser-chrome-2, a few more verbose tests: > 97 warnings from test browser/components/sessionstore/test/browser_354894_perwindowpb.js > 76 warnings from test browser/components/sessionstore/test/browser_522545.js > 48 warnings from test browser/components/downloads/test/browser/browser_iframe_gone_mid_download.js It looks like this can happen if |mIsBeingDestroyed| is true  or if |do_GetInterface(mTreeOwner)| fails . Given the frequency of this warning it seems like we should just remove it (or possibly move it to |EnsureScriptEnvironment| where we can get a better idea of what is actually failing).  https://hg.mozilla.org/mozilla-central/annotate/02f640a72dcd/docshell/base/nsDocShell.cpp#l4607  https://hg.mozilla.org/mozilla-central/annotate/0b2f5e8b7be5/docshell/base/nsDocShell.cpp#l12780  https://hg.mozilla.org/mozilla-central/annotate/0b2f5e8b7be5/docshell/base/nsDocShell.cpp#l12795
Note: This is the most verbose warning during linux64 debug testing.
Attachment #8626364 - Flags: review?(bugs)
Comment on attachment 8626364 [details] [diff] [review] Stop warning if EnsureScriptEnvironment returns NS_ERROR_NOT_AVAILABLE I don't think it is useful to warn ever. So just return NS_SUCCEEDED(EnsureScriptEnvironment()) ? mScriptGlobal : nullptr; Or even EnsureScriptEnvironment(); return mScriptGlobal; But I think I'd prefer the first one.
Attachment #8626364 - Flags: review?(bugs) → review+
(In reply to Olli Pettay [:smaug] from comment #2) > Comment on attachment 8626364 [details] [diff] [review] > Stop warning if EnsureScriptEnvironment returns NS_ERROR_NOT_AVAILABLE > > I don't think it is useful to warn ever. > So just > > return NS_SUCCEEDED(EnsureScriptEnvironment()) ? mScriptGlobal : nullptr; > > Or even > EnsureScriptEnvironment(); > return mScriptGlobal; > > But I think I'd prefer the first one. Thanks for the quick review! I'll update to use the tristate.
You need to log in before you can comment on or make changes to this bug.