Re: [webkit-dev] ccache on mac

[youenn fablet]

I had this setup working a year or so ago. I was using the regular Mac
"make" build.

Le dim. 7 mai 2017 à 19:28, Ben Kelly  a écrit :

> Hi all,
>
> Does anyone have ccache (or an equivalent) working with local webkit
> builds on mac?  I've spent the last couple of days trying to figure out,
> but have not had much luck.
>
> I've installed ccache via homebrew and its in my path.
>

Did the same. I had to ensure clang used by Xcode was the ccache proxy.
Don't remember whether just setting CC/CXX in the command line works.
When running make, you can see which clang is used.
Maybe setting CC/CXX in Source/WebCore/Configurations/Base.xcconfig would
do the trick (for WebCore).


> I *do* see ccache being used if I do a `webkit-build --cmake`, but I can't
> use run-safari or run-webkit-tests with a cmake build.  I get an error like:
>
>   Can't find built framework at
> "/srv/WebKit/WebKitBuild/dev/Debug/JavaScriptCore.framework/Versions/A/JavaScriptCore".
>

I think the CMake build is not complete in terms of executable. It would be
great if we could finalize it.
Alex knows a lot about this.


> If I do a non-cmake build I can successfully use run-safari and
> run-webkit-tests, but it appears ccache is not used.  It looks like its
> going through the xcode CLI tools.  I've searched for how to configure
> xcode to use ccache, but everything suggests I need to hand modify the
> project xcconfig.
>
> Can anyone recommend a good way to get local builds that work with
> run-safari/run-webkit-tests and that use ccache?
>
> (FWIW, the main reason I want ccache is that touching any idl file appears
> to trigger a rebuild of most of WebCore.)
>

Right, this is a known limitation of the current build system and something
that would be good to improve on.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] User agent woes

[Michael Catanzaro]

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.)


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.


Thanks,

Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] User agent woes

[Maciej Stachowiak]

> On May 6, 2017, at 5:19 PM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> You're probably aware that WebKitGTK+ has user agent quirks to make various 
> popular websites work, most notably google.com.  For our list of quirks, see:
> 
> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/UserAgentQuirks.cpp
> 
> Recently we had two major bugs caused by these quirks:
> 
> https://bugs.webkit.org/show_bug.cgi?id=171603 (New YouTube displays only 
> white page)
> https://bugs.webkit.org/show_bug.cgi?id=171770 (Google login fails on white 
> page)
> 
> In the case of the YouTube bug, I decided to just remove the quirk. This case 
> was pretty much a nightmare scenario, because Google decided that a random 
> subset of users would receive the new version of YouTube long in advance of 
> the rest of us. This means that we had a portion of our users complaining 
> that YouTube was "broken" for weeks when we were unable to reproduce the 
> issue (and had no way to do so; how could we have guessed it was some trial 
> program?).
> 
> Anyway, removing the quirk is not a good option for the generic google.com 
> quirk in the second bug. If we use a standard user agent, we receive a crap 
> unusable 1990s version of Google Calendar, a high source of user complaints, 
> and also the awesome 3D earth mode in Google Maps that our users expect is 
> unavailable. This makes users think that WebKit is bad. I found a solution, 
> but I know it's temporary; give it a few more months and Google will break us 
> again, no doubt.
> 
> User agent is an extremely demotivating, never-ending game, and it's by far 
> our biggest web compatibility problem. It almost feels as if Google is 
> deliberately trying to break WebKit, which I know is not true as they don't 
> care either way about us... but they do know full well that basing logic off 
> of user agent checks serves to harm less-popular browsers, so it's hardly 
> unintentional. I cannot think of any aspect of WebKit development less 
> gratifying than maintaining our user agent quirk list, nor any bigger user 
> agent offender than Google.
> 
> For a while I thought there was nothing we could do, but now I have an idea: 
> Safari could adopt the same (or lightly-adapted) user agent quirks that we 
> use for WebKitGTK+. Of course, only the small handful of websites to which we 
> currently need to send user agent quirks would be affected by this change: 
> Google, Yahoo, Slack, Whatsapp, Typekit, and some Chinese site Taobao. Now, 
> this would do no good for Safari, but it would be a huge help to us as it 
> would ensure that if these user agent offenders attempt to degrade 
> functionality for browsers not on their lists, they will have to at least 
> treat all WebKit browsers equally. Presumably they test to make sure their 
> websites work in Safari, so that should make this situation much better for 
> other ports. And if we run into problems, we at least know the change is 
> limited to this small set of websites.
> 
> I think the existing quirks would be fine for Safari with minimal changes. We 
> would definitely need to add some #if OS(UNIX) && !PLATFORM(COCOA) guards 
> inside urlRequiresLinuxDesktopPlatform(), and put if !PLATFORM(IOS) around 
> the quirks that are designed to turn off mobile versions of websites. This 
> would only be a small amount of work to set up, and it would only affect the 
> handful of websites that we have identified as problematic. Would Apple be 
> willing to allow this?
> 
> Alternatively, we could use the nuclear option and add a Chrome version 
> component, similar to how Chrome includes a Safari version in its user agent. 
> (Bonus: that will shut up Google's "switch to Chrome" ads for a couple weeks 
> until they figure it out.) Edge already includes a Chrome version. This would 
> undoubtedly be better for the web as a whole, but it would surely also 
> introduce serious short-term compatibility problems, as an unknown number of 
> websites would likely break horribly in Safari (and some known websites, e.g. 
> YouTube and Google Hangouts), so that's a pretty tough ask. Making it more 
> difficult for websites to send us crap versions of web pages would be good 
> for WebKit in the long term, but it's way safer to start only on quirks for 
> specific sites.
> 
> What do you think?

It's unlikely that we'll change the user agent that Safari (or other macOS or 
iOS WebKit clients) send for websites that already work correctly in Safari. I 
can think of at least four reasons:

(1) In general we'll only add site-specific hacks for prominent websites that 
are actively broken in Safari, and we do evangelism in parallel to be able 
remove them.
(2) We don't want the UA string environment observed by sites to become even 
more complicated.
(3) Changing the UA string is high risk. Even updating our own version number 
is a risky proposition. To the point that we've seriously considered 
permanently 

[webkit-dev] ccache on mac

[Ben Kelly]

Hi all,

Does anyone have ccache (or an equivalent) working with local webkit builds
on mac?  I've spent the last couple of days trying to figure out, but have
not had much luck.

I've installed ccache via homebrew and its in my path.

I *do* see ccache being used if I do a `webkit-build --cmake`, but I can't
use run-safari or run-webkit-tests with a cmake build.  I get an error like:

  Can't find built framework at
"/srv/WebKit/WebKitBuild/dev/Debug/JavaScriptCore.framework/Versions/A/JavaScriptCore".

If I do a non-cmake build I can successfully use run-safari and
run-webkit-tests, but it appears ccache is not used.  It looks like its
going through the xcode CLI tools.  I've searched for how to configure
xcode to use ccache, but everything suggests I need to hand modify the
project xcconfig.

Can anyone recommend a good way to get local builds that work with
run-safari/run-webkit-tests and that use ccache?

(FWIW, the main reason I want ccache is that touching any idl file appears
to trigger a rebuild of most of WebCore.)

Thanks!

Ben
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] User agent woes

[Michael Catanzaro]

On Sun, May 7, 2017 at 12:43 PM, Saam Barati  wrote:
This is not my area of expertise, but why can't you just adopt 
Safari's user agent instead of the other way around?


- Saam


Then our users won't be able to use Google Hangouts, as they'd only be 
able to download the macOS version of the Hangouts browser plugin. 
Using an OS X quirk is the very first thing I usually try.


Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] User agent woes

[Saam Barati]

> On May 6, 2017, at 5:19 PM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> You're probably aware that WebKitGTK+ has user agent quirks to make various 
> popular websites work, most notably google.com.  For our list of quirks, see:
> 
> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/UserAgentQuirks.cpp
> 
> Recently we had two major bugs caused by these quirks:
> 
> https://bugs.webkit.org/show_bug.cgi?id=171603 (New YouTube displays only 
> white page)
> https://bugs.webkit.org/show_bug.cgi?id=171770 (Google login fails on white 
> page)
> 
> In the case of the YouTube bug, I decided to just remove the quirk. This case 
> was pretty much a nightmare scenario, because Google decided that a random 
> subset of users would receive the new version of YouTube long in advance of 
> the rest of us. This means that we had a portion of our users complaining 
> that YouTube was "broken" for weeks when we were unable to reproduce the 
> issue (and had no way to do so; how could we have guessed it was some trial 
> program?).
> 
> Anyway, removing the quirk is not a good option for the generic google.com 
> quirk in the second bug. If we use a standard user agent, we receive a crap 
> unusable 1990s version of Google Calendar, a high source of user complaints, 
> and also the awesome 3D earth mode in Google Maps that our users expect is 
> unavailable. This makes users think that WebKit is bad. I found a solution, 
> but I know it's temporary; give it a few more months and Google will break us 
> again, no doubt.
> 
> User agent is an extremely demotivating, never-ending game, and it's by far 
> our biggest web compatibility problem. It almost feels as if Google is 
> deliberately trying to break WebKit, which I know is not true as they don't 
> care either way about us... but they do know full well that basing logic off 
> of user agent checks serves to harm less-popular browsers, so it's hardly 
> unintentional. I cannot think of any aspect of WebKit development less 
> gratifying than maintaining our user agent quirk list, nor any bigger user 
> agent offender than Google.
> 
> For a while I thought there was nothing we could do, but now I have an idea: 
> Safari could adopt the same (or lightly-adapted) user agent quirks that we 
> use for WebKitGTK+. Of course, only the small handful of websites to which we 
> currently need to send user agent quirks would be affected by this change: 
> Google, Yahoo, Slack, Whatsapp, Typekit, and some Chinese site Taobao. Now, 
> this would do no good for Safari, but it would be a huge help to us as it 
> would ensure that if these user agent offenders attempt to degrade 
> functionality for browsers not on their lists, they will have to at least 
> treat all WebKit browsers equally. Presumably they test to make sure their 
> websites work in Safari, so that should make this situation much better for 
> other ports. And if we run into problems, we at least know the change is 
> limited to this small set of websites.
> 
> I think the existing quirks would be fine for Safari with minimal changes. We 
> would definitely need to add some #if OS(UNIX) && !PLATFORM(COCOA) guards 
> inside urlRequiresLinuxDesktopPlatform(), and put if !PLATFORM(IOS) around 
> the quirks that are designed to turn off mobile versions of websites. This 
> would only be a small amount of work to set up, and it would only affect the 
> handful of websites that we have identified as problematic. Would Apple be 
> willing to allow this?
> 
> Alternatively, we could use the nuclear option and add a Chrome version 
> component, similar to how Chrome includes a Safari version in its user agent. 
> (Bonus: that will shut up Google's "switch to Chrome" ads for a couple weeks 
> until they figure it out.) Edge already includes a Chrome version. This would 
> undoubtedly be better for the web as a whole, but it would surely also 
> introduce serious short-term compatibility problems, as an unknown number of 
> websites would likely break horribly in Safari (and some known websites, e.g. 
> YouTube and Google Hangouts), so that's a pretty tough ask. Making it more 
> difficult for websites to send us crap versions of web pages would be good 
> for WebKit in the long term, but it's way safer to start only on quirks for 
> specific sites.
> 
> What do you think?
This is not my area of expertise, but why can't you just adopt Safari's user 
agent instead of the other way around?

- Saam

> 
> Michael
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev