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 [email protected] https://lists.mozilla.org/listinfo/dev-platform
