Here is the meta bug for new IPC Embedding API. Idea of this new embedding is to provide API similar to WebKit2, and build applications with embedded mozilla engine (including browser application) 1) No xul/xpcom in UI process (fast embed app startup and less memory usage) 2) Content process separation enabled (embed app responsiveness on expected level, UI protected from engine crashes) 3) Basic C++ embedding API, extendable by JSON messaging system. and content process script loading.
Created attachment 585053 [details] [diff] [review] Add new XRE process type for IPC Embedding Purpose of this patch is to create new UI/Content process relationship where UI process contains: 1) Chromium message loop 2) Shadow Layer tree 3) EmbedContentParent/TabParent Child process: 1) XPCOM/Embedding, profile 2) Necko, permissions et.c. Implementation similar to Fennec, but without XPCOM/XUL on UI process, and Mozilla engine lives mostly in child process
I don't understand (yet) how these process types would be used or (for example) why you need a process type for the "embeddefault" case at all... you said XPCOM code never runs in that process, right? This definitely needs better documentation of the process types in nsXULAppAPI.h, but I also am feeling more than a little unhappy about having to sprinkle these XRE_ calls all over the codebase. Can we come up with a more generic function that people can use in general?
Also I'd like to understand how profiles/profile data is managed in this configuration.
> Also I'd like to understand how profiles/profile data is managed in this > configuration. In comment 1, I've explained a bit structure of this embedding type Profile data created for child process, and basically managed by child process. and because we can't share profile data between processes it will be one profile directory per process. > example) why you need a process type for the "embeddefault" case at all... > you said XPCOM code never runs in that process, right? embeddefault currently only used for protecting GFX code from XPCOM usage. (UI process GFX, Layers), for example I don't create fonts in embeddefault UI process.
Created attachment 613627 [details] [diff] [review] Replace equals into XRE_IsProcessType function wrapper
Created attachment 613631 [details] [diff] [review] Previde IPC Embedding process types Here is more simple version of IPC embedding process types with new XRE process check function.
Comment on attachment 613627 [details] [diff] [review] Replace equals into XRE_IsProcessType function wrapper Wrap "XRE_GetProcessType ==" > XRE_IsProcessType
cjones, can you look these over and give some opinions? I'm getting bad vibes about the "process type" abstraction here in any case, although the XRE_IsProcessType abstraction helps a bit. But I can't think of a straightforward way of doing this differently.
Comment on attachment 613631 [details] [diff] [review] Previde IPC Embedding process types Sorry, I'm declaring review bankruptcy. I don't have an opinion on these patches on their own merit. If someone else wants to review them and land them, that's fine with me. Given gecko's small share of the embedding market, my opinion would be that copying the webkit2 API, or derivatives thereof like WebView, would be the way to go. But I have no idea what the consumers are for gecko embeddings these days.
(In reply to Chris Jones [:cjones] inactive; ni?/f?/r? if you need me from comment #9) > Comment on attachment 613631 [details] [diff] [review] >...I have no idea what the > consumers are for gecko embeddings these days. Sailfish browser is using it: https://github.com/sailfishos/sailfish-browser https://github.com/tmeshkova/gecko-dev/tree/embedlite/embedding/embedlite
Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.