Enable interception of beacons through service workers

RESOLVED FIXED in Firefox 39

Status

()

defect
RESOLVED FIXED
5 years ago
5 months ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

unspecified
mozilla39
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox39 fixed)

Details

Attachments

(1 attachment)

Currently when sending a beacon, HttpBaseChannel::ShouldIntercept tries to get access to the nsINetworkInterceptController interface through the channel's notification callbacks, but in this case the notification callback is the nsCORSListenerProxy object (thanks to nsCORSListenerProxy::Init).

nsCORSListenerProxy already knows how to forward calls to nsIInterfaceRequestor::GetInterface to mOuterNotificationCallbacks, and ShouldIntercept calls GetInterfce.  But mOuterNotificationCallbacks is set by default to the callbacks of the channel at the time nsCORSListenerProxy is called, and the callbacks on this channel is intentionally null, so ShouldIntercept bails out and the beacon never gets intercepted.

I'm planning to extend nsCORSListenerProxy to make it aware of nsINetworkInterceptController, and have it route the request for nsINetworkInterceptController correctly to the docshell without the need to mess with the notification callbacks.
Blocks: 1121157
Assignee: nobody → ehsan
Currently when sending a beacon, HttpBaseChannel::ShouldIntercept tries
to get access to the nsINetworkInterceptController interface through the
channel's notification callbacks, but in this case the notification
callback is the nsCORSListenerProxy object (thanks to
nsCORSListenerProxy::Init).

nsCORSListenerProxy already knows how to forward calls to
nsIInterfaceRequestor::GetInterface to mOuterNotificationCallbacks, and
ShouldIntercept calls GetInterfce.  But mOuterNotificationCallbacks is
set by default to the callbacks of the channel at the time
nsCORSListenerProxy is called, and the callbacks on this channel is
intentionally null, so ShouldIntercept bails out and the beacon never
gets intercepted.

This patch extends nsCORSListenerProxy to make it aware of
nsINetworkInterceptController, and have it route the request for
nsINetworkInterceptController correctly to the docshell without the need
to mess with the notification callbacks.

This will be tested in bug 1147699.
Attachment #8583515 - Flags: review?(nsm.nikhil)
https://hg.mozilla.org/mozilla-central/rev/256a54bc4d96
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.