On Dec 9, 2017 8:25 AM, "Gijs Kruitbosch" <[email protected]> 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 [email protected] https://lists.mozilla.org/listinfo/dev-platform
