Created attachment 8767452 [details] Nightly Using Nightly, navigating to http://logdown.com/dashboard (you need to log in) The icons are not showing.
Since a missing character hex symbol is drawn instead it looks like those icons are drawn using an icon font.
Component: Layout: Images → Layout: Text
Created attachment 8768090 [details] simplied test case that used a twitter awesome font (icon font)
Attachment #8768090 - Attachment mime type: text/plain → text/html
I cannot reproduce this issue on Nightly on Windows. Is it platform-specific? What system are you using?
Latest OS X.
Hmmm... I fail to reproduce with OS X either... Although I'm on OS X 10.10, I don't think there should be any difference...
(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #6) > Hmmm... I fail to reproduce with OS X either... Although I'm on OS X 10.10, > I don't think there should be any difference... I can reproduce on windows 10, macOS 10.11 with either the test site or simplified test cases as attached. Is it locale related ? AFAIK, it's using woff from FontAwesome.io with \f135 code point. Chrome can display the code point correctly but shown default missing character on gecko.
Are there any font-related messages in the web console when it fails? (Start a new browser session and open the web console *before* loading the testcase, otherwise you may not see any messages related to the font load due to caching.)
(In reply to Jonathan Kew (:jfkthame) from comment #8) > Are there any font-related messages in the web console when it fails? (Start > a new browser session and open the web console *before* loading the > testcase, otherwise you may not see any messages related to the font load > due to caching.) Looks like the font download was blocked due to cross-origin policy which is not seeing on chrome... 15:35:32.101 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://d1vzm1nztjpyu4.cloudfront.net/assets/fontawesome-webfont-18e6b5ff511b90edf098e62ac45ed9d6673a3eee10165d0de4164d4d02a3a77f.woff. (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘https://logdown.com’).(unknown) 15:35:32.101 downloadable font: download failed (font-family: "FontAwesome" style:normal weight:normal stretch:normal src index:0): bad URI or cross-site access not allowed source: https://d1vzm1nztjpyu4.cloudfront.net/assets/fontawesome-webfont-18e6b5ff511b90edf098e62ac45ed9d6673a3eee10165d0de4164d4d02a3a77f.woffattachment.cgi:2:12
Interesting. When I load the simplified testcase attached here, and then inspect the request for the font, I see that it is served with access-control-allow-origin:"https://bug1284041.bmoattachments.org" so the font loads successfully. In more detail, here's the request that gets made for the font: GET https://d1vzm1nztjpyu4.cloudfront.net/assets/fontawesome-webfont-18e6b5ff511b90edf098e62ac45ed9d6673a3eee10165d0de4164d4d02a3a77f.woff [HTTP/1.1 200 OK 0ms] Response headers: Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: GET Access-Control-Max-Age: 1728000 Age: 1064 Content-Length: 43572 Content-Type: application/font-woff Date: Wed, 06 Jul 2016 07:25:13 GMT Last-Modified: Tue, 14 Jun 2016 05:46:41 GMT Server: Cowboy Via: 1.1 vegur, 1.1 c66d7e31512bf340e32266eebd70b64a.cloudfront.net (CloudFront) X-Amz-Cf-Id: AgJZPfLP8W4TG5W317sKIJkZ66hCzm4rgf6yQJoE-YX6Zasd0J5TYw== X-Cache: Hit from cloudfront access-control-allow-origin: https://bug1284041.bmoattachments.org Request headers: Accept: application/font-woff2;q=1.0,application/font-woff;q=0.9,*/*;q=0.8 Accept-Encoding: identity Accept-Language: en-US,en;q=0.5 Connection: keep-alive DNT: 1 Host: d1vzm1nztjpyu4.cloudfront.net Origin: https://bug1284041.bmoattachments.org Referer: https://bug1284041.bmoattachments.org/attachment.cgi?id=8768090 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 Note the access-control-allow-origin header in the response, clearly added on the fly. I guess whatever they're doing to generate that on the server side may not be working correctly for all cases?
You need to log in before you can comment on or make changes to this bug.