In Chrome sandbox model, GDI calls such as GetOutlineTextMetrics() can fail if the font is not loaded in memory already. Chrome browser process implements a hack that will force GDI to load the desired font into memory, and in WebKit terms, it's called PlatformSupport::ensureFontLoaded(). This means that WebKit renderer must call PlatformSupport::ensureFontLoaded() right before calling Skia to draw glyphs because they are both in sandbox.
Created attachment 109685 [details] Patch
Comment on attachment 109685 [details] Patch Is there any way to construct a test case for this? What is the failure mode if this doesn't happen?
(In reply to comment #2) > (From update of attachment 109685 [details]) > Is there any way to construct a test case for this? This currently causes problem only in Chrome printing code because Skia needs to query GDI outline text metrics for generating PDF data. I'm not sure how that sandbox/PDF generation can fit in WebKit testing. > What is the failure mode if this doesn't happen? In Chrome it will crash the renderer and the printing will fail.
So this is just a fix for printing? You should update the bug title to reflect that.
(In reply to comment #4) > So this is just a fix for printing? You should update the bug title to reflect that. Done.
This LGTM, but I am not a WebKit reviewer. You need an r+ from a real WebKit reviewer before committing.
Comment on attachment 109685 [details] Patch agl's LGTM is good enough for me.
Comment on attachment 109685 [details] Patch Clearing flags on attachment: 109685 Committed r96847: <http://trac.webkit.org/changeset/96847>
All reviewed patches have been landed. Closing bug.
There's a pretty significant memory regression on Chromium Windows. This is the only Windows change in the regression range, so we're going to try rolling it out and see if memory returns to normal. If it turns out this isn't causing it, I'll roll it back in.
Created attachment 110897 [details] Patch for landing
Committed r97426: <http://trac.webkit.org/changeset/97426>