> On May 7, 2017, at 8:11 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
> Hi Maciej,
> I agree with basically everything you wrote, except I recommend not using OS 
> X as the operating system string in the default user agent except when 
> actually running on macOS. We tried this for about a year and got tons of 
> complaints. It breaks more than it fixes: many websites decide to present 
> only macOS versions of downloads and offer no recourse to get the right 
> version of the download (like Hangouts), and other times it's just annoying, 
> e.g. the OS field on Bugzilla defaults to OS X, which a substantial subset of 
> bug reporters feel the need to complain about. So instead, we now add OS X 
> quirks for websites when needed.
>> You mentioned that for some sites, that wouldn't work. I think it's 
>> reasonable to have more specific exceptions just for those, and we can 
>> review them together. Specifically, for Google Hangouts, you mention that 
>> claiming to be Mac Safari will offer a non-working plugin. However, it looks 
>> like WebKitGTK+ pretends to be Linux Firefox for Google sites instead. It 
>> seems very likely that a Linux Firefox UA string would break Google Hangouts 
>> in Mac Safari for pretty much the same reason.
> Yes, you definitely can't send a Linux+Firefox UA string, as that would 
> definitely break Hangouts for Safari users.
> But I bet you could send a macOS+Firefox UA string, until such time that 
> Google fixes its websites to stop sending inferior pages to other WebKit 
> browsers. That way, next time they decide to make a change based on UA that's 
> going to cause other WebKit browsers to break, Safari should break as well 
> and Google should notice before deploying the change if they test it at all. 
> (Of course, this is only really needed if evangelism fails.)

The ideal scenario would be for Google Hangouts to correctly handle WebKit UA 
strings on X11 platforms. It seems like Safari claiming to be Mac Firefox would 
be a move in the wrong direction. (It might also cause Hangouts to try to use 
features that are unsupported in Mac Safari.) 

What happens on Google Hangouts if you use your normal UA string?

>> It's not clear to me what the issues are with typekit or slack, or why you 
>> claim to be Chrome instead of Mac Safari on those.
> I don't remember exactly why I came up with the Chrome quirk for these sites, 
> but I usually try our macOS quirk first and use the Chrome quirk next if that 
> fails. The macOS quirk is much safer as it does not encourage websites to try 
> to use Chrome-specific JS.
> The issue with Typekit is that lots of websites use Typekit for web fonts, 
> but Typekit disables itself unless it recognizes the user agent. Then users 
> complain that fonts are wrong on a bunch of different websites. See 
> https://bugs.webkit.org/show_bug.cgi?id=147296.
> Slack just doesn't work at all with our default UA, it displays only an 
> unsupported browser page. It works perfectly fine with the UA changed.
>> Maybe claiming to be Mac Safari would reduce future breakage. Or if not, it 
>> would be interesting to know what the issue is.
>> We may also be able to reach out to some of the problem websites or help you 
>> get contact info.
> This would be wonderful. I don't think it's worthwhile to reach out to 
> websites like Slack and Whatsapp that are clearly intentionally trying to 
> block our users: I'd rather them not realize that we are sending UA quirks at 
> all, as they might try harder to block our users if so. But in other cases, 
> like with Google, we would really appreciate your help with evangelism. Let's 
> continue this line of discussion via private mail.

Sure, let's continue offline.


webkit-dev mailing list

Reply via email to