Closed Bug 1234232 Opened 10 years ago Closed 7 years ago

consider moving service worker controller from notification callbacks to nsILoadInfo

Categories

(Core :: DOM: Service Workers, defect, P5)

Product:
Core
Component:
DOM: Service Workers
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox46 --- affected

People

(Reporter: bkelly, Unassigned)

Details

(Whiteboard: [e10s-multi:-])

Currently the nsINetworkInterceptController is part of the channel notification callbacks. This can be problematic since the callbacks are periodically cleared by various channel consumers. Instead, we might want to put the controller on the nsILoadInfo so that its consistently available. I'm attaching this to our refactor bug for now since it might make sense to do at the same time.
I recently tried making a change similar to this and discovered its incompatible with our e10s necko code. We require that the controller is changed during redirect since the controller is the HttpChannelParent. So fixing this probably needs to happen after the e10s refactoring.
Blocks: ServiceWorkers-postv1
No longer blocks: ServiceWorkers-e10s
Depends on: ServiceWorkers-e10s
That just changed in bug 1219469; the controller is now the HttpChannelParentListener.
Oh, nice!
Blocks: ServiceWorkers-e10s
No longer blocks: ServiceWorkers-postv1
No longer depends on: ServiceWorkers-e10s
Whiteboard: [e10s-multi:-]
Priority: -- → P5
I don't think this is relevant in our current plan.
No longer blocks: ServiceWorkers-e10s
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.