| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
name to resolve is too long.
This change is important when a site has @font-face rule like:
// http://paulirish.com/webkit-fontface-hang.html
@font-face{font-family:testfont;src:url('data:font/ttf;base64,AA.....<<looooooooooong base64 data>>.....aQ==')}
In such a case, WebCore first calls SkFontHost::CreateTypeface() with the (possibly very long) data-uri string itself, then calls SkFontHost::CreateTypefaceFromStream() with decoded byte stream. Since render_sandbox_host_linux.cc just ignores too long IPC message, the renderer process could block indefinitely waiting for a reply inside recvmsg() system call called from SkFontHost::CreateTypeface().
I'm not sure if the WebCore behavior (i.e. calling CreateTypeface with data-uris) is reasonable, but I believe the Skia part is better to be fixed anyway. Non data-uri font family names could be very long too:
@font-face{font-family:testfont;src:local('AA........AA');}
BUG=29861
TEST=First, set up your Linux SUID Sandbox binary: http://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment. Then start Chromium and visit http://paulirish.com/webkit-fontface-hang.html or http://typekit.com/. Verify that the renderer does not freeze.
Review URL: http://codereview.chromium.org/507037
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34915 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch we assumed that the style which we got from
fontconfig was the one that we asked for. Rather than do this we need
to query the resulting style and plumb that back into WebKit. Once
WebKit knows that there's a mismatch between the request and actual
styles it can trigger faking.
BUG=14810
http://codereview.chromium.org/147005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19095 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
I'll be needing in some pending WebKit changes.
http://codereview.chromium.org/131006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18676 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://code.google.com/p/chromium/wiki/LinuxSandboxIPC
Without filesystem access from the renderers, we need another way of
dealing with fontconfig and font loading.
This add support for:
* An "SBX_D" environment variable in the renderers which is used to
signal the end of dynamic linking so that the chroot can be
enforced.
* A sandbox_host process, running outside the sandbox, to deal with
fontconfig requests from the renderers. See the wiki page for
the reasoning behind making it a separate process.
* A new, custom SkFontHost for Skia. Because this is Chrome
specific, it will live outside the upstream Skia tree. This
FontHost can be configured either to drive fontconfig directly
(for the browser process and for any unsandboxed renderers) or to
use an IPC system. Since the same SkFontHost has to be linked into
both the browser and renderer (they are the same binary), this
switch has to be made at run time.
Sandbox IPC calls are rare (a couple of dozen at page load time) and
add about 50us of overhead for each call.
(Reland of r17575 which was reverted in r17577)
http://codereview.chromium.org/112074
BUG=8081
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18405 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17577 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
http://code.google.com/p/chromium/wiki/LinuxSandboxIPC
Without filesystem access from the renderers, we need another way of
dealing with fontconfig and font loading.
This add support for:
* An "SBX_D" environment variable in the renderers which is used to
signal the end of dynamic linking so that the chroot can be
enforced.
* A sandbox_host process, running outside the sandbox, to deal with
fontconfig requests from the renderers. See the wiki page for
the reasoning behind making it a separate process.
* A new, custom SkFontHost for Skia. Because this is Chrome
specific, it will live outside the upstream Skia tree. This
FontHost can be configured either to drive fontconfig directly
(for the browser process and for any unsandboxed renderers) or to
use an IPC system. Since the same SkFontHost has to be linked into
both the browser and renderer (they are the same binary), this
switch has to be made at run time.
Sandbox IPC calls are rare (a couple of dozen at page load time) and
add about 50us of overhead for each call.
http://codereview.chromium.org/112074
BUG=8081
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17575 0039d316-1c4b-4281-b951-d872f2087c98
|
