Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 591052 - Messagemanager wakeup service
: Messagemanager wakeup service
: dev-doc-needed
Product: Core
Classification: Components
Component: IPC (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla5
Assigned To: Alon Zakai (:azakai)
: Bill McCloskey (:billm)
Depends on: 592017 585173 594487
Blocks: 584401 584842 594430
  Show dependency treegraph
Reported: 2010-08-26 14:34 PDT by Alon Zakai (:azakai)
Modified: 2012-12-19 16:33 PST (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (8.66 KB, patch)
2010-08-27 16:09 PDT, Alon Zakai (:azakai)
mark.finkle: review+
bugs: review+
Details | Diff | Splinter Review
Final Patch (8.86 KB, patch)
2010-09-03 10:42 PDT, Alon Zakai (:azakai)
azakai: review+
Details | Diff | Splinter Review
Final patch for checkin (8.74 KB, patch)
2010-09-03 16:27 PDT, Alon Zakai (:azakai)
azakai: review+
Details | Diff | Splinter Review

Description Alon Zakai (:azakai) 2010-08-26 14:34:14 PDT
This would prevent us needing to load components that listen to messages in the parent during startup. A wakeup service could read component data from their manifest files and listen to their messages for them, then wake them up as necessary, at which time it would unlisten from those messages.
Comment 1 Alon Zakai (:azakai) 2010-08-27 10:02:45 PDT
When this is ready we should apply it on:

* ContentPrefs in toolkit
* PromptService in mobile-browser
Comment 2 Mark Finkle (:mfinkle) (use needinfo?) 2010-08-27 11:51:35 PDT
Alon and I talked about using a model similar to the way nsIUpdateTimerService works:

Components add a category to their manifest to "register" with the wakeup service. Something like:

category wakeup-message nsFooComponent;1,Message:Name1,Message:Name2

The wakeup service would instanticate the component and call the receiveMessage method with the intended message.
Comment 3 Alon Zakai (:azakai) 2010-08-27 16:09:16 PDT
Created attachment 470070 [details] [diff] [review]

Basically does what mfinkle just said.

Wish there were a good way to test this, bug xpcshell isn't enough, and we'd need a mochitest with a child process (which we don't have yet). Tested this as working manually with the content prefs patch.
Comment 4 Mark Finkle (:mfinkle) (use needinfo?) 2010-08-28 10:56:55 PDT
Comment on attachment 470070 [details] [diff] [review]

>+ * In both cases the service that will be woken up must provide
>+ * .wrappedJSObject. This is necessary for us to be able to call
>+ * the receiveMessage of the service directly.

Let's work to remove this requirement. If we require that the service implements nsIFrameMessageListener, we should be fine.

>+  receiveMessage: function(aMessage) {
>+    var data = this.messagesData[];
>+    delete this.messagesData[];
>+    var service = Cc[data.cid][data.method](Ci[data.iid]);
>+    this.messageManager.addMessageListener(, service.wrappedJSObject);
>+    this.messageManager.removeMessageListener(, this);
>+    service.wrappedJSObject.receiveMessage(aMessage);
>+  },

Instead of using wrappedJSObject, we should be able to QI to nsIFrameMessageListener, use it to call addMessageListener and then call receiveMessage

Overall, this patch looks good. We do need to remove the wrappedJSObject use though.
Comment 5 Alon Zakai (:azakai) 2010-09-03 10:42:42 PDT
Created attachment 471912 [details] [diff] [review]
Final Patch

It has been decided not to wait on bug 592017. This patch is updated with comments about that. Otherwise no changes.

We will stop using the hack in bug 593407.
Comment 6 Alon Zakai (:azakai) 2010-09-03 16:27:48 PDT
Created attachment 472031 [details] [diff] [review]
Final patch for checkin
Comment 7 Doug Turner (:dougt) 2010-09-03 19:10:15 PDT
Comment 8 :Gavin Sharp [email:] 2012-02-13 17:34:05 PST
Looks like this ended up never being documented. I"m removing the IDL in bug 726866, and I suggest we take the comments from it as the basis for documentation on MDN:
Comment 9 Eric Shepherd [:sheppy] 2012-02-23 07:42:16 PST
What release did this go into?
Comment 10 :Gavin Sharp [email:] 2012-02-23 14:22:42 PST
It won't be included in desktop Firefox until Firefox 13 (bug 726864). It was added for mobile in Gecko 5.
Comment 11 Eric Shepherd [:sheppy] 2012-12-18 07:58:28 PST
Added a link to this in the Firefox 13 for developers page, but actual docs are not written yet.
Comment 12 Eric Shepherd [:sheppy] 2012-12-18 08:05:49 PST
I don't see this API in mozilla-central; I take it it has gone away?
Comment 13 Eric Shepherd [:sheppy] 2012-12-18 08:07:39 PST
FWIW I started docs here before noticing that it's apparently gone:
Comment 14 :Gavin Sharp [email:] 2012-12-18 16:12:54 PST
Sheppy: The code itself is still there:

The IDL (nsIMessageWakeupService) was removed, because it wasn't being used. The service just uses nsIObserver and the category manager to function now. The comment in the original IDL (linked in comment 8) is still accurate, though, AFAICT.
Comment 15 Eric Shepherd [:sheppy] 2012-12-19 09:13:05 PST
OK, I *think* the documentation for this is finished, but if anyone can give it a quick once-over (it's short), please do:

The main question is the clarity of the text about requestWakeup(), since as far as I can tell, nobody in the real world calls that; instead everyone uses the manifest.
Comment 16 :Gavin Sharp [email:] 2012-12-19 16:31:46 PST
Thanks Sheppy. A couple of issues:
- There really is no "interface" for this functionality, in the traditional XPCOM sense. So the documentation URL and associated metadata is kind of confusing, and I'm not sure how to fix that.
- Given that, the "requestWakeup" part of the documentation is incorrect. I removed it and tried to flesh out the parts related to the bits that work, but I'm sure the formatting and such is probably not ideal.
Comment 17 :Gavin Sharp [email:] 2012-12-19 16:33:35 PST
(In reply to :Gavin Sharp (use for email) from comment #16)
> - There really is no "interface" for this functionality, in the traditional
> XPCOM sense. So the documentation URL and associated metadata is kind of
> confusing

Really I guess I'm just saying that the wrong template is being used - this is not an "interface", but rather a mechanism by which apps can be registered to be woken up via the category manager. I don't know where this kind of stuff should live on MDN exactly.

Note You need to log in before you can comment on or make changes to this bug.