Interesting. That return value is definitely not ever used. This doesn't appear to be a recent change.
From my quick look over this, it appears that this method can fail in a couple of ways:
nsIInputStream to produce the header stream data fails
- The header stream data is malformed, or
- Setting a header on the
However, there is actually only a single codepath which can cause a headers stream to be set on a navigation like this, all other calls either use
nullptr, or are simply forwarding the value around. That one codepath is here: https://searchfox.org/mozilla-central/rev/ddb81c7a43ffada1f6cb4200c4f625e50e44dcf3/dom/plugins/base/nsPluginInstanceOwner.cpp#450-453
nsIInputStream doesn't actually need to be one here, as the value being passed in is always a string input stream, which was derived from a
const char* value passed to us by an NPAPI plugin.
Looking at the callsites of that method, it looks even weirder - tracing stuff back even further, and trimming off branches which just pass in
nullptr, it looks like https://searchfox.org/mozilla-central/rev/ddb81c7a43ffada1f6cb4200c4f625e50e44dcf3/dom/plugins/base/nsPluginHost.cpp#639-640 is the only callsite which would pass a value in, though its only callsite also passes in
nullptr for the headers parameter: https://searchfox.org/mozilla-central/rev/ddb81c7a43ffada1f6cb4200c4f625e50e44dcf3/dom/plugins/base/nsNPAPIPlugin.cpp#368
In summary, I think that it is currently impossible to set a
HeadersChannel on an
nsDocShell load, and that the feature only existed for legacy NPAPI features which have since been removed, so this isn't an issue, but rather a sign of dead code.
ni? :bz for thoughts and potentially more context.