1369118 - Consider remoting access to DConf/GSettings for e10s

Status: NEW

(Core :: Widget: Gtk, enhancement, P3)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

This is a followup to bug 1321134, and specifically bug 1321134 comment #6 which suggested that we should do DConf/GSettings accesses through the parent process instead of using the sandboxed content process and needing to allow access to the specific files it happens to use.

Currently there seem to be two GSettings users in the content process:

* HourCycle(), to read the 12/24 hour preference when formatting dates (for browser-generated directory listings, and maybe other things)

* WebRTC, to read the system proxy configuration, but this might eventually be moving to another process in bug 1287225

Straightforwardly remoting GSettings would mean either using sync IPC (discouraged) or introducing and converting things to an async API (usually difficult and/or annoying), and every read would mean an IPC round-trip so we might want some kind of caching (which means deciding when to invalidate it — which is what the files we're allowing write access to in bug 1321134 are used for, incidentally).

This seems like a lot of work if it's just going to be used for HourCycle(), so the other possibility is to remote that specific user, but that still has the same problems with asynchrony and caching.

If nothing else, it's worth keeping this in mind in case there are more content-process GSettings things in the future.

Comment 1

[Landry Breuil (:gaston)]

having those only in the parent process would allow for tighter sandboxing also on OpenBSD...