Bug 41148 – [Chromium] Add support for OOP Font loading

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Jeremy Moskovich]

http://crbug.com/29729

On OS X, with font management software installed. Fonts can reside in an arbitrary path on disk which is blocked by Chromium's Sandbox.

We need hooks in the Mac version of FontPlatformData that allow us to fall back to loading a font x-process if blocked by the Sandbox.

[Jeremy Moskovich]

Created attachment 59637 [details]
Fork FontPlatformFontDataMac.mm to enable x-process font loading

Fork platform/graphics/mac/FontPlatformFontDataMac.mm to platform/graphics/chromium/FontPlatformDataChromiumMac.mm and add functionality for x-process font loading.

* We need to use the header from platform/graphics/mac since the class is used by a bunch of code in there.
* I'd prefer not to fork the code, suggestions would be much appreciated.

[Avi Drissman]

In the ChangeLog, you can edit out spurious function entries like "(WebCore::):". Otherwise, SLGTM.

[Dimitri Glazkov (Google)]

Comment on attachment 59637 [details]
Fork FontPlatformFontDataMac.mm to enable x-process font loading

Please update the change log and then it'll be ready to land. Also, we need a plan to unfork this. File a bug and block it on this bug.

[Eric Seidel (no email)]

I don't like the word "fork"... chromium is too old of a project with too many webkit reviewers to have any excuse to "fork" files in WebKit anymore.

[Eric Seidel (no email)]

(That said, that's just a drive-by comment, and I'd be the first to admit I don't actually know what's going on here.)

[Eric Seidel (no email)]

As an example of "forks" eating away at the WebKit project.  Both V8 and QtXML nonsense have cost me at least a day of work in the last 2 weeks.  0 value to me.  Huge time sinks when trying to refactor other parts of the code.  Chromium certainly shouldn't be adding to forks these days now that we're big enough to just develop things right in webkit.org and refactor as needed.

[Jeremy Moskovich]

Eric: I think we all whole-heartedly agree with you.

The thinking here was to land this, then immediately submit a cl to merge this with the other Mac code. (If you look, this CL is already structured to make this easy).

The reasoning for having a Chromium codepath in this code isn't obvious, and having this code in the tree will mean that on one hand we can merge with a small patch and on the other it will be easier for reviewers of that patch to understand the context.

[Eric Seidel (no email)]

It would be possible to add sandbox support for DRT.  It would probably require a fork (ha ha) of DRT though, since I doubt that the general AppKit APIs it uses are sandbox safe.

[Jeremy Moskovich]

Created attachment 60113 [details]
Fork FontPlatformFontDataMac.mm to enable x-process font loading

[Dimitri Glazkov (Google)]

Comment on attachment 60113 [details]
Fork FontPlatformFontDataMac.mm to enable x-process font loading

ok.

[WebKit Commit Bot]

Comment on attachment 60113 [details]
Fork FontPlatformFontDataMac.mm to enable x-process font loading

Clearing flags on attachment: 60113

Committed r62187: <http://trac.webkit.org/changeset/62187>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.