1284291 - Add the 'com.apple.fonts' service to the sandbox profile.

Status: RESOLVED WORKSFORME

(Core :: Widget: Cocoa, defect)

Description

[Markus Stange [:mstange]]

See https://codereview.chromium.org/2075953002/ :

> It was done for WebKit in http://wkrev.com/192805
>
> Without it, the renderer process can't talk to the font server on macOS 10.12
> Sierra and spawns an entire font server in each renderer process.
>
> This CL reduces the memory footprint of each renderer process by ~600MB on
> macOS 10.12 Beta (16A201w).

Comment 1

[Haik Aftandilian [:haik]]

I'll take a look at this tomorrow. I wonder what the implications are for 10.9 - 10.11 and if other plugin process types (besides content) should also get this permission. Sounds like they should.

Comment 2

[Haik Aftandilian [:haik]]

I've got Sierra running in a VM, but am having trouble getting my Nightly builds to run. There are a few other Sierra known crashes being worked out so I'll revisit this.

Comment 3

[Haik Aftandilian [:haik]]

I'm definitely not seeing the type of memory usage reported on the Chromium/Sierra bug. To test this, I set Nightly's dom.ipc.processCount config to 8 and tested with lots of tabs and also some plugin processes and compared the memory usage on El Capitan (10.11) and Sierra beta 3 (10.12.3). The tests I did were

1) with 10 web tabs and checking the memory usage in OS X's Activity Monitor. The per-process memory usage ranged from ~120 MB to ~400 for both 10.11.6 and the 10.12.3 beta.

2) with 2 widevine plugin tabs streaming video using Widevine. The memory usage on 10.11 and 10.12 looked similar for the two plugin processes.

It's possible we don't need to explicitly allow com.apple.fonts because another OS X facility that we allow is starting to use it before we enable the sandbox in content.

We only have the content sandbox on OS X enabled on Nightly for now so this problem wouldn't affect release versions of Firefox when Sierra rolls out.

Closing as works-for-me for now. Adding needinfo for myself to do some more debugging to hopefully understand why we don't see the issue Chromium was hitting.

Comment 4

[Haik Aftandilian [:haik]]

(In reply to Haik Aftandilian [:haik] from comment #3)
> It's possible we don't need to explicitly allow com.apple.fonts because
> another OS X facility that we allow is starting to use it before we enable
> the sandbox in content.

I meant it's possible we don't need to explicitly allow com.apple.fonts because something that the plugin container did before starting the sandbox triggered the mach open of com.apple.fonts.

Comment 5

[Haik Aftandilian [:haik]]

We will be examining the ports that are opened before we enable the sandbox in bug 1389494 "Review open mach ports in the content process".