Logdown icon not showing.

NEW
Unassigned

Status

()

Core
Layout: Text
P3
normal
2 years ago
a year ago

People

(Reporter: jhao, Unassigned)

Tracking

50 Branch
Points:
---

Firefox Tracking Flags

(firefox50 affected)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

2 years ago
Created attachment 8767452 [details]
Nightly

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

The icons are not showing.
(Reporter)

Comment 1

2 years ago
Created attachment 8767453 [details]
Chrome

Comparison with Chrome.
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)

Updated

2 years ago
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?
Flags: needinfo?(jhao)
(Reporter)

Comment 5

2 years ago
Latest OS X.
Flags: needinfo?(jhao)
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?

Updated

a year ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.