[GTK][WPE] outlook.live.com displays old-fashioned UI

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Sergio Villar Senin]

Outlook email (former hotmail.com) displays a very old interface whenever logging in with WebKitGtk browsers. It isn't a matter of configuration on the server side because with the very same credentials I can see the new look and feel in any other browser.

Looks like we need to adjust the UA for those domains.

[Sergio Villar Senin]

Indeed adding a Chrome string just before Safari, for example "Chrome/72.0.3626.81" makes it show the new UI instead of the clunky old one.

[Sergio Villar Senin]

Patch coming soon...

[Sergio Villar Senin]

Created attachment 366808 [details]
Patch

[Michael Catanzaro]

Comment on attachment 366808 [details]
Patch

Can't you use the Mac platform quirk instead?

    // Microsoft Outlook Web App forces users with WebKitGTK+'s standard user
    // agent to use the light version. Earlier versions even blocks users from
    // accessing the calendar.
    if (domain == "outlook.live.com" || domain == "mail.ntu.edu.tw")
        return true;

Sadly there are a bazillion hosts running this service and we can't whitelist them all, but we can whitelist the main one at least.

[Sergio Villar Senin]

(In reply to Michael Catanzaro from comment #4)
> Comment on attachment 366808 [details]
> Patch
> 
> Can't you use the Mac platform quirk instead?
> 
>     // Microsoft Outlook Web App forces users with WebKitGTK+'s standard user
>     // agent to use the light version. Earlier versions even blocks users
> from
>     // accessing the calendar.
>     if (domain == "outlook.live.com" || domain == "mail.ntu.edu.tw")
>         return true;
> 
> Sadly there are a bazillion hosts running this service and we can't
> whitelist them all, but we can whitelist the main one at least.

Any reason in particular why we prefer to use a different arch instead of adding the Chrome UA? Is it just because we want the server to identify us as a WebKit browser instead of a Chromium one?

[Michael Catanzaro]

It's a safer quirk, yes. With a Chrome quirk there's greater risk of breakage if the site starts using Chrome-specific JS in the future, so the macOS quirk should be preferred whenever possible. The Chrome quirk has caused several problems in the past so it should only be used if there are no better options.

[Sergio Villar Senin]

Created attachment 366908 [details]
Patch

[Carlos Garcia Campos]

Comment on attachment 366908 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=366908&action=review

> Source/WebCore/platform/UserAgentQuirks.cpp:64
>  {
> -    String baseDomain = topPrivatelyControlledDomain(url.host().toString());
> +    String domain = url.host().toString();
> +    String baseDomain = topPrivatelyControlledDomain(domain);

This is not needed.

[Sergio Villar Senin]

Comment on attachment 366908 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=366908&action=review

>> Source/WebCore/platform/UserAgentQuirks.cpp:64
>> +    String baseDomain = topPrivatelyControlledDomain(domain);
> 
> This is not needed.

Right, forgot to delete it

[Sergio Villar Senin]

Created attachment 366922 [details]
Patch

[Sergio Villar Senin]

Committed r243971: <https://trac.webkit.org/changeset/243971>

[Sergio Villar Senin]

Comment on attachment 366922 [details]
Patch

Removing r? as the patch already landed