Closed Bug 678006 Opened 14 years ago Closed 14 years ago

Downloadable fonts in a different directory won't load with the file protocol

Categories

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

Product:
Core
Component:
Layout: Text and Fonts
Version:
7 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: josh.tumath+bugzilla, Unassigned)

Details

(Whiteboard: [parity-chrome])

Downloadable fonts (via the @font-face property) do not work in a document where the "file" protocol is used (which I assume is by design). This is an inconvenience for Web authors who are testing website designs on their computers before uploading them to a server. Also, this works fine on Chrome.
Whiteboard: [parity-chrome]
Version: unspecified → 7 Branch
I'd think it should work if the fonts are in the same directory as the page using them, since we're applying a cross-origin check to font loading, and different directories are considered different origins.
On my system, I come across the bug even if the WOFF file and the CSS file are in the same directory.
I think it's the HTML file vs. the WOFF file that matters.
Whoops. Sorry. The WOFF file that I've been using is corrupted. I've been using it for a while and I haven't noticed that the browser has been falling back to the truetype version of the font. That's partly why I've been having this bug. However, if the font can't be used if it is in a different directory, then that's still an inconvenience, so it would be appreciated if that could be changed so that they're not considered to be foreign. :)
Summary: Downloadable fonts won't work with the file protocol → Downloadable fonts in a different directory won't load with the file protocol
Font loads are subject to same-origin policy in Gecko, per spec. For file:// URIs, each file is a separate origin (it's not per-directory; it's per-file), though there are some hacks for considering files in the same directory as a given file or a subdirectory of it as same-origin in some rare cases. This is the case in Chrome too, without the same-directory escape valve, but they don't apply same-origin checks for font loads yet. Once they do, this will stop working in Chrome as well.. I really don't think we want to make an exception for font loads here, though the existence of the OTS sanitizer is likely to mean that all you can do is find out info about random fonts on the system... which you may be able to do anyway. But in general, lots and lots of stuff is "broken" when testing over file:// (including different treatment of various characters in URIs, different handling of XHR and font loads, different handling of some relative URIS, etc). So testing from file:// is just something to avoid; using a local web server is a much better idea.
You can circumvent the same-origin restriction for file:// URIs if you really want to, by setting the preference security.fileuri.strict_origin_policy to false in about:config. (I sometimes find this convenient for local testing, despite the various caveats mentioned by Boris.) This amounts to disabling a security-related feature, however. Use at your own risk!
OK. Well if it's mentioned in the spec that this isn't allowed, then I can understand that, so there no point in fixing this. But thanks for your help, everyone. I'll mark this as WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.