677210 - @font-face doesn't work when 'www' removed from URL

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[Edd Grant]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110622130550

Steps to reproduce:

I recently started using @font-face CSS on a site, whilst testing I noticed that FireFox seems to ignore the @font-face declaration if I remove the www. from the URL.

If I serve this URL then the @font-face is used correctly:

http://www.eddgrant.com/blog

however this does NOT work:

http://eddgrant.com/blog/

Have searched existing bugs and whilst similar to 638280 I couldn't find an exact match. Have also tested in Chromium which works correctly irrespective of whether the www. is present.


Using FireFox v5.0 on Ubuntu Desktop 10.10 AMD64


Actual results:

@font-face declaration seemed to be ignored when www. removed from URL.


Expected results:

@font-face declaration should have been utilised

Comment 1

[Thomas Ahlblom]

Reproduced (fonts look different):
Mozilla/5.0 (X11; Linux x86_64; rv:5.0.1) Gecko/20100101 Firefox/5.0.1
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0
Mozilla/5.0 (X11; Linux x86_64; rv:7.0a2) Gecko/20110807 Firefox/7.0a2
Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110808 Firefox/8.0a1

WFM (fonts look similar):
Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.9.168 Version/11.50
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30

Comment 2

[AndreiD[QA]]

I could reproduce the issue also on the latest Firefox Nightly, 
-> Windows 7:
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:8.0a1) Gecko/20110807 Firefox/8.0a1
Mozilla/5.0 (Windows NT 6.1; rv:8.0a1) Gecko/20110807 Firefox/8.0a1

-> Mac 10.6:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110807 Firefox/8.0a1

The fonts are visibly different if loading the same page with the www. prefix or without. If not a dupe, this can be set as NEW.

Comment 3

[Robert Longson [:longsonr]]

Have you followed the rules in https://developer.mozilla.org/en/HTTP_access_control as these are different domains.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Indeed.  The blog links to a stylesheet at http://www.eddgrant.com/blog/EdD/resource/fonts/BergamoStd/stylesheet.css using an absolute URI instead of using a site-relative URI.  The stylesheet uses a relative URI for the font, so the font is always loaded from www.eddgrant.com.  And since this is is not same-origin with eddgrant.com and the font file doesn't send access-control headers that would allow it to be used cross-origin, it doesn't get used.

Chrome and Opera don't implement same-origin restrictions on fonts yet.

Possible fixes are to send the right access-control headers or to use "/blog/EdD/resource/fonts/BergamoStd/stylesheet.css" as the stylesheet URI so that it's coming from the same origin as the blog page itself.

Comment 5

[Edd Grant]

Wow - thanks for the quick response all! Apologies, I'd overlooked the fact that the CSS was always served from the www domain. Do I understand that FireFox is actually correctly applying a same origin policy here? Is it likely that this will remain in place? If so then I'm happy to accept that and find an appropriate workaround.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Do I understand that FireFox is actually correctly applying a same origin
> policy here?

Yes.

> Is it likely that this will remain in place?

Yes.  See http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction for the draft spec text.

Comment 7

[Edd Grant]

Thanks for the info, in which case please feel free to close/ mark as invalid.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

To be clear, the best way to fix this problem on your end is to change:

(In reply to Boris Zbarsky (:bz) from comment #4)
> The blog links to a stylesheet at
> http://www.eddgrant.com/blog/EdD/resource/fonts/BergamoStd/stylesheet.css
> using an absolute URI instead of using a site-relative URI.

Comment 9

[Edd Grant]

Understood, unfortunately the URL is dynamically generated by the blog engine I use (Roller), will take it up with the Roller dev list to see what can be done. Ta.