See bug 1695560 comment #6.
It seems weird that a JAR channel used to load a file from onmi.js locally is cancelled at here.
Not sure if this is the expected behavior. Tentatively set the component to DOM:Navigation. Feel free to change it.

Hi Matt,

Do you probably have an idea here? Is this the expected behavior?

Thanks.

Unhiding comment #1 given that I'm pretty sure making it security private was a mistake.

STR:
Simply enable the logging by setting MOZ_LOG=nsJarProtocol:5 and execute firefox.
The log message below shows that the channel was cancelled with NS_ERROR_FAILURE.

[Parent 19420: Main Thread]: D/nsJarProtocol nsJARChannel::OnStopRequest [this=0x12f13c8d0 jar:file:///Users/changkershaw/work/gecko/objdir/dist/firefox/NightlyDebug.app/Contents/Resources/browser/omni.ja!/chrome/browser/res/activity-stream/prerendered/activity-stream-noscripts.html status=80004005]

from #ysod on Matrix - if the investigation were to show that this behavior is valid, I'd like to ask for changing the error status code for it to separate it out from generic NS_ERROR_FAILURE to make debugging easier and make it possible to filter this class of behaviors out of error monitoring.

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #4)

from #ysod on Matrix - if the investigation were to show that this behavior is valid, I'd like to ask for changing the error status code for it to separate it out from generic NS_ERROR_FAILURE to make debugging easier and make it possible to filter this class of behaviors out of error monitoring.

I've took a bit look and I think this behavior is valid. Based on the log below, I think DocumentChannel did what it supposed to do. The redirection is for process switch.

[Parent 89919: Main Thread]: V/DocumentChannel DocumentLoadListener OnStartRequest [this=0x1334eb040]
[Parent 89919: Main Thread]: D/nsStreamPump nsInputStreamPump::Suspend [this=0x132f13d00]
[Parent 89919: Main Thread]: V/DocumentChannel DocumentLoadListener MaybeTriggerProcessSwitch [this=0x1334eb040]
[Parent 89919: Main Thread]: V/DocumentChannel DocumentLoadListener GetRemoteTypeForPrincipal [this=0x1334eb040, contentParent=privilegedabout, preferredRemoteType=privilegedabout]
[Parent 89919: Main Thread]: V/DocumentChannel GetRemoteTypeForPrincipal -> current:privilegedabout remoteType:privilegedabout
[Parent 89919: Main Thread]: V/DocumentChannel Process Switch Abort: type (privilegedabout) is compatible
[Parent 89919: Main Thread]: V/DocumentChannel DocumentLoadListener::TriggerRedirectToRealChannel [this=0x1334eb040] aDestinationProcess=-1
[Parent 89919: Main Thread]: V/DocumentChannel DocumentLoadListener RedirectToRealChannel [this=0x1334eb040] aRedirectFlags=4, aLoadFlags=3d0004
[Parent 89919: Main Thread]: V/DocumentChannel DocumentLoadListener RedirectToRealChannel [this=0x1334eb040] mRedirectChannelId=8
[Child 89922: Main Thread]: V/DocumentChannel DocumentChannelChild RecvRedirectToRealChannel [this=0x1062d2280, uri=about:home]
[Child 89922: Main Thread]: V/DocumentChannel DocumentChannelChild OnRedirectVerifyCallback [this=0x1062d2280, aRv=0x00000000 ]

The reason why the channel is cancelled with NS_ERROR_FAILURE is there is no parent channel registered for this load. I think this is also valid, since JAR channel can be used directly in content process.

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #4)

from #ysod on Matrix - if the investigation were to show that this behavior is valid, I'd like to ask for changing the error status code for it to separate it out from generic NS_ERROR_FAILURE to make debugging easier and make it possible to filter this class of behaviors out of error monitoring.

I think this is the best we can do for now. I'd suggest to use NS_BINDING_ABORTED.

I think this is the best we can do for now. I'd suggest to use NS_BINDING_ABORTED.

The issue is that we also see a huge volume of NS_BINDING_ABORTED from various files and we have a strong reverse correlation of that event to YSOD.
If we add more to that event type I think it may be hard to siphon through it and isolate the type of NS_BINDING_ABORTED that causes real damage to the UI.

Is there a chance we could add a new error type that is indicating that it is a valid behavior?

Not sure if this is the expected behavior. Tentatively set the component to DOM:Navigation. Feel free to change it.

This is expected behavior.

Is there a chance we could add a new error type that is indicating that it is a valid behavior?

NS_BINDING_ABORTED is the right error when a channel is aborted, so I will morph this bug to be about returning NS_BINDING_ABORTED instead of generic NS_ERROR_FAILURE.

P3 because, IIUC, this error is not contributing to YSOD or getting in the way of debugging YSOD. If I misunderstood, please needinfo me!

It is not, but the problem we're facing is that we're seeing VERY LARGE volume of this error type and we know (bug 1696551) that some NS_BINDING_ABORTED predict YSOD.
So, one way to approach YSOD would be to try to chip away from "good" cases of NS_BINDING_ABORTED from "bad" cases and hope that all bad cases will be correlated with YSOD which would allow us to reason about it.

Adding more won't help, but maybe we just have to accept that a lot of network errors are actually "good" cases, and keep looking for ways to distinguish the "bad" cases. So yeah, I'm ok with this plan for the bug.