Exposing the API as a component will allow Loop, Sync, and FxA to use push notifications from chrome code, without migrating to service workers. :dougt suggested using an XPCOM service to handle subscriptions, and observer notifications to broadcast incoming push messages.

I used the mock WebSocket from bug 899742 for speed, and so the error conditions could be tested. This can be replaced with a real server to match the mochitests, though.

Comment on attachment 8587648 [details] [diff] [review] Bug 1150683 - Add XPCOM interfaces for push notifications Review of attachment 8587648 [details] [diff] [review]: ----------------------------------------------------------------- lgtm ::: dom/interfaces/push/nsIPushObserverNotification.idl @@ +12,5 @@ > +[scriptable, uuid(66a87970-6dc9-46e0-ac61-adb4a13791de)] > +interface nsIPushObserverNotification : nsISupports > +{ > + /* The URL that receives push messages from an application server. */ > + attribute string pushEndpoint; In the spec, we also have subscriptionID. Not sure which way the spec will go, but I implemented subscriptionID for the stuff exposed to the web. @@ +18,5 @@ > + /** > + * The notification version sent by the application server. This is a > + * monotonically increasing number. > + */ > + attribute long long version; version is going away, right?

I tested these patches, and it looks like they broke my mochitests. Apply the patch from 1153937, rebuild, then: ./mach mochitest --subsuite push dom/push

Comment on attachment 8591405 [details] [diff] [review] Bug 1150683 - Add xpcshell tests for nsIPushNotificationService This patch should just be testing. Pull out the changes to PushService.jsm,

Comment on attachment 8591404 [details] [diff] [review] Bug 1150683 - Implement nsIPushNotificationService clearing until we understand what the test failure is about.

This fixes the mochitest failures.

Fixing up commit message and carrying over r+ from comment #7.

(In reply to Doug Turner (:dougt) from comment #7) > In the spec, we also have subscriptionID. Not sure which way the spec will > go, but I implemented subscriptionID for the stuff exposed to the web. Cool. I see you're tracking that in bug 1149271. Would you prefer a `subscriptionId` placeholder for XPCOM, too, or wait until we know what it does? > version is going away, right? Yup, though I think Loop relies on it now. Data should remove the need for version eventually.

i think you can leave it as is for now.

Fix Android bustage.

remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/814fc7abbe18 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/66ca87f2a944 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/4389151f1348 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/645508dd2a76

And backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/aa01c3fd458c for failing Android xpcshell like it did on try.

Updated against `mozilla-inbound`, removed `dom.push.enabled` pref. Carrying over r+ from previous patch, and bug 1153937 for the pref removal.

Updated against `mozilla-inbound`.

Updated against `mozilla-inbound`.

* Disable the wake lock on non-B2G platforms. Works around bug 1154492. * Include alarms and push in the Android install manifest. https://treeherder.mozilla.org/#/jobs?repo=try&revision=5439476e21e1

rebase + a small change to when we startup everything. See https://treeherder.mozilla.org/#/jobs?repo=try&revision=37b06eded7b5

Rebased and switched to `sessionstore-windows-restored`.

Disabled `nsIPushNotificationService` and the tests on Android. No more IndexedDB errors: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a76e7402e610

remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/8e82f557f913 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/186ed6bc887e remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/c6805afff48c remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/7953d3dd62ff

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/4f0e980ff1e1 for both the same indexedDB crashes in talos @mozilla::dom::indexedDB::::ConnectionPool::Start that it had on try and also possibly more informative talos assertions and crashes like https://treeherder.mozilla.org/logviewer.html#?job_id=9031652&repo=mozilla-inbound

And despite matching up with the existing intermittent bug 1146705, I think the Windows Mn crashes are yours too.

The indexeddb crash is also being looked at in bug 1156063.

https://hg.mozilla.org/integration/mozilla-inbound/rev/fb6500be1479 https://hg.mozilla.org/integration/mozilla-inbound/rev/f6c0ba775c8a https://hg.mozilla.org/integration/mozilla-inbound/rev/eb10543f2833 https://hg.mozilla.org/integration/mozilla-inbound/rev/ec5991856bb7

https://hg.mozilla.org/mozilla-central/rev/fb6500be1479 https://hg.mozilla.org/mozilla-central/rev/f6c0ba775c8a https://hg.mozilla.org/mozilla-central/rev/eb10543f2833 https://hg.mozilla.org/mozilla-central/rev/ec5991856bb7