Issue metadata
Sign in to add a comment
|
MacV2Sandbox blocks access to/operations on fonts installed in $HOME/Library/Fonts |
||||||||||||||||||||||
Issue descriptionChrome Version: 64.0.3269.3 (Official Build) dev (64-bit) OS: macOS 10.13.1 What steps will reproduce the problem? (1) Go to https://www.google.com/get/noto/help/cjk/ and download super OTC packs for Noto Sans CJK and Noto Serif CJK. Uncompress and install fonts (36 instances of Noto Sans CJK and 28 instances of Noto Serif CJK insides the two TTC files. Make sure to install them in the home directory (/Users/<userid>/Library/Fonts) instead of system-wide (/Library/Fonts or /System/Library/Fonts ). (2) Start Chrome and go to chrome://flags. Search for 'Mac v2 sandbox' and explicitly enable it (instead of Default). (3) Try the following data urls and use DOM inspector to see what font is actually used. data:text/html;charset=utf-8,<span style="font-family: Helvetica, Noto Serif CJK KR; font-weight: 700;">abc%ED%95%9C%EA%B8%80abc</span> data:text/html;charset=utf-8,<span style="font-family: Times, Noto Sans CJK KR; font-weight: 700;">abc%ED%95%9C%EA%B8%80abc</span> (3) What is the expected result? Noto Sans CJK KR / Noto Serif CJK KR "Regular" is used for '한글'. (screen shot #3 : Firefox) and its weight matches that of 'abc' (bold) What happens instead? Noto Sans CJK JP Thin and Noto Serif CJK JP Extralight are used for '한글'. Both are the thinnest instance. 'JP' instance is also the first instance in the TTC. (screen shot #1). The weight does not match that of 'abc' (bold) Additional information: 1. This is is a regression. It used to work correctly. Firefox does not have this issue. 2. I haven't yet tried installing individual OTF files or per-weight OTC files (instead of one super OTC). If installing individual OTF files make this issue go away, the cause is mishandling of TTC/OTC files (always picking the 1st instance). 3. After finding a work-around for bug 786693 , I discovered this issue because my default sans-serif font is set to 'Noto Sans CJK KR'. When I go to web pages that do not specify a Korean font on my local machine, my font preference is supposed to kick in. It used to work correctly, but in the latest dev build, the thinnest weight is used. (screen shot #2 : http://sports.news.naver.com/kbaseball/news/read.nhn?oid=108&aid=0002661688 ). To reproduce this, the default sans-serif font has to be set to Noto Sans CJK KR. However, the root cause is what's reported here.
,
Nov 19 2017
Noto Sans CJK is not style-locked in its name table while Noto Serif CJK is style-locked only for regular and bold. Nonetheless, all the weights of theirs are treated as weight instances of a single font family. See the screen shot of macOS fontbook.
,
Nov 19 2017
Attached screenshot is the data url in comment 1 rendered with Chrome 62.0.3202.89 (Official Build) (64-bit) on macOS 10.12.5 data:text/html;charset=utf-8,<span style="font-family: Helvetica, Noto Sans CJK KR; font-weight: 700;">%ED%95%9C%EA%B8%80abc</span> Note that 'Noto Sans CJK KR Bold' is used for Korean characters while Latin letters are rendered with 'Helvetica'. There's no weight mismatch (both are bold).
,
Nov 20 2017
,
Nov 20 2017
Hmm... I was about to run bisect on my macOS 10.12.6 machine, but then realized that I couldn't reproduce it on macOS 10.12.6, but 10.13 still has this issue. The following works as expected on 10.12.6 in canary build (64.x) as well as in stable 62.x. data:text/html;charset=utf-8,<span style="font-family: Helvetica, Noto Sans CJK KR; font-weight: 700;">%ED%95%9C%EA%B8%80abc</span>. I'll run a bisect on macOS 10.13 where I observed (and still can reproduce) this issue.
,
Nov 20 2017
I bisected with the following command: python bisect-builds.py -a mac64 -g 499098 --verify-range -- --no-first-run and used the data url in comment 5. ----------------- You are probably looking for a change made after 508505 (known good), but no later than 508527 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/2a4edb39bc15c3b8aa854dd0597c7511ea913a1e..82f01613f105820a53f606925313ab7417835938 But in the range, nothing interesting popped up....
,
Nov 21 2017
Unable to reproduce the issue on Mac 10.13.1 using chrome reported version #64.0.3269.3. Attached a screen cast for reference. Following are the steps followed to reproduce the issue. ------------ (1) Navigated to https://www.google.com/get/noto/help/cjk/ and downloaded super OTC packs for Noto Sans CJK and Noto Serif CJK. Uncompressed and installed fonts. (2) Tried the following data urls and used DOM inspector to see what font is actually used. data:text/html;charset=utf-8,<span style="font-family: Noto Serif CJK KR; font-weight: 400;">%ED%95%9C%EA%B8%80abc</span> data:text/html;charset=utf-8,<span style="font-family: Noto Sans CJK KR; font-weight: 400;">%ED%95%9C%EA%B8%80abc</span> (3) Observed that Noto Sans CJK KR / Noto Serif CJK KR "Regular" is used as expected. jshin@ - Could you please check the attached screen cast and please let us know if anything missed from our side. Thanks...!!
,
Nov 22 2017
https://chromium.googlesource.com/chromium/src/+log/2a4edb39bc15c3b8aa854dd0597c7511ea913a1e..82f01613f105820a53f606925313ab7417835938 I manually bisected in the range above to find out which CL is to blame. (it took pretty long because I can reproduce it only on my personal Mac where I cannot use goma). Anyway, it's this change that triggered both this issue and bug 786693 : https://chromium.googlesource.com/chromium/src/+/fcd7b94fa Enable Finch Trial Test for MacV2Sandbox. -------------- It appears that a new sandbox is blocking certain access to/operations on fonts installed in $HOME/Library/Fonts (as opposed to the system location). Greg, how can I disable MacV2Sandbox ? Can I do that at chrome://flags ?
,
Nov 22 2017
> Greg, how can I disable MacV2Sandbox ? Can I do that at chrome://flags ? Ok. I disabled MacV2Sandbox in chrome://flags page and everything works fine ( bug 786693 and this bug)
,
Nov 22 2017
,
Nov 22 2017
,
Nov 22 2017
,
Nov 22 2017
I think I found a fix. ; https://crbug.com/11269 (allow file-read* (subpath (user-homedir-path "/Library/Fonts"))) is missing in rendere_v2.sb . I'll add that and try again.
,
Nov 22 2017
,
Nov 22 2017
,
Nov 22 2017
,
Nov 22 2017
Reproduction steps for bug 786693 (both on macOS 10.12 and 10.13) 1) Go to https://goo.gl/tnLJ1I (Google Web Fonts - Roboto page). At the lower-right corner, click on '1 Family selected'. In a box that comes up, click on 'Download icon' on the upper right corner. 2) Unzip Roboto.zip and open fonts in Fontbook. Install them in the home directory (as a user). If Roboto is installed system-wide, click on 'Computer' in Fontbook and disable Roboto there. Relaunch Fontbook and make sure Roboto is present in User tab while Roboto is not present or disabled in Computer tab. 3) In Chrome, go to chrome://flags and look for 'Mac v2 sandbox'. Explicitly enable it and relaunch chrome 4) Go to https://www.google.com/search?hl=en&q=한글 Actual: A lot of Tofus (empty boxes) Expected: Korean Hangul is shown.
,
Nov 22 2017
It's also important to retest issue 662686 - otherwise Mac OS downloadable fonts will stop working with SandboxV2.
,
Nov 22 2017
https://chromium-review.googlesource.com/c/chromium/src/+/784473 is a fix. On macOS 10.13, I can reproduce both this issue (comment 0) and bug 786693 (comment 17) and the above CL fixes both. On macOS 10.12, I can only reproduce bug 786693 (comment 17) and the above CL fixes it.
,
Nov 22 2017
re comment 19 : I tested bug 662686 with v2 sandbox explicitly enabled and it worked fine in Chrome canary (without any CL applied).
,
Nov 22 2017
,
Nov 22 2017
Thanks for retesting, sgtm.
,
Nov 22 2017
Well. on macOS 10.13, HanziPen* works fine (even though I can't find it in FontBook, DOM Inspector says that it uses the font - local font and the shape is definitely that of HanziPen). On macOS 10.12, with V2 sandbox enabled, that's not the case (even though I can find the font in FontBook). So, I guess the change forbug 662686 has to be reapplied to v2 sb rules.
,
Nov 22 2017
Issue 787892 has been merged into this issue.
,
Nov 29 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/768ca698306538681c3acca3c45de9cee32be907 commit 768ca698306538681c3acca3c45de9cee32be907 Author: Jungshik Shin <jshin@chromium.org> Date: Wed Nov 29 00:47:55 2017 Fixes font access in sandbox v2 1. Allows reading ~/Library/Fonts ( bug 786777 ) 2. Allows downloaded font access (bug 662686) Bug: 786777 ,662686 Test: See crbug.com/786777 (comment 0 and comment 17) and crbug.com/662686 Change-Id: I3734f38bc72d8324dc482849e5a4bcb3238b88e5 Reviewed-on: https://chromium-review.googlesource.com/784473 Commit-Queue: Jungshik Shin <jshin@chromium.org> Reviewed-by: Greg Kerr <kerrnel@chromium.org> Reviewed-by: Robert Sesek <rsesek@chromium.org> Cr-Commit-Position: refs/heads/master@{#519934} [modify] https://crrev.com/768ca698306538681c3acca3c45de9cee32be907/services/service_manager/sandbox/mac/renderer_v2.sb
,
Dec 1 2017
,
Dec 11 2017
Issue 791686 has been merged into this issue.
,
Oct 12
Issue 665725 has been merged into this issue. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by js...@chromium.org
, Nov 19 201777.4 KB
77.4 KB View Download