RESOLVED FIXED69115
[GTK] Custom fonts on surlybikes.com and boingboing.net do not load
https://bugs.webkit.org/show_bug.cgi?id=69115
Summary [GTK] Custom fonts on surlybikes.com and boingboing.net do not load
Martin Robinson
Reported 2011-09-29 17:57:27 PDT
It seems that typekit is doing user-agent sniffing. Since we claim to be Safari, but not OS X by default, we must be detected as iOS. This means that we often get the lighter version of the sites and, in this case, no custom fonts.
Attachments
We won't do this anymore. (6.44 KB, patch)
2011-09-29 18:07 PDT, Martin Robinson
no flags
Pretend to be Chromium (6.15 KB, patch)
2011-11-17 21:39 PST, Martin Robinson
gustavo: review+
Martin Robinson
Comment 1 2011-09-29 18:07:00 PDT
Created attachment 109230 [details] We won't do this anymore.
Xan Lopez
Comment 2 2011-09-30 02:21:30 PDT
Comment on attachment 109230 [details] We won't do this anymore. Jesus. To be honest I don't know what to do here anymore. Feels to me we are just trying things randomly? :/
Xan Lopez
Comment 3 2011-09-30 02:24:51 PDT
I think we need a document somewhere explaining what each string does, because it seems each thing we do fixes something and breaks something else. For instance, is it a good idea at this point to have "Safari" in our UA?
Martin Robinson
Comment 4 2011-09-30 06:42:47 PDT
It's not random really. Sites are dividing Safari into a two buckets: iOS Safari and Desktop Safari. If you do not claim to be Desktop Safari, sites assume you are iOS Safari. This wasn't an issue when we first started because iOS Safari wasn't prevalent. I believe that if we remove Safari from the string we will see lots of broken sites. Even Chrome claims to be Safari and they are much more different from Safari than we are. I tried to add documentation via code comments to part I changed, but if necessary I can expand it to try to explain everything.
Martin Robinson
Comment 5 2011-09-30 08:12:12 PDT
Xan requested a deeper analysis, so I'm going to post a more detailed overview of the situation as I understand it. Safari: Claims to be Mozilla (very old sites used to differeniate between IE and Netscape/Firefox). Claims to be Safari. Safari may either be iOS or OS X (Desktop). The platform information is placed after the Mozilla string. Chromium: Claims to be Mozilla (see above). Claims to be Safari, because when Chromium was created, sites didn't test for it -- instead testing only for Safari. The platform string is correct for Chromium. For instance on Linux it claims to be Linux. WebKitGTK+: Traditionally we claimed to be Safari and Mozilla, for very similar reason to Chrome. We also appended our own identifier (WebKitGTK+). We have claimed to be Safari even *before* Gustavo's controversial patch at: https://bugs.webkit.org/show_bug.cgi?id=39617. That patch didn't really modify the default user agent much, but did make it so that the default user-agent overrides any custom one set on WebKitWebSettings when site-specific-quirk is set. This solution worked pretty well, because we were claiming to be Safari, like Chromium. Things have changed today though, because now that iOS is becoming prevalent sites are starting to trim down their content for mobile user-agents. They do this by sniffing the user-agent to differentiate between OS X Safari and iOS Safari. This is not an issue for Chromium, because these same sites also detect Chromium now. We have no hope (at this point) of getting sites to detect WebKitGTK+ in their scripts so, we need to intensify our Safari claim by also claiming that we are the OS X version of Safari. There is an alternative here which I considered originally. We can also claim to be Chromium. This avoids the need to claim to be OS X. The issue with this (which Oliver Hunt, I think, brought up on Gustavo's patch) is that sites may send different JavaScript to Chromium since it runs a different JavaScript engine. So in my patch, I took the more conservative approach.
Gustavo Noronha (kov)
Comment 6 2011-10-03 09:11:54 PDT
Comment on attachment 109230 [details] We won't do this anymore. View in context: https://bugs.webkit.org/attachment.cgi?id=109230&action=review I like this approach; it's a pitty we'll be lying even more to Google, but they had it coming =P. Xan, I don't really remember changes we did in U-A breaking stuff, it's just we found new stuff that was already broken, really. I don't think we have many options other than fine tuning as we find stuff that is broken, given the web's current state. > Source/WebKit/gtk/ChangeLog:14 > + prefix of the user agent hsa changed. hsa->has
Martin Robinson
Comment 7 2011-10-27 10:08:49 PDT
It seems that even yahoo.com is broken now. I'll write another patch which pretends to be Chromium.
Sergio Villar Senin
Comment 8 2011-11-16 00:57:26 PST
(In reply to comment #7) > It seems that even yahoo.com is broken now. I'll write another patch which pretends to be Chromium. Looks like they fixed it.
Martin Robinson
Comment 9 2011-11-17 21:39:43 PST
Created attachment 115736 [details] Pretend to be Chromium
Xan Lopez
Comment 10 2011-11-28 02:58:18 PST
Comment on attachment 115736 [details] Pretend to be Chromium So sad, but I'm OK with this. Guess we need 2 r+ since this is a bit like an API break.
Gustavo Noronha (kov)
Comment 11 2011-11-28 13:17:50 PST
Comment on attachment 115736 [details] Pretend to be Chromium I aprove of this message, unfortunately. (from the airport in São Paulo)
Martin Robinson
Comment 12 2011-11-29 07:50:15 PST
Note You need to log in before you can comment on or make changes to this bug.