Closed Bug 591052 Opened 14 years ago Closed 14 years ago

Messagemanager wakeup service


(Core :: IPC, defect)

Not set



Tracking Status
fennec 2.0b1+ ---


(Reporter: azakai, Assigned: azakai)



(Keywords: dev-doc-needed)


(2 files, 1 obsolete file)

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.
When this is ready we should apply it on:

* ContentPrefs in toolkit
* PromptService in mobile-browser
Blocks: 584401
Depends on: 585173
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.
tracking-fennec: --- → 2.0b1+
Blocks: 584842
Attached patch PatchSplinter 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.
Attachment #470070 - Flags: review?(mark.finkle)
Attachment #470070 - Flags: review?(Olli.Pettay)
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.
Attachment #470070 - Flags: review?(mark.finkle) → review+
Depends on: 592017
Attachment #470070 - Flags: review?(Olli.Pettay) → review+
Attached patch Final Patch (obsolete) — Splinter Review
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.
Attachment #471912 - Flags: review+
Attachment #471912 - Attachment is obsolete: true
Attachment #472031 - Flags: review+
Keywords: checkin-needed
Whiteboard: "Final patch for checkin" needs checkin (not other one)
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: "Final patch for checkin" needs checkin (not other one)
Depends on: 594487
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:
Keywords: dev-doc-needed
What release did this go into?
It won't be included in desktop Firefox until Firefox 13 (bug 726864). It was added for mobile in Gecko 5.
Target Milestone: --- → mozilla5
Added a link to this in the Firefox 13 for developers page, but actual docs are not written yet.
I don't see this API in mozilla-central; I take it it has gone away?
FWIW I started docs here before noticing that it's apparently gone:
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.
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.
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.
(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.
You need to log in before you can comment on or make changes to this bug.