Base64 encoded font in data URI within @font-face is ignored when browsing over HTTPS




5 years ago
5 years ago


(Reporter: Pierre Mazière, Unassigned)


18 Branch

Firefox Tracking Flags

(Not tracked)



(2 attachments)



5 years ago
Created attachment 712976 [details]
test page for base64 encoded font embedded in font-face data uri

User Agent: Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130201065344

Steps to reproduce:

I use a base64 encoded font embedded in a CSS via the @font-face rule and a data uri.

In the test code I attached, I used a forged font defining only the character 'A' (with an easily identifiable glyph) to minimize the size of the base64 font.
I also added a base64 encoded image (a french flag), both in CSS and in a HTML IMG tag,  to check whether it was globally related to data uri, or more specifically to CSS data uri, or even more specifically to font-face rule within CSS.

Actual results:

When browsing the page over an HTTPS connection, the font is ignored by Firefox.
When browsing the page over an HTTP connection, the font is used correctly by Firefox.

the base64 encoded images, whether in CSS or in HTML IMG tag are displayed correctly in both cases.

Expected results:

The font should be used correctly by Firefox, whatever the connection used, as it happens with other tested browsers (chromium 22, opera 12)
Attachment #712976 - Attachment mime type: text/plain → text/html
Loading the attachment (which loads over HTTPS) works fine for me, both in Firefox 18 and on trunk.

Do you see the problem when you run in safe mode?

Comment 2

5 years ago
Same problem in safe mode: with the embedded font, the A should appear with the usual white 'triangle' filled in black, but it still appears as a regular A
Hmm.  You see that with the testcase attached to this bug, when loading it from the " test page for base64 encoded font embedded in font-face data uri" link above?

Because when I load that testcase (though on Mac, not Linux), I see an 'A' with the top part all filled in as you describe.

Comment 4

5 years ago
Yes, with the test case attached to this bug, from the link above: the A with the regular top part, not with the filled black triangle
To be clear I'll attach a screen shot of what the result should be should be, and what it actually is

Comment 5

5 years ago
Created attachment 713092 [details]
how the test case should render and how it does not
Yes, the rendering I see on the attached testcase is your "expected" rendering.

Comment 7

5 years ago
So, in order to confirm this bug, someone else must test it with a firefox compiled for linux.

I'm sure it's not a server issue since:
1/ other browsers behave as expected
2/ the files downloaded with wget via HTTP or HTTPS are strictly the same as verified by md5 checksum
OK, so I just tried this on Linux.

1)  cd /tmp
2)  wget
3)  Untar.
4)  Run.
5)  Load

The rendering looks like your "expected" rendering.

Just to check, is it possible that you have (or one of your extensions has) set your "security.mixed_content.block_active_content" preference to true?  The default value is false...

Comment 9

5 years ago
OK you have it ... my fault, sorry for the noise.

Could you just explain why base64 embedded fonts are considered as active content, but not base64 embedded images ?
Images are considered display content; there's a separate pref for that.

Fonts are considered active content, last I checked, because we hand them off to OS libraries, which we don't control, so there's a lot more security attack surface...

Comment 11

5 years ago
ok thanks
Last Resolved: 5 years ago
Resolution: --- → INVALID
Pierre, please try this in Firefox Nightly and let me know the results. When I view your bugzilla attachment in Nightly, it gives me the correct rendering even with the pref set. The handling of data: URLs was broken in previous releases, which is why the security.mixed_content.block_active_content preference was defaulted to false. We fixed that issue in bug 822367 or one of the related ones.
Blocks: 822367
You need to log in before you can comment on or make changes to this bug.