We might want the nsIStremListener to receive OnStart/StopRequest off the main thread.
Unfortunately, all loaders except workers are touching the main thread eventually in child process.
Therefore, we can't have performance gain by saving event dispatching.
That reminds us of another motivation.
Workers could avoid touching the main thread with respect to spec and performance.
That's more attractive, but we found that OMT AsyncOpen could be a complicated piece.
If we want to avoid touching main thread in AsyncOpen., the lifecycle of nsHttpChannel could not depend on HttpChannelParent, i.e., no HttpChannelParent is created.
To achieve that, we need to move out most of the code from HttpChannelParent to HttpChannelBackgroundParent, including OS*R/ODA/OnProgress/..., which could break lots of things
Moreover, we prompt the events through ParentChannelListener, which implements several interfaces
That is, we need to let HttpChannelBackgroundParent handles those events, including service worker and auth prompt.
Otherwise, we need to reconsider the structure with DocumentChannel, that would be another long story.
However, I know you mention OMT ShouldIntercept is possible, but there's more dependency.
We still need to handle getAuthPrompt in HttpChannelBackgroundParent, which happens on the main thread.
Moreover, it also depends on appcache deprecation and child intercept in the child side (bug 1639433 comment 0)
And even more, we need to handle all the races in comment 1
Touching any one of the IPC message which needs to wait HttpChannelParent could not have performance gain.
The most inevitable one is redirect, we have permission check/content security check/... in both threads, which is on the main thread now.
Not sure how much work on them.
On the other hand, workers is planned to have its own PFetch IPC which is managed by PBackground (see Bug 1613912 comment 4)
It might be not a strong motivation to avoid touching main thread for all necko requests.