Bug 147296 – [FreeType] Typekit fonts do not work

• Status: RESOLVED
• Resolution: FIXED
• Component: Evangelism

[Elad Alfassa]

I'm not sure if this is the right sub-component, and I'm not sure if I picked the right version from the list.

I'm using Epiphany (also known as GNOME Web) and I noticed it doesn't handle base64 encoded web fonts. Many websites embed fonts within the CSS to reduce the number of HTTP requests...
One such example is The Verge ( http://www.theverge.com/ ), and there are many other examples across the web.

I mentioned this in a discussion in GNOME's bugzilla ( https://bugzilla.gnome.org/show_bug.cgi?id=752533 ), and was asked to file it here.

[Michael Catanzaro]

I tested this on Browsershots, and it works in Safari, so it's not a cross-platform issue. But I don't see why it would be a FreeType backend issue either, so I will change [Freetype] to [GTK] until we figure out what's up.

[Martin Robinson]

It looks like this is an issue with the user agent. The script that is serving fonts will not serve the proper fonts to us with our default user-agent. I have confirmed that the fonts load properly when using the user agent from Chromium in MiniBrowser "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/43.0.2357.130 Chrome/43.0.2357.130 Safari/537.36"

I think this is a regression from https://bugs.webkit.org/show_bug.cgi?id=132681, since reverting it locally seems to fix the issue. If I recall correctly (and I might not), this made our default user-agent string more like Safari and less like Chrome. Since there is no way we can add every single site that uses JavaScript-based CSS font libraries to the work-around list, perhaps we should use the Safari string as the work-around and the Chromey one as the default.

[Michael Catanzaro]

Wow, OK. So not a bug then. Thanks Martin....

Changing the default user agent is pretty much a hopeless endeavor; if we add Chrome, then we're just going to break more sites.

[Elad Alfassa]

The Verge uses Adobe typekit. I know many other websites do. So what if you add a quirk rule that sends the Chrome user agent to the adobe typekit server?

[Martin Robinson]

(In reply to comment #4)
> The Verge uses Adobe typekit. I know many other websites do. So what if you
> add a quirk rule that sends the Chrome user agent to the adobe typekit
> server?

This idea seems like it is worth a try!

[Michael Catanzaro]

The fonts are controlled by http://fonts.voxmedia.com/wvq7oai.js which seems to get them from either use.typekit.com or p.typekit.net or maybe both. We could try adding both of those to the quirks list and just use the existing quirk we have to add Chromium to the user agent.

Alternative: Adobe might fix it if somebody cares to complain. I visited https://typekit.com/ and found at the bottom of the page:

Email: [e-mail]

Twitter: @typekit

[Martin Robinson]

(In reply to comment #6)
> The fonts are controlled by http://fonts.voxmedia.com/wvq7oai.js which seems
> to get them from either use.typekit.com or p.typekit.net or maybe both. We
> could try adding both of those to the quirks list and just use the existing
> quirk we have to add Chromium to the user agent.

Looks like this only works if we make the quirk depend on theverge.com, which makes sense. The URL that matters is the security context that actually runs the JavaScript. I think we have a few options here:

1. Give up on typekit fonts, at least on most pages.
2. Use OS X or the Chromium user agent by default (this is what we did before https://bugs.webkit.org/show_bug.cgi?id=132681).
3. Push for a fix in typekit.

To be honest, #1 is akin to just giving up on rendering the web properly. Obviously #3 would be ideal, but I don't really see the issue with #2, since that was the old behavior.

I'm also reopening this bug.

[Michael Catanzaro]

I guess with #2 we'll probably have more problems and bug reports, and eventually a larger quirks list, since we are way more similar to Safari than to Chromium. But I really have no way to know, so I won't oppose that change.

But I half think we should just give up on pretending to be other browsers: do something minimal like "Mozilla/5.0 ($DISTRO; Linux x86_64) AppleWebKit/601.1 (KHTML, like Gecko) Epiphany/3.16.2" and maybe even remove the quirks list....

[Michael Catanzaro]

Closing this since it's a Typekit bug, not a WebKit bug.

[Martin Robinson]

Maybe we should leave it open until it's resolved. We need to advocate to fix this in TypeKit, but until that time it's the browser's responsibility to render the web correctly. This bug can also serve to track progress in TypeKit advocacy and to prevent duplicates.

[Michael Catanzaro]

I don't agree. There's nothing we can do about this except to change our UA. We can't do it with a quirks list, since we would have to add every site that uses Typekit, and we can't do it by default, since sites would try to use Chrome-specific JS, so there's nothing we can do in WebKit, so no reason to keep the bug open. This isn't the first bug that can't be fixed client-side, and it won't be the last.

I've brought this to the attention of Jon, Apple's web evangelist. He may or may not be able to get the Typekit developers to fix this.

[Martin Robinson]

(In reply to comment #11)
> I don't agree. There's nothing we can do about this except to change our UA.
> We can't do it with a quirks list, since we would have to add every site
> that uses Typekit, and we can't do it by default, since sites would try to
> use Chrome-specific JS, so there's nothing we can do in WebKit, so no reason
> to keep the bug open. This isn't the first bug that can't be fixed
> client-side, and it won't be the last.

I'm not going to insist the bug be open, but I think that just because there isn't a straight-forward fix today, doesn't mean that this isn't a real problem and that we shouldn't track it.

[Michael Catanzaro]

We just have a difference of opinion in how to handle bugs, then. :) I prefer to aggressively close bugs we don't plan to fix, certainly if there's nothing actionable.

[Myles C. Maxfield]

What is Epiphany's user agent string?

[Myles C. Maxfield]

(In reply to comment #14)
> What is Epiphany's user agent string?

Bram Stein (who works on the TypeKit team) mentioned he can get this straightened out if you send him the UA string. https://twitter.com/bram_stein/status/666503761276370944

[Carlos Garcia Campos]

(In reply to comment #2)
> It looks like this is an issue with the user agent. The script that is
> serving fonts will not serve the proper fonts to us with our default
> user-agent. I have confirmed that the fonts load properly when using the
> user agent from Chromium in MiniBrowser "Mozilla/5.0 (X11; Linux x86_64)
> AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/43.0.2357.130
> Chrome/43.0.2357.130 Safari/537.36"

I don't think UA string can be buggy (unless we don't follow the order or whatever), websites relying on UA strings and assuming there are only 3 browsers in the world are the buggy thing here. We don't fix anything in the browser engine, but work around buggy sites.

> I think this is a regression from
> https://bugs.webkit.org/show_bug.cgi?id=132681, since reverting it locally
> seems to fix the issue. If I recall correctly (and I might not), this made
> our default user-agent string more like Safari and less like Chrome. Since
> there is no way we can add every single site that uses JavaScript-based CSS
> font libraries to the work-around list, perhaps we should use the Safari
> string as the work-around and the Chromey one as the default.

This is the never ending story, we switched to Safari UA to fix a lot of sites trying to use chromium specific stuff. No matter what UA we use, there will always be broken sites. However, since we switched to Safari we have fewer problems, and I agree with Michael that switching back to chrome would make our quirk list longer.

[Martin Robinson]

(In reply to comment #14)
> What is Epiphany's user agent string?

It seems that distributions love to customize the user agent string for Epiphany, but the default Epiphany user agent in Ubuntu is this: 

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/601.1 (KHTML, like Gecko) Version/8.0 Safari/601.1 Ubuntu/15.10 (3.16.3-1ubuntu1) Epiphany/3.16.3

I think the important thing here is that we are AppleWebKit and not any version of iOS or OS X. The problem we often face is that WebKit + !OS X is detected as iOS.

[Martin Robinson]

(In reply to comment #13)
> We just have a difference of opinion in how to handle bugs, then. :) I
> prefer to aggressively close bugs we don't plan to fix, certainly if there's
> nothing actionable.

I think there are still actionable elements to this bug.

[Martin Robinson]

(In reply to comment #16)

> This is the never ending story, we switched to Safari UA to fix a lot of
> sites trying to use chromium specific stuff. No matter what UA we use, there
> will always be broken sites. However, since we switched to Safari we have
> fewer problems, and I agree with Michael that switching back to chrome would
> make our quirk list longer.

The reason I lean more toward the Chromey user agent is that (as far as I recall), the failures we have seen with it are individual sites. We can add quirks for individual sites. Meanwhile, the failures we see with the Safari one are in frameworks. We cannot add quirks for frameworks, because they are embedded in many web sites and the quirks code cannot detect that. Perhaps there is indeed a framework that fails with the Chromey user-agent. In that case, I suppose we should pick the one that breaks the least number of sites.

[Michael Catanzaro]

Martin, besides Typekit, what other framework are you aware of that has problems with our UA? I know we talked about jQuery's problems with touch detection, but to be clear, that is not a UA issue.

(In reply to comment #14)
> What is Epiphany's user agent string?

It's a *BIG* problem if there's no way to detect font format support asides from UA parsing. Relying on our UA means it will *ALWAYS* be broken for some browsers. Anyway, for me:

Mozilla/5.0 (Fedora; Linux x86_64) AppleWebKit/602.1 (KHTML, like Gecko) Version/8.0 Safari/602.1 Epiphany/3.18.0

But please don't look for "Epiphany" as you'll fix one browser but leave basically other WebKit browsers broken; just look for AppleWebKit and the version number there....

---

Note that we patch WebKit to put the distro branding in a different place than where it goes by default (the Ubuntu location in Martin's UA), since we want it to match where it goes in Firefox. This, too, breaks sites (Google Calendar assumes Linux without X11 means phone, and turns into crap); we can't win....

The other big problem I'm noticing is that sites are starting to check the architecture to decide whether to show a mobile site; they seem armv7l and think "oh it's ARM, must be a phone." Sucks for you if you're using an ARM-based desktop, but the only thing we can do is fake our arch in the UA... and then that gives wrong results if you ARE using a phone.

[Michael Catanzaro]

(In reply to comment #15) 
> Bram Stein (who works on the TypeKit team) mentioned he can get this
> straightened out if you send him the UA string.
> https://twitter.com/bram_stein/status/666503761276370944

Did anyone follow-up with Bram?

[Michael Catanzaro]

(In reply to comment #20)
> It's a *BIG* problem if there's no way to detect font format support asides
> from UA parsing. Relying on our UA means it will *ALWAYS* be broken for some
> browsers.

Perhaps we should repurpose this bug toward adding some way for browsers to detect font format support without relying on the user agent.

[Michael Catanzaro]

(In reply to comment #22)
> Perhaps we should repurpose this bug toward adding some way for browsers to
> detect font format support without relying on the user agent.

s/browsers/sites/

[Martin Robinson]

(In reply to comment #22)
> (In reply to comment #20)
> > It's a *BIG* problem if there's no way to detect font format support asides
> > from UA parsing. Relying on our UA means it will *ALWAYS* be broken for some
> > browsers.
> 
> Perhaps we should repurpose this bug toward adding some way for browsers to
> detect font format support without relying on the user agent.

iOS devices do support web fonts, as far as I know, but sites are not serving them because they are mobile devices. I'm not sure the issue is quite as simple as "supports web fonts or not."

[Michael Catanzaro]

I have discovered this page on typekit.com:

http://practice.typekit.com/lesson/caring-about-opentype-features/

It contains the following text:

"Wait a minute! You’re not seeing everything...
The example below illustrates OpenType features (common/standard ligatures number styles small caps) that your browser doesn’t yet support. You may want to switch to a different browser. You may also want to ask the folks who work on this browser for better OpenType feature support."

All of the features in the example work exactly as described, but the sliders to toggle them are grayed out as if insensitive. So the page is telling users WebKit does not support advanced font features, when in fact they work fine.

[Michael Catanzaro]

(I just found the Evangelism Bugzilla component. Let's use that, I suppose.)

[Michael Catanzaro]

(In reply to comment #25)
> All of the features in the example work exactly as described, but the
> sliders to toggle them are grayed out as if insensitive. So the page is
> telling users WebKit does not support advanced font features, when in fact
> they work fine.

To clarify: in that example, you can click on the sliders and they actually work fine, same as in Firefox, even though they appear insensitive in WebKit.

[Myles C. Maxfield]

(In reply to comment #27)
> (In reply to comment #25)
> > All of the features in the example work exactly as described, but the
> > sliders to toggle them are grayed out as if insensitive. So the page is
> > telling users WebKit does not support advanced font features, when in fact
> > they work fine.
> 
> To clarify: in that example, you can click on the sliders and they actually
> work fine, same as in Firefox, even though they appear insensitive in WebKit.

Yeah, I debugged that site a few weeks ago; they are doing naive UA detection along with a pre populated list of UAs that support font features. Unfortunately, they can't use @supports because we have had parsing support for the property for years (the properties just did nothing). Maybe they could use @supports with one of the newer properties I added, like font-variant-east-asian.

[Michael Catanzaro]

(In reply to comment #11)
> I don't agree. There's nothing we can do about this except to change our UA.
> We can't do it with a quirks list, since we would have to add every site
> that uses Typekit, and we can't do it by default, since sites would try to
> use Chrome-specific JS, so there's nothing we can do in WebKit, so no reason
> to keep the bug open.

This was wrong; if I add a Chromium quirk for typekit.net, the fonts load fine.

I was not able to figure out how to fix practice.typekit.com, though; it seems to be doing something different. :/

[Michael Catanzaro]

(In reply to comment #29) 
> This was wrong; if I add a Chromium quirk for typekit.net, the fonts load
> fine.

The quirk is actually needed for both typekit.net and typekit.com; one or the other is insufficient. I will post a patch in bug #142074.

[Alexey Proskuryakov]

<rdar://problem/28213706>

[Michael Catanzaro]

We fixed this a while back by sending a fake user agent to typekit.com and typekit.net.