Re: new code to help with cross-process windows/workers (and Clients API)
On Dec 9, 2017 8:25 AM, "Gijs Kruitbosch"wrote: On 08/12/2017 20:23, Ben Kelly wrote: > Please let me know if you have any question or if you think you have a > feature that could integrate with the clients infrastructure. While the > initial implementation is limited to Clients API needs, I've tried to > design it to support other internal uses. I'd be very happy to help get > new features added to support browser chrome or native code. > Sorry if this was answered by implication somewhere in the OP already (I looked, but must have missed it!), but is this infrastructure exposed/available to Chrome JS, and message manager messages (as opposed to C++-based IPC with ipdl etc.) ? Not yet, but I have designed it to support that. Probably the first step would be to expose the Clients WebAPI to browser chrome script. We could then add more chrome-only features as use cases arise. Can you file a bug in Core:DOM and describe a bit more how you would like to use it? I just want to make sure anything we expose fits our browser chrome use cases well. In particular, in situations where we currently have content scripts that need to go ask the parent process something, and the parent then needs to go back to the content process with an answer, without losing the "reference" to the frame concerned (which may be a subframe, so just knowing the target browser is not enough), that is currently annoying to implement (requires e.g. manual window id tracking in the content process). It sounds like this API might make this type of thing easier to implement if we could use it from chrome JS. The Clients API is all promise based and I expect any future API would be as well. So hopefully that will make things easier. Thanks. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: new code to help with cross-process windows/workers (and Clients API)
On 08/12/2017 20:23, Ben Kelly wrote: Please let me know if you have any question or if you think you have a feature that could integrate with the clients infrastructure. While the initial implementation is limited to Clients API needs, I've tried to design it to support other internal uses. I'd be very happy to help get new features added to support browser chrome or native code. Sorry if this was answered by implication somewhere in the OP already (I looked, but must have missed it!), but is this infrastructure exposed/available to Chrome JS, and message manager messages (as opposed to C++-based IPC with ipdl etc.) ? In particular, in situations where we currently have content scripts that need to go ask the parent process something, and the parent then needs to go back to the content process with an answer, without losing the "reference" to the frame concerned (which may be a subframe, so just knowing the target browser is not enough), that is currently annoying to implement (requires e.g. manual window id tracking in the content process). It sounds like this API might make this type of thing easier to implement if we could use it from chrome JS. ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: new code to help with cross-process windows/workers (and Clients API)
On Fri, Dec 8, 2017 at 4:38 PM, Mike Conleywrote: > >> I personally think this would be useful, and will (probably) only > happen if > >> you do it now, before you move on to the next thing. +1 for > documentation! > > I concur. > Alright. I'll work on a blog post next week. (I'm not going to be in Austin for the work week.) Thanks. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: new code to help with cross-process windows/workers (and Clients API)
This all sounds great! >> I personally think this would be useful, and will (probably) only happen if >> you do it now, before you move on to the next thing. +1 for documentation! I concur. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: new code to help with cross-process windows/workers (and Clients API)
Hi Ben, On Fri, Dec 8, 2017 at 12:23 PM, Ben Kellywrote: > Hi all, > > I just want to give you a heads up about some new infrastructure that is > landing in the tree. In particular, we now have: > 1. A central list of windows and workers for the entire browser in the > parent process. This includes information on their origin, url, and what > process they are running in. This lives in ClientManagerService. > This is the kind of work that makes me wonder how we _didn't_ have this central list before :) > P.S. I was also thinking of doing a blog post with diagrams of how it works > if people think that would be useful. > I personally think this would be useful, and will (probably) only happen if you do it now, before you move on to the next thing. +1 for documentation! Thanks for this work! Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
new code to help with cross-process windows/workers (and Clients API)
Hi all, I just want to give you a heads up about some new infrastructure that is landing in the tree. In particular, we now have: 1. A central list of windows and workers for the entire browser in the parent process. This includes information on their origin, url, and what process they are running in. This lives in ClientManagerService. 2. A structure called ClientInfo which lets you refer to a particular window or worker. This can be passed between threads/processes and then used to attach to the running window/worker by creating a ClientHandle object. 3. ClientHandle provides initial support for focusing and navigating windows. You can also postMessage() both window and worker clients. 4. A ClientManager interface allows you to query the list of clients in the system and open windows regardless of your current process/thread. In the future we may move values that apply to both windows and workers to the new ClientInfo type. For example, we have plans to move CSP from nsIPrincipal. Other data like referrer-policy would that applies to both windows/workers would also be a good fit. Before adding new values to nsIDocument or WorkerPrivate, please consider if they would fit better in the clients infrastructure layer. Over time it would be nice to move towards the client types since it will allow us to write more code that "just works" with windows and workers. We can start removing the conditional "if nsIDocument do X else if WorkerPrivate do Y" we have in the tree. This code has been implemented so far in bug 1293277 and its dependents in order to support a multi-e10s Clients WebAPI: https://developer.mozilla.org/en-US/docs/Web/API/Clients Initially we will be using these new features only in Clients API on service worker threads, but the design supports using it other contexts as well. I have a spec issue open to support content windows as well. If there is a desire to access these features from browser chrome script, please let me know. I think this should be possible once we have use cases. While not as powerful as our various xpcom components, it might be more convenient to use for some cases. Please let me know if you have any question or if you think you have a feature that could integrate with the clients infrastructure. While the initial implementation is limited to Clients API needs, I've tried to design it to support other internal uses. I'd be very happy to help get new features added to support browser chrome or native code. Thanks! Ben P.S. I was also thinking of doing a blog post with diagrams of how it works if people think that would be useful. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform