Provide lite embedding API with IPC

RESOLVED INCOMPLETE

Status

()

Core
Embedding: APIs
RESOLVED INCOMPLETE
6 years ago
a year ago

People

(Reporter: romaxa, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
All
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

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

Updated

6 years ago
(Reporter)

Comment 1

6 years ago
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
Attachment #585053 - Flags: feedback?(benjamin)
(Reporter)

Updated

6 years ago
Depends on: 714929

Comment 2

6 years ago
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?

Comment 3

6 years ago
Also I'd like to understand how profiles/profile data is managed in this configuration.

Updated

6 years ago
Attachment #585053 - Flags: feedback?(benjamin) → feedback-
(Reporter)

Comment 4

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

Comment 5

5 years ago
Created attachment 613627 [details] [diff] [review]
Replace equals into XRE_IsProcessType function wrapper
Attachment #585053 - Attachment is obsolete: true
(Reporter)

Comment 6

5 years ago
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.
Attachment #613631 - Flags: feedback?(benjamin)
(Reporter)

Comment 7

5 years ago
Comment on attachment 613627 [details] [diff] [review]
Replace equals into XRE_IsProcessType function wrapper

Wrap "XRE_GetProcessType ==" > XRE_IsProcessType
Attachment #613627 - Flags: feedback?(benjamin)

Comment 8

5 years ago
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.

Updated

5 years ago
Attachment #613631 - Flags: feedback?(benjamin) → feedback?(jones.chris.g)

Updated

5 years ago
Attachment #613627 - Flags: feedback?(benjamin)
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.
Attachment #613631 - Flags: feedback?(cjones.bugs)

Comment 10

3 years ago
(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

Comment 11

a year ago
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.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.