1284041 - Logdown icon not showing.

Status: NEW

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Jonathan Hao (inactive) [:jhao]]

Attachment: Nightly

Using Nightly, navigating to http://logdown.com/dashboard (you need to log in)

The icons are not showing.

Comment 1

[Jonathan Hao (inactive) [:jhao]]

Attachment: Chrome

Comparison with Chrome.

Comment 2

[Timothy Nikkel (:tnikkel)]

Since a missing character hex symbol is drawn instead it looks like those icons are drawn using an icon font.

Comment 3

[Astley Chen (inactive)]

Attachment: simplied test case that used a twitter awesome font (icon font)

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

I cannot reproduce this issue on Nightly on Windows. Is it platform-specific? What system are you using?

Comment 5

[Jonathan Hao (inactive) [:jhao]]

Latest OS X.

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

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...

Comment 7

[Astley Chen (inactive)]

(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.

Comment 8

[Jonathan Kew [:jfkthame]]

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.)

Comment 9

[Astley Chen (inactive)]

(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

Comment 10

[Jonathan Kew [:jfkthame]]

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?