Closed Bug 1459209 Opened Last year Closed Last year

Add an IPC-based inner implementation of service worker binding objects

Categories

(Core :: DOM: Service Workers, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: bkelly, Assigned: mrbkap)

References

(Blocks 3 open bugs)

Details

(Whiteboard: SW-MUST)

Attachments

(15 files, 34 obsolete files)

38.01 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
13.70 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
16.23 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
14.79 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
8.70 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
11.24 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
6.07 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
7.60 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
10.12 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
7.73 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
5.01 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
8.50 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
7.47 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
8.31 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
6.92 KB, patch
mrbkap
: review+
Details | Diff | Splinter Review
Now that the service worker binding objects have been split into inner and outer objects we can start implementing remoting.  This bug will add the initial implementation of IPC-based inner objects.
Priority: -- → P2
Depends on: 1460635
Updated wip patch.  I need to pause this, though, to fix bug 1460635 first.
Attachment #8974433 - Attachment is obsolete: true
With this I can flip the pref and successfully register a service worker.  Still some more bits to implement before this bug is done, though.
This should complete the plumbing of the binding objects across the IPC boundary.  Still more work to do before tests will pass with this turned on, though.  I need to do some fixes to the controller handler.

Let's make sure these patches don't break anything in the current legacy mode:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=759df7e337a038c6051da2994f0018dba62a970d
Andrea, I'm going to summarize the overall design of the code in this comment.  I'll then refer back to this comment when I flag for review for each patch.

The overall goal is to build IPC-based implementations for the service worker binding objects.  This means IPC-based implementations for:

* ServiceWorker::Inner
* ServiceWorkerRegistration::Inner
* ServiceWorkerContainer::Inner

The implementation for each of these will follow the same pattern.  Each implementation has:

1. A Remote*Impl class that directly implements the Inner interface.
2. A PBackground-based actor created by the Remote*Impl class.  Each of these actors is managed by PBackground since you can get all of the binding objects individually.  (For example, the MessageEvent.source can be a ServiceWorker, ServiceWorkerGlobalScope.registration is a ServiceWorkerRegistration, and of course the container is always top level.)
3. A Proxy class that is created by the parent-side actor to communicate with the ServiceWorkerManager on the main thread.  This is only strictly needed for ServiceWorker and ServiceWorkerRegistration, but I create this for the container as well to keep the design the same.  It doesn't cause any harm and might be useful in the future.
Comment on attachment 8974804 [details] [diff] [review]
P1 Add IPC actor boilerplate for PServiceWorker, PServiceWorkerContainer, and PServiceWorkerRegistration. r=baku

This patch is pure boilerplate to scaffold the three PBackground actor types.  Later patches will add the functional messages to the ipdl interfaces.
Attachment #8974804 - Flags: review?(amarchesini)
Comment on attachment 8974805 [details] [diff] [review]
P2 Implement RemoteServiceWorkerImpl to connect the binding ServiceWorker to the PServiceWorkerChild actor. r=baku

As discussed in comment 35 we need a class that implements the binding layer's Inner interface.  This patch adds RemoteServiceWorkerImpl to implement ServiceWorker::Inner.

Note I am using WorkerHolderToken here and for the other actors because I need the AllowIdleShutdown behavior.  These actors are created when the binding object is instantiated and continue to stay alive even if no operation is being performed.  The existence of the actor should not block worker shutdown.

I also am basically carrying forward my favored pattern of a separate non-ref-counted actor attached to an outer ref-counted owner.  They reference each other with weak pointers so that either one can be destroyed first.  This is basically the same as what I used in Cache API and Clients API.  I decided the ClientThing base type didn't provide much value in the end, so I did not try to use a similar abstraction here.
Attachment #8974805 - Flags: review?(amarchesini)
Comment on attachment 8974807 [details] [diff] [review]
P3 Scaffold RemoteServiceWorkerContainerImpl to connect the binding ServiceWorkerContainer to the PServiceWorkerContainerChild actor. r=baku

This adds the RemoteServiceWorkerContainerImpl class to implement the ServiceWorkerContainer::Inner interface.  The description for the P2 patch basically applies here as well.

I should also mention this is still just scaffolding.  The functional methods will be filled in individually in later patches.
Attachment #8974807 - Flags: review?(amarchesini)
Comment on attachment 8974808 [details] [diff] [review]
P4 Scaffold RemoteServiceWorkerRegistrationImpl to connect the binding registration to the actor. r=baku

This adds scaffolding for the last Inner implementation.  In this case its RemoteServiceWorkerRegistrationImpl.
Attachment #8974808 - Flags: review?(amarchesini)
Comment on attachment 8974829 [details] [diff] [review]
P5 Scaffold a ServiceWorkerProxy class to connect the parent actor to the main thread SWM. r=baku

This patch scaffolds the ServiceWorkerProxy to connect the ServiceWorkerParent to the main thread ServiceWorkerManager guts.

This is a ref-counted object owned initially by the actor.  It also must listen for ServiceWorkerInfo updates, so its also ref-ed on the main thread.  This means the class must handle being destroyed on either thread.  The proxy must also handle the actor being destroyed before the proxy.
Attachment #8974829 - Flags: review?(amarchesini)
Comment on attachment 8975041 [details] [diff] [review]
P6 Scaffold a ServiceWorkerRegistrationProxy class to connect the parent actor to the main thread SWM. r=baku

This scaffolds the ServiceWorkerRegistrationProxy to connect the PBackground ServiceWorkerRegistrationParent actor to the main thread SWM.  It basically has the same design as the proxy class in the P5 patch.
Attachment #8975041 - Flags: review?(amarchesini)
Comment on attachment 8975071 [details] [diff] [review]
P7 Scaffold a ServiceWorkerContainerProxy class to connect the parent actor to the main thread SWM. r=baku

This scaffolds a ServiceWorkerContainerProxy class.  This ends up being less useful because right now we are not listening for any general events for the container.  Things like controllerchange event come through a different path.

I chose to keep this class for now since it keeps the design the same for all the binding objects.  Also, I might want to use it for the controllerchange stuff in the future.  I need to think about that some more.
Attachment #8975071 - Flags: review?(amarchesini)
Comment on attachment 8975125 [details] [diff] [review]
P8 Implement RemoteServiceWorkerImpl::PostMessage() across IPC and to the parent-side SWM. r=baku

This patch implements the first piece of actual functionality.  It plumbs the ServiceWorker.postMessage() call through the various layers.  Its pretty straightforward since the caller doesn't need to know if/when the postMessage completes.
Attachment #8975125 - Flags: review?(amarchesini)
Comment on attachment 8975128 [details] [diff] [review]
P9 Implement ServiceWorkerInfo::Listener::SetState() across back to the child-side binding layer. r=baku

This patch propagates any ServiceWorker.state value changes back from the ServiceWorkerInfo to the binding layer ServiceWorker object.  This will automatically trigger statechange events when appropriate.
Attachment #8975128 - Flags: review?(amarchesini)
Comment on attachment 8975143 [details] [diff] [review]
P10 Fix CopyableErrorResult::operator==() to actually compile with ipdl types. r=baku

For the upcoming patches I want to be able to use CopyableErrorResult in an ipdl union type.  Unfortunately I botched the copy constructor a bit in bug 1357463.  This patch fixes it by making the copy constructors const and implementing them in the cpp where the types are defined.

Boris gave me approval on IRC to have you review this patch.
Attachment #8975143 - Flags: review?(amarchesini)
Comment on attachment 8975575 [details] [diff] [review]
P11 Implement RemoteServiceWorkerRegistrationImpl::Update() across IPC to the parent-side SWM. r=baku

This patch implements the ServiceWorkerRegistration.update() method.  Its the first case where we need to actually plumb back a promise reaction value.

To do this I decided to use the new ipdl async method with a return value.  This avoids the need to create any "op" actors.  On the calling side this means I can just use lambda callbacks to populate and resolve the MozPromise that was returned to the binding layer.

On the receiving side we get a handy resolver function.  This must be called on the PBackground thread (AFAICT), but its very handy in that it automatically deals with the destruction of the actor using an internal WeakPtr<>.  So we don't have to worry about tracking the ActorDestroy ourselves.

To connect to the main thread I have the proxy method return a MozPromise.  The parent actor calls Then() with the PBackground thread and simply forwards the result to the resolver.

This turned out surprisingly clean (I think).  My main annoyance is that I can't use a single MozPromise type throughout.  There is some boilerplate to convert between types at each stage thanks to ipdl requirements.
Attachment #8975575 - Flags: review?(amarchesini)
Comment on attachment 8975603 [details] [diff] [review]
P12 Implement RemoteServiceWorkerRegistrationImpl::Unregister() across IPC to the parent-side SWM. r=baku

This implements the ServiceWorkerRegistration.unregister() method.  It basically uses the same design as the P11 patch.  The main difference is that we are not returning a ServiceWorkerRegistration as a result.  Instead we are basically doing a GenericPromise.

Rather than define a new ipdl type for "bool or error" I tried using the tuple support.  Its a bit awkward but works.

Note, the ResolveUnregister() helper function ServiceWorkerRegistrationParent.cpp is mainly there to work around some tuple nonsense.  The MakeTuple() helper function wants to produce Tuple<bool, CopyableErrorResult>, but ipdl insanely wants Tuple<const bool&, const CopyableErrorResult&>.  Forcing through a helper function let me satisfy ipdl.
Attachment #8975603 - Flags: review?(amarchesini)
Comment on attachment 8975609 [details] [diff] [review]
P13 Propagate ServiceWorkerRegistration updatefound events from the parent across IPC to the child. r=baku

This patch propagates updatefound events back to the binding layer.  Its pretty straightforward.
Attachment #8975609 - Flags: review?(amarchesini)
Comment on attachment 8975623 [details] [diff] [review]
P14 Propogate registration state changes back from the parent to the child. r=baku

This patch propagates changes to the ServiceWorkerRegistrationDescriptor back to the binding layer.  This is what updates the registration.installing, .waiting, and .active getter values.  Its pretty straightforward.
Attachment #8975623 - Flags: review?(amarchesini)
Comment on attachment 8975634 [details] [diff] [review]
P15 Implement RemoteServiceWorkerContainerImpl::Register() across IPC to the parent-side SWM. r=baku

This patch implements the ServiceWorkerContainer.register() method.  Its design is pretty similar to the update() and unregister() patches.  The proxy code is even more straightforward because we can simply use the MozPromise ChainTo() method.
Attachment #8975634 - Flags: review?(amarchesini)
Comment on attachment 8975640 [details] [diff] [review]
P16 Allow ServiceWorkerParentInterceptEnabled() to be used off-main-thread. r=baku

While testing the code to this point I realized I needed to allow ServiceWorkerParentInterceptEnabled() to be used on worker threads.  I added a call to this on worker threads effectively when I plumbed the new Inner implementation for the registration.

I know we have a new pref system in the tree.  I want to wait to try using it for now.  I expect I'll need to make some more changes to the prefs soon.  I'll do that in a separate bug.
Attachment #8975640 - Flags: review?(amarchesini)
Comment on attachment 8975935 [details] [diff] [review]
P17 Implement RemoteServiceWorkerContainerImpl::GetRegistration() across IPC to the parent-side SWM. r=baku

This implements ServiceWorkerContainer.getRegistration().  Same basic design as register().
Attachment #8975935 - Flags: review?(amarchesini)
Comment on attachment 8975955 [details] [diff] [review]
P18 Implement RemoteServiceWorkerContainerImpl::GetRegistrations() across IPC to the parent-side SWM. r=baku

This implements ServiceWorkerContainer.getRegistrations() to retrieve a list of registrations.  Same basic design, but with a different result type.
Attachment #8975955 - Flags: review?(amarchesini)
Comment on attachment 8975960 [details] [diff] [review]
P19 Implement RemoteServiceWorkerContainerImpl::GetReady() across IPC to the parent-side SWM. r=baku

Finally, this implements the ServiceWorkerContainer.ready promise.  Same design as register(), getRegistration(), etc.  This should look pretty familiar now.
Attachment #8975960 - Flags: review?(amarchesini)
Blocks: 1462069
Attachment #8974804 - Flags: review?(amarchesini) → review+
Blocks: 1462460
Blocks: 1462466
Blocks: 1462467
Comment on attachment 8975125 [details] [diff] [review]
P8 Implement RemoteServiceWorkerImpl::PostMessage() across IPC and to the parent-side SWM. r=baku

Review of attachment 8975125 [details] [diff] [review]:
-----------------------------------------------------------------

Note, there are some problems with this patch.  This does not harm our default config right now since this is pref'd off by default.  I will fix the problems in the follow-on bug 1462466.
I've found a number of issues with the patches here when running tests.  I had originally thought maybe this stuff could land since its behind a pref and incrementally fix the tests, but I think I will now just drop the flags and try to get it in a passing state before flagging for review again.  A number of follow-on bugs will probably get folded in here.
Attachment #8974805 - Flags: review?(amarchesini)
Attachment #8974807 - Flags: review?(amarchesini)
Attachment #8974808 - Flags: review?(amarchesini)
Attachment #8974829 - Flags: review?(amarchesini)
Attachment #8975041 - Flags: review?(amarchesini)
Attachment #8975071 - Flags: review?(amarchesini)
Attachment #8975125 - Flags: review?(amarchesini)
Attachment #8975128 - Flags: review?(amarchesini)
Attachment #8975143 - Flags: review?(amarchesini)
Attachment #8975575 - Flags: review?(amarchesini)
Attachment #8975603 - Flags: review?(amarchesini)
Attachment #8975609 - Flags: review?(amarchesini)
Attachment #8975623 - Flags: review?(amarchesini)
Attachment #8975634 - Flags: review?(amarchesini)
Attachment #8975640 - Flags: review?(amarchesini)
Attachment #8975935 - Flags: review?(amarchesini)
Attachment #8975955 - Flags: review?(amarchesini)
Attachment #8975960 - Flags: review?(amarchesini)
One of the issues I've found is that the extra runnable introduced by using MozPromise can create races when updating state variables.  We need very precise numbers of runnables in all cases.  So I need to refactor the Inner interfaces to use callbacks instead of MozPromise.
Attachment #8975640 - Attachment is obsolete: true
No longer blocks: 1462069
Depends on: 1466681
Whiteboard: SW-MUST
No longer blocks: 1462466
Depends on: 1462466
No longer blocks: 1462467
Depends on: 1471303
Depends on: 1462772
Depends on: 1471631
Depends on: 1471706
Depends on: 1471912
Depends on: 1471929
Depends on: 1472005
Depends on: 1472008
Attachment #8974804 - Attachment is obsolete: true
Attachment #8974805 - Attachment is obsolete: true
Attachment #8974807 - Attachment is obsolete: true
Attachment #8974808 - Attachment is obsolete: true
Attachment #8974829 - Attachment is obsolete: true
Attachment #8975041 - Attachment is obsolete: true
Attachment #8975071 - Attachment is obsolete: true
Attachment #8975125 - Attachment is obsolete: true
Attachment #8975128 - Attachment is obsolete: true
Attachment #8975143 - Attachment is obsolete: true
Attachment #8975575 - Attachment is obsolete: true
Attachment #8975603 - Attachment is obsolete: true
Attachment #8975609 - Attachment is obsolete: true
Attachment #8975623 - Attachment is obsolete: true
Attachment #8975634 - Attachment is obsolete: true
Attachment #8975935 - Attachment is obsolete: true
Attachment #8975955 - Attachment is obsolete: true
Attachment #8975960 - Attachment is obsolete: true
Comment on attachment 8988822 [details] [diff] [review]
P1 Add IPC actor boilerplate for PServiceWorker, PServiceWorkerContainer, and PServiceWorkerRegistration. r=mrbkap

Blake, please see comment 35 for background and overall design summary.

This patch scaffolds out 3 different actors.  One for each type of binding object:

* PServiceWorkerContainer
* PServiceWorkerRegistration
* PServiceWorker

This is pretty much all boilerplate.

Note, there are some existing IPC actors for service workers that are related to propagating state between multiple processes.  I purposely avoid building on top of those so that its easier to remove the legacy code after things switch over to the new system.
Attachment #8988822 - Flags: review?(mrbkap)
Comment on attachment 8988823 [details] [diff] [review]
P2 Scaffold RemoteServiceWorkerImpl to connect the binding ServiceWorker to the PServiceWorkerChild actor. r=mrbkap

This patch scaffolds the RemoteServiceWorkerImpl class.  It implements the ServiceWorker::Inner interface and is used when the e10s pref is set.

Note, I am using a pattern of integrating with IPC actors that I've used in other places before.  An outer objects has a bare pointer to the actor and the actor has a bare pointer to the outer object.  Either one can go away independently and they clear their pointers as appropriate.  I prefer this approach since the actors really have a different life cycle from the outer object.  I've used this same pattern in dom/cache and dom/clients.
Attachment #8988823 - Flags: review?(mrbkap)
Comment on attachment 8988824 [details] [diff] [review]
P3 Scaffold RemoteServiceWorkerContainerImpl to connect the binding ServiceWorkerContainer to the PServiceWorkerContainerChild actor. r=mrbkap

Scaffold RemoteServiceWorkerContainerImpl as an IPC-enabled implementation of ServiceWorkerContainer::Inner.
Attachment #8988824 - Flags: review?(mrbkap)
Comment on attachment 8988825 [details] [diff] [review]
P4 Scaffold RemoteServiceWorkerRegistrationImpl to connect the binding regi stration to the actor. r=mrbkap

Scaffold RemoteServiceWorkerRegistrationImpl as an IPC-enabled implementation of ServiceWorkerRegistration::Inner.
Attachment #8988825 - Flags: review?(mrbkap)
Comment on attachment 8988826 [details] [diff] [review]
P5 Scaffold a ServiceWorkerProxy class to connect the parent actor to the m ain thread SWM. r=mrbkap

Now that we have roughed in the child-side, this patch starts roughing in the parent-side.

This patch scaffolds the ServiceWorkerProxy class that bridges from the ServiceWorkerParent on the background thread to the ServiceWorkerManager on the main thread.

This class uses the same pattern of bare pointers connecting the actor to an outer object.
Attachment #8988826 - Flags: review?(mrbkap)
Comment on attachment 8988827 [details] [diff] [review]
P6 Scaffold a ServiceWorkerRegistrationProxy class to connect the parent ac tor to the main thread SWM. r=mrbkap

This patch scaffolds the ServiceWorkerRegistrationProxy to bridge from the ServiceWorkerRegistrationParent to the SWM.
Attachment #8988827 - Flags: review?(mrbkap)
Comment on attachment 8988828 [details] [diff] [review]
P7 Scaffold a ServiceWorkerContainerProxy class to connect the parent actor  to the main thread SWM. r=mrbkap

This patch scaffolds a ServiceWorkerContainerProxy to bridge from the ServiceWorkerContainerParent to the SWM.

Note, its possible this class could be removed since there is no main thread entity it really connects with.  It simply allows operations to be started on the SWM which doesn't really need a persistent object like this.  I decided to keep the proxy class for consistency with the other objects, though.  (Also I was short on time for more refactoring...)
Attachment #8988828 - Flags: review?(mrbkap)
Comment on attachment 8988829 [details] [diff] [review]
P8 Implement RemoteServiceWorkerImpl::PostMessage() across IPC and to the p arent-side SWM. r=mrbkap

Now that we have roughed in the structure, lets start adding functional pieces.

This patch implements ServiceWorker::Inner::PostMessage().
Attachment #8988829 - Flags: review?(mrbkap)
Comment on attachment 8988831 [details] [diff] [review]
P9 Implement RemoteServiceWorkerRegistrationImpl::Update() across IPC to th e parent-side SWM. r=mrbkap

This patch implements ServiceWorkerRegistration::Inner::Update().

Note, we are using the ipdl async returning method feature here.  This gives us a "resolver" on the receiving side.  I have verified that its safe to call the resolver function after the actor goes away (but you must be on the right thread).
Attachment #8988831 - Flags: review?(mrbkap)
Comment on attachment 8988832 [details] [diff] [review]
P10 Implement RemoteServiceWorkerRegistrationImpl::Unregister() across IPC to the parent-side SWM. r=mrbkap

This patch implement ServiceWorkerRegistration::Inner::Unregister().
Attachment #8988832 - Flags: review?(mrbkap)
Comment on attachment 8988833 [details] [diff] [review]
P11 Propogate registration state changes back from the parent to the child.  r=mrbkap

This patch propagates any registration state changes from the parent back to the child.  The binding objects will then use these state changes to update properties and dispatch events.
Attachment #8988833 - Flags: review?(mrbkap)
Comment on attachment 8988834 [details] [diff] [review]
P12 Implement RemoteServiceWorkerContainerImpl::Register() across IPC to th e parent-side SWM. r=mrbkap

This patch implements ServiceWorkerContainer::Inner::Register().
Attachment #8988834 - Flags: review?(mrbkap)
Comment on attachment 8988835 [details] [diff] [review]
P13 Implement RemoteServiceWorkerContainerImpl::GetRegistration() across IP C to the parent-side SWM. r=mrbkap

This patch implements ServiceWorkerContainer::Inner::GetRegistration().
Attachment #8988835 - Flags: review?(mrbkap)
Comment on attachment 8988836 [details] [diff] [review]
P14 Implement RemoteServiceWorkerContainerImpl::GetRegistrations() across I PC to the parent-side SWM. r=mrbkap

This patch implements ServiceWorkerContainer::Inner::GetRegistrations().  (Note, that is the plural...)
Attachment #8988836 - Flags: review?(mrbkap)
Comment on attachment 8988837 [details] [diff] [review]
P15 Implement RemoteServiceWorkerContainerImpl::GetReady() across IPC to th e parent-side SWM. r=mrbkap

This patch implements ServiceWorkerContainer::Inner::GetReady().
Attachment #8988837 - Flags: review?(mrbkap)
Blocks: 1469048
Blocks: 1472303
Blocks: 1472307
Assignee: ben → mrbkap
Attachment #8988822 - Flags: review?(mrbkap) → review+
Attachment #8988823 - Flags: review?(mrbkap) → review+
Attachment #8988824 - Flags: review?(mrbkap) → review+
Attachment #8988825 - Flags: review?(mrbkap) → review+
Attachment #8988826 - Flags: review?(mrbkap) → review+
Attachment #8988827 - Flags: review?(mrbkap) → review+
Attachment #8988828 - Flags: review?(mrbkap) → review+
Attachment #8988829 - Flags: review?(mrbkap) → review+
Attachment #8988831 - Flags: review?(mrbkap) → review+
Attachment #8988832 - Flags: review?(mrbkap) → review+
Attachment #8988833 - Flags: review?(mrbkap) → review+
Attachment #8988834 - Flags: review?(mrbkap) → review+
Attachment #8988835 - Flags: review?(mrbkap) → review+
Attachment #8988836 - Flags: review?(mrbkap) → review+
Comment on attachment 8988837 [details] [diff] [review]
P15 Implement RemoteServiceWorkerContainerImpl::GetReady() across IPC to th e parent-side SWM. r=mrbkap

Review of attachment 8988837 [details] [diff] [review]:
-----------------------------------------------------------------

Phew, that was a lot of patches! Overall, though, this was all extremely straight-forward, especially once I got my head around which objects live where (in which process and on what thread).
Attachment #8988837 - Flags: review?(mrbkap) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/a20adca36f9c833b37ff5c2f13e3783df775a7b3
Bug 1459209 P1 Add IPC actor boilerplate for PServiceWorker, PServiceWorkerContainer, and PServiceWorkerRegistration. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/a5c3aa4b30f954490724034f71b1ab47ae000b44
Bug 1459209 P2 Scaffold RemoteServiceWorkerImpl to connect the binding ServiceWorker to the PServiceWorkerChild actor. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/246c9fdaf98bfaf564660f19e9253bb9129d790c
Bug 1459209 P3 Scaffold RemoteServiceWorkerContainerImpl to connect the binding ServiceWorkerContainer to the PServiceWorkerContainerChild actor. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/09b322538309b493bea460c80fee717a10657ef3
Bug 1459209 P4 Scaffold RemoteServiceWorkerRegistrationImpl to connect the binding registration to the actor. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/64b0b50dc595c9f23b2478df834d8f509bedafda
Bug 1459209 P5 Scaffold a ServiceWorkerProxy class to connect the parent actor to the main thread SWM. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/e50b0e9556281d0d4b6f0b2c94d2d6efc50aeb24
Bug 1459209 P6 Scaffold a ServiceWorkerRegistrationProxy class to connect the parent actor to the main thread SWM. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/6503e9d70bf5ac804d023a88915f7c4429ab7c65
Bug 1459209 P7 Scaffold a ServiceWorkerContainerProxy class to connect the parent actor to the main thread SWM. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/c5328bc15a3fe38059e1e8a7fac3a23d5c0f438c
Bug 1459209 P8 Implement RemoteServiceWorkerImpl::PostMessage() across IPC and to the parent-side SWM. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/edc5818fa3f7010ed139d2e392f3397773b83a57
Bug 1459209 P9 Implement RemoteServiceWorkerRegistrationImpl::Update() across IPC to the parent-side SWM. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/3755928713f0c76d1200bad62c9518d40bf1fe94
Bug 1459209 P10 Implement RemoteServiceWorkerRegistrationImpl::Unregister() across IPC to the parent-side SWM. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/400b387177fd0bb501703f47cef5122d3f49fbc9
Bug 1459209 P11 Propogate registration state changes back from the parent to the child. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/15e4cd93bbe6db20dc8d2b2e5c822bd119b81a94
Bug 1459209 P12 Implement RemoteServiceWorkerContainerImpl::Register() across IPC to the parent-side SWM. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/9b35255be125bf135896f4d0edbb3e054bb620b4
Bug 1459209 P13 Implement RemoteServiceWorkerContainerImpl::GetRegistration() across IPC to the parent-side SWM. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/aa5e72575757e28a1641e5dbb15a7c09755117af
Bug 1459209 P14 Implement RemoteServiceWorkerContainerImpl::GetRegistrations() across IPC to the parent-side SWM. r=mrbkap

https://hg.mozilla.org/integration/mozilla-inbound/rev/fcf922ceca661836fc6f59d8fd3ef395709dfe75
Bug 1459209 P15 Implement RemoteServiceWorkerContainerImpl::GetReady() across IPC to the parent-side SWM. r=mrbkap
Depends on: 1474825
Depends on: 1474898
You need to log in before you can comment on or make changes to this bug.