655366 - Font-face origin checking does not respect document.domain

Status: RESOLVED WONTFIX

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

Description

[Tim Fisken]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

When checking if a request for a font using @font-face is cross domain, the full domain of the document is used, even if document.domain is set to a less restrictive value.

Reproducible: Always

Steps to Reproduce:
Store a font at http://files.example.com/font.woff . Create a document that references this font via @font-face, upload to http://www.example.com/test.html . In this document, use javascript to change document.domain to 'example.com'

Actual Results:  
Firefox should treat the font stored http://files.example.com/font.woff as from the same origin as the document at http://www.example.com/test.html , as it would for JavaScript, per https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript

Expected Results:  
files.example.com and www.example.com are treated as different origins, and the font file is not loaded.

Comment 1

[Boris Zbarsky [:bzbarsky]]

document.domain involves _both_ parties setting it to allow in the JS same-origin policy.  And the font file has no way to set document.domain on itself, so this can't work.  See the discussion in bug 567511 for some more details.

So I think this is invalid as filed...

That said, we don't seem to have an existing bug on using CORS for font-face file loads.  Should we have one?

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We do use CORS for font-face file loads.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ah, then that's the right way to handle this, not document.domain hackery.