899675 - expose a way for Firefox to share profile data with apps

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Web Apps, enhancement, P2)

Description

[Myk Melez [:myk] [@mykmelez]]

Desktop runtime apps need share some data stored in the Firefox profile, like the webapps registry (bug 892020), the proxy configuration (bug 753983), and possibly a "developer mode" preference (bug 899656); and sharing it on disk is perilous, because "file corruption is easy to cause and debugging it is very hard" (bug 892020, comment 8); so Firefox should expose a way to share that data between apps.

A variety of engineers have discussed this off and on both on- and off-line, and we've identified two possible approaches:

1. a service/daemon that runs as needed whether or not Firefox is running and exposes an interface via IPC;

2. a command-line handler for -remote commands handled by either an existing Firefox process or a headless process that the runtime starts/stops to process a command.

Comment 1

[Marco Castelluccio [:marco]]

The second option is probably simpler and cross-platform.

Comment 2

[:Felipe Gomes (needinfo for replies!)]

Just to add another option in the mix, which might not be the answer for all use cases, but still worth thinking about it: SQLite can explicitly handle multiple processes accessing the same DB, so it might be a simple way to share data between processes and have data consistency and race conditions already solved.

Comment 3

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

The MetroFx team has also discussed making Firefox desktop profile data available to other apps (specifically Firefox Metro). Implementing a mechanism for accessing Firefox desktop profile data would allow Firefox Metro and Firefox desktop to share browsing history and related data.

From what I know thus far, I would suggest that we go with the service/daemon approach, as long as we make that service/daemon the exclusive mechanism for accessing profile data (i.e. Firefox would no longer access profile data directly; it would instead use the service).

If Firefox is allowed to continue accessing profile data directly, then every running Firefox process is a potential broker of profile data and all running Firefox processes would need to be enumerated and communicated with by a consumer wanting profile data.

If a process is started/stopped once for every command, then the overhead of locking an entire profile will be incurred every time a piece of profile data is accessed.

One complication to consider is that older versions of Firefox will be unaware of whatever profile-data-sharing mechanism gets implemented, so they will continue to access profiles directly and lock them from being accessed by the sharing mechanism.

Comment 4

[Marco Castelluccio [:marco]]

I think we should start to seriously consider this, because to support some APIs on desktop we'll probably need a background service (for example, alarms, webactivities, push notifications, etc.).

I think we could start by creating this background service and using it to share just some profile data (for example the proxy settings), and then slowly sharing also other data (to avoid disruptive changes).
The service could be executed on-demand and live for some time even if unused (to avoid having to relaunch it too many times).

The service shouldn't have particular privileges as it only needs to access the Firefox profile.

Comment 5

[Marco Castelluccio [:marco]]

Attachment: Early WIP

I've built a simple system to share data between the webapp runtime,
Firefox and a central service.
The webapp runtime instances and Firefox communicate with the central
server via sockets.
There is a server for each Firefox profile.
The clients requests are "GET", "STORE" and "REMOVE". In each request
there's an app ID and some additional data if needed (for example in
the "STORE" case). We could associate a "department" name to each
request (to access the different shared databases we have, for example
"webapp registry" or "preferences").
The server notifies all clients when an app is modified (if a client
requested a "STORE") or removed (if a client requested a "REMOVE"). The
notification sent when a client sends a "STORE" is the same as the reply
the server sends to a "GET" (this way, the protocol is simplified and is
basically stateless because the client doesn't have to associate the
request to the reply too precisely).

This is an early WIP, so a lot of stuff is missing (for example, the data
is hardcoded in the server itself).

I think if we want to follow this approach, we should start with sharing
some prefs (for example, the proxy prefs). Sharing the webapps registry
would involve some refactoring first (first of all, bug 910469).

Comment 6

[Marco Castelluccio [:marco]]

We could also use the server to get the list of running apps and similar stuff needed for the devtools.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

Per bug 1238079, we're going to disable the desktop web runtime and remove it
from the codebase, so we won't fix these bugs in the integration between Firefox and the runtime.