Font Loading API loads font file from scratch in addition to preload
Reported by
nazar.mo...@gmail.com,
Apr 6 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 Steps to reproduce the problem: 1. Have web page with custom web font 2. Use link[rel=preload][as=font] for font file 3. Call document.fonts.load() with the same font 4. Look at network tab of dev tools for font download requests What is the expected behavior? Font file is loaded once. What went wrong? Font file is correctly loaded once because of link[rel=preload][as=font] and incorrectly loaded once again from scratch on document.fonts.load() call (regardless if preloaded file was already fully loaded or not). Did this work before? No Does this work in other browsers? N/A Chrome version: 67.0.3390.0 Channel: canary OS Version: Ubuntu 18.04 Flash Version: Live demo with the same contents as attached file: http://jsbin.com/yalogeqise/edit?html
,
Apr 6 2018
Thanks for filing the issue! Checked the issue on reported chrome version 67.0.3390.0 and on the latest stable 65.0.3325.181 using ubuntu 14.04 and Ubuntu 17.10 with the below mentioned steps. 1. Launched Chrome 2. Downloaded the file double-file-load.html and opened in a new tab. 3. Navigated to http://jsbin.com/yalogeqise/edit?html We observed blank page after navigating to the .html file and didn't observe any fonts in jsbin file too. Attaching the screen cast of the same. @Reporter: Could you please have a look at the screen cast and let us know if we have missed anything. Any further inputs from your end may help us.
,
Apr 6 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 6 2018
You need to match the CORS mode of the non-preload resource, so adding 'crossorigin' (or crossorigin=anonymous) to the <link> should eliminate the double load.
,
Apr 6 2018
Interesting, [crossorigin] attribute helps. However, this is a bit counter-intuitive. Is this by design or something that should be improved?
,
Apr 6 2018
AFAICT, <link> is specced this way: https://html.spec.whatwg.org/multipage/semantics.html#obtaining-a-resource-from-a-link-element From an ergonomic standpoint I would tend to agree that this may not be optimal/intuitive though. (I.e using the default CORS mode for the destination ['as'] might've been more intuitive/expected.)
,
Apr 9 2018
Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 14.04 using chrome reported version #67.0.3390.0. This is a non-regression issue as it is observed from M60 old builds. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Apr 9 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by krajshree@chromium.org
, Apr 6 2018