| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to this change, third_party/skia/src/port/SkFontHost_Freetype.cpp
needs a couple of lines changed.
The Skia part is at http://codereview.appspot.com/1847046/show
BUG=50389
TEST=Install ttf-wqy-microhei package on Ubuntu and go to http://i18nl10n.com/chrome/ttc2.html. Latin letters in the 1st line should be monospaced while they're proportional in the second line.
Review URL: http://codereview.chromium.org/2870073
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55262 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
BUG=50273
TEST=everything still builds, build is 10% faster on windows, same speed on mac/linux
TBR: erg
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53716 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This also includes Evan's patch: http://codereview.chromium.org/1611033
This roll sits after a revert to Skia's hairline change so,
hopefully, doesn't need any rebaselines. The try servers mostly agree
although there's one (clip-path-text-and-shape.svg on Windows) that I
need to keep on eye on. (That's why I'm landing this before MTV is
active.)
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45696 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
