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

Status: RESOLVED INVALID

(Core :: General, defect)

Description

[Pierre Mazière]

Attachment: 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)

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

[Pierre Mazière]

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

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

[Pierre Mazière]

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

[Pierre Mazière]

Attachment: how the test case should render and how it does not

Comment 6

[Boris Zbarsky [:bzbarsky]]

Yes, the rendering I see on the attached testcase is your "expected" rendering.

Comment 7

[Pierre Mazière]

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

Comment 8

[Boris Zbarsky [:bzbarsky]]

OK, so I just tried this on Linux.

1)  cd /tmp
2)  wget http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/18.0.2/linux-x86_64/en-US/firefox-18.0.2.tar.bz2
3)  Untar.
4)  Run.
5)  Load https://bugzilla.mozilla.org/attachment.cgi?id=712976

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

[Pierre Mazière]

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 ?

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

[Pierre Mazière]

ok thanks

Comment 12

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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.