+++ This bug was initially created as a clone of Bug #760436 +++ Steps to reproduce: - Use sth like `<link rel="stylesheet" href="../Assets/Fonts/Proxima Nova/proxima-nova.css"/>` in your HTML file. - The `proxima-nova.css` defines an @font-face with a src in the same directory. - Load the HTML from the local file system (file: protocol). Actual results: Console (where "CSS" needs to be enabled first): ``` downloadable font: download failed (font-family: "Proxima Nova" style:normal weight:normal stretch:normal src index:1): status=2147500037 source: file:///[…]/Assets/Fonts/Proxima%20Nova/ProximaNova-Regular.otf ``` Expected results: Log this as a *security error* with a message like: `downloadable font: download not allowed due to same origin restriction (see KBxxxxx)` (This may also apply for same-origin violations with the http: or https: scheme.)

http font loads that are blocked by same-origin restriction get logged in the developer console, e.g. when visiting http://emojipedia.org, I see: - - - - - Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://getemoji.com/type/EmojiSymbols-Regular.woff. This can be fixed by moving the resource to the same domain or enabling CORS. downloadable font: download failed (font-family: "EmojiSymbols" style:normal weight:normal stretch:normal src index:0): bad URI or cross-site access not allowed source: http://getemoji.com/type/EmojiSymbols-Regular.woff - - - - - This was a fairly recent enhancement (bug 713980). Maybe what was done there should be made to apply to file: URLs as well?

I think your test case needs amending. When the WOFF file is in the same directory as the CSS file I would expect the font to be rendered, not blocked. This is a legitimate use case where people wish to download or develop a website offline and find that any pages in sub-directories are not rendering the font due to Bug 760436 - Font fails to load from local filesystem Downloadable font: download failed

"or enabling CORS" should probably be "or enabling CORS for that resource". Or something that gives a little more detail about what "enabling CORS" is exactly. Without the qualifier it sounds like CORS is a user-level pref that can be enabled.

Is this a webconsole bug? Can we move it to Core:Layout Text?