Messagemanager wakeup service

RESOLVED FIXED in mozilla5

Status

()

Core
IPC
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: azakai, Assigned: azakai)

Tracking

(Depends on: 1 bug, {dev-doc-needed})

Trunk
mozilla5
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(fennec2.0b1+)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

7 years ago
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.
(Assignee)

Comment 1

7 years ago
When this is ready we should apply it on:

* ContentPrefs in toolkit
* PromptService in mobile-browser

Updated

7 years ago
Blocks: 584401
(Assignee)

Updated

7 years ago
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 @mozilla.org/foo;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+
(Assignee)

Updated

7 years ago
Blocks: 584842
(Assignee)

Comment 3

7 years ago
Created attachment 470070 [details] [diff] [review]
Patch

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]
Patch

>+ * 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[aMessage.name];
>+    delete this.messagesData[aMessage.name];
>+    var service = Cc[data.cid][data.method](Ci[data.iid]);
>+    this.messageManager.addMessageListener(aMessage.name, service.wrappedJSObject);
>+    this.messageManager.removeMessageListener(aMessage.name, 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+
(Assignee)

Updated

7 years ago
Depends on: 592017

Updated

7 years ago
Attachment #470070 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Comment 5

7 years ago
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.
Attachment #471912 - Flags: review+
(Assignee)

Comment 6

7 years ago
Created attachment 472031 [details] [diff] [review]
Final patch for checkin
Attachment #471912 - Attachment is obsolete: true
Attachment #472031 - Flags: review+
(Assignee)

Updated

7 years ago
Keywords: checkin-needed
Whiteboard: "Final patch for checkin" needs checkin (not other one)

Comment 7

7 years ago
http://hg.mozilla.org/mozilla-central/rev/dc9a26033206
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: "Final patch for checkin" needs checkin (not other one)
Blocks: 594430
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:

http://hg.mozilla.org/mozilla-central/annotate/60edf587f4af/content/base/public/nsIMessageWakeupService.idl#l40
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:

https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIMessageWakeupService
Sheppy: The code itself is still there:
http://mxr.mozilla.org/mozilla-central/find?string=messageWakeupService

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:

https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIMessageWakeupService

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.
Keywords: dev-doc-needed → dev-doc-complete
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.
Keywords: dev-doc-complete → dev-doc-needed
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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.