Re: [webkit-dev] Another WPT bite

[Brady Eidson]

> On May 8, 2017, at 10:42 PM, youenn fablet  wrote:
> 
> testharness.js does not need an http server. Some WPT goodies need the WPT 
> server.

I misunderstood since we were also discussing:

>> To continue moving forward, some of us are proposing to serve all tests in 
>> LayoutTests/wpt through the WPT server [1].

I think if somebody is writing a testharness.js test and it does *not* require 
the WPT server, it should be tested as a file URL.

This would imply putting it outside of LayoutTests/wpt though, right?

> I agree different frameworks offer different benefits. There is no reason we 
> should mandate one framework in particular.

Let me make it even more clear what I'm trying to defend. An ad-hoc custom test 
that uses no "framework" but is entirely self contained.

> In case there is no specific needs, it makes sense to me to recommend using 
> testharness.js, at least for those hacking WebCore.

I think it's valuable for engineers to be aware of the "frameworks" like 
testharness.js and js-test, and familiar with the facilities they provide, but 
to not necessarily imply that using any framework is expected.

Thanks,
 Brady___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

[Ryosuke Niwa]

On Mon, May 8, 2017 at 10:17 PM, Brady Eidson  wrote:
> On May 8, 2017, at 9:31 PM, youenn fablet  wrote:
>
> Hi all,
>
> Discussing with some WebKittens, testharness.js is more and more used in
> WebKit.
> Is it time to make testharness.js the recommended way of writing
> LayoutTests?
>
>
> Setting aside the pros or cons of testharness.js itself, I disagree with the
> principle of "1 single way to write all regression tests"
>
> In the past 11 years I've heard from multiple members of the team commenting
> on the benefits of different people writing regression tests in their own
> styles using their own techniques. We're capable of covering more edge cases
> when we don't have enforced uniformity. And I agree wholeheartedly.

Agreed.

> But now talking about testharness.js directly, I object on the grounds of "a
> file:// regression test is dirt easy to hack on and work with, whereas
> anything that requires me to have an httpd running is a PITA"

I think whether we use file:// or http:// is orthogonal point to using
testharness.js.  Many of the tests Chris and I have written using
testharness.js are checked into regular LayoutTests/ directories, and
they work just fine.

The imported web platform tests use WPT today because that's how
upstream works. But we're looking at ways to reduce the number of
tests that need to be ran under WPT for imported tests as well.

> I just object to making it the "recommended way" of writing tests.

Would you equally object to making js-test.js / js-test-pre.js the
recommended way of writing tests? If not, why?

What we're suggesting is to give preferential treatments to
testharness.js over js-test.js / js-test-pre.js when you were already
planning to write a test with the latter two scripts.

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

Re: [webkit-dev] Another WPT bite

[youenn fablet]

testharness.js does not need an http server. Some WPT goodies need the WPT
server.

I agree different frameworks offer different benefits. There is no reason
we should mandate one framework in particular.

In case there is no specific needs, it makes sense to me to recommend using
testharness.js, at least for those hacking WebCore. Chances are high that
another browser community might like running (and improving and
maintaining) it.
Chances are also high that one will have to debug/update such tests, so it
is good to learn this framework anyway.
Le lun. 8 mai 2017 à 22:17, Brady Eidson  a écrit :

> On May 8, 2017, at 9:31 PM, youenn fablet  wrote:
>
> Hi all,
>
> Discussing with some WebKittens, testharness.js is more and more used in
> WebKit.
> Is it time to make testharness.js the recommended way of writing
> LayoutTests?
>
>
> Setting aside the pros or cons of testharness.js itself, I disagree with
> the principle of "1 single way to write all regression tests"
>
> In the past 11 years I've heard from multiple members of the team
> commenting on the benefits of different people writing regression tests in
> their own styles using their own techniques. We're capable of covering more
> edge cases when we don't have enforced uniformity. And I agree
> wholeheartedly.
>
> But now talking about testharness.js directly, I object on the grounds of
> "a file:// regression test is dirt easy to hack on and work with, whereas
> anything that requires me to have an httpd running is a PITA"
>
> Note: I don't intend for any of this to mean I discourage the use of
> testharness.js tests. I don't. By all means, write them.
>
> I just object to making it the "recommended way" of writing tests.
>
> Thanks,
>  Brady
>
>
> To continue moving forward, some of us are proposing to serve all tests in
> LayoutTests/wpt through the WPT server [1].
> This would serve some purposes like increasing the use of WPT goodies:
> file-specific headers, templated tests (*.any.js), IDLParser, server-side
> scripts...
> It could also ease test migration from WebKit to W3C WPT.
>
> Some rules can guide whether adding tests to LayoutTests/wpt or
> LayoutTests/imported/w3c/web-platform-tests:
> - WebKit specific tests (crash tests, tests using internals...) in
> LayoutTests/wpt
> - Spec conformance/interoperability tests in
> LayoutTests/imported/w3c/web-platform-tests
>
>y
>
> [1]: bug 171479 
>
>
> ___
> 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

Re: [webkit-dev] Another WPT bite

[Brady Eidson]

> On May 8, 2017, at 9:31 PM, youenn fablet  wrote:
> 
> Hi all,
> 
> Discussing with some WebKittens, testharness.js is more and more used in 
> WebKit.
> Is it time to make testharness.js the recommended way of writing LayoutTests?

Setting aside the pros or cons of testharness.js itself, I disagree with the 
principle of "1 single way to write all regression tests"

In the past 11 years I've heard from multiple members of the team commenting on 
the benefits of different people writing regression tests in their own styles 
using their own techniques. We're capable of covering more edge cases when we 
don't have enforced uniformity. And I agree wholeheartedly.

But now talking about testharness.js directly, I object on the grounds of "a 
file:// regression test is dirt easy to hack on and work with, whereas anything 
that requires me to have an httpd running is a PITA"

Note: I don't intend for any of this to mean I discourage the use of 
testharness.js tests. I don't. By all means, write them.

I just object to making it the "recommended way" of writing tests.

Thanks,
 Brady

> 
> To continue moving forward, some of us are proposing to serve all tests in 
> LayoutTests/wpt through the WPT server [1].
> This would serve some purposes like increasing the use of WPT goodies: 
> file-specific headers, templated tests (*.any.js), IDLParser, server-side 
> scripts...
> It could also ease test migration from WebKit to W3C WPT.
> 
> Some rules can guide whether adding tests to LayoutTests/wpt or 
> LayoutTests/imported/w3c/web-platform-tests:
> - WebKit specific tests (crash tests, tests using internals...) in 
> LayoutTests/wpt
> - Spec conformance/interoperability tests in 
> LayoutTests/imported/w3c/web-platform-tests
> 
>y
> 
> [1]: bug 171479 
> 
> 
> ___
> 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

Re: [webkit-dev] Another WPT bite

[Chris Dumez]

> On May 8, 2017, at 9:44 PM, Geoffrey Garen  wrote:
> 
>> Is it time to make testharness.js the recommended way of writing LayoutTests?
> 
> What are the costs and benefits of testharness.js?

Benefit: 
- Tests would be more easily upstreamable to web-platform-tests, which are run 
by all major browser engines. This would help a lot in terms of 
interoperability. As previously discussed, Gecko and Blink already do automated 
export of tests to web-platform-tests. I believe we should do in the same 
direction and contribute more tests back.
- It is quite powerful (see documentation [1], has things like Promise tests, 
Worker tests and advanced assertions.

Cost:
- People are not necessarily used to it so there is a little bit of a learning 
curve. It is well documented though [1].

> 
> We usually try to make regression tests reductions of some larger problem to 
> aid debugging and to make testing fast. But testharness.js is 95kB. That's 
> kind of the opposite of a reduction.

It is proposed as a replacement to js-test.js, which a lot of us are already 
using in our layout tests. Using js-test.js or testharness.js has rarely 
interfered in my reductions, although it has happened to me.
For some tests, we’ll probably not use any framework. However, for most of 
them, I personally don’t see an issue.

[1] http://testthewebforward.org/docs/testharness-library.html 



> 
> Geoff
> 
>> 
>> To continue moving forward, some of us are proposing to serve all tests in 
>> LayoutTests/wpt through the WPT server [1].
>> This would serve some purposes like increasing the use of WPT goodies: 
>> file-specific headers, templated tests (*.any.js), IDLParser, server-side 
>> scripts...
>> It could also ease test migration from WebKit to W3C WPT.
>> 
>> Some rules can guide whether adding tests to LayoutTests/wpt or 
>> LayoutTests/imported/w3c/web-platform-tests:
>> - WebKit specific tests (crash tests, tests using internals...) in 
>> LayoutTests/wpt
>> - Spec conformance/interoperability tests in 
>> LayoutTests/imported/w3c/web-platform-tests
>> 
>>y
>> 
>> [1]: bug 171479 
>> 
>> 
>> ___
>> 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

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

Re: [webkit-dev] Another WPT bite

[Geoffrey Garen]

> Is it time to make testharness.js the recommended way of writing LayoutTests?

What are the costs and benefits of testharness.js?

We usually try to make regression tests reductions of some larger problem to 
aid debugging and to make testing fast. But testharness.js is 95kB. That's kind 
of the opposite of a reduction.

Geoff

> 
> To continue moving forward, some of us are proposing to serve all tests in 
> LayoutTests/wpt through the WPT server [1].
> This would serve some purposes like increasing the use of WPT goodies: 
> file-specific headers, templated tests (*.any.js), IDLParser, server-side 
> scripts...
> It could also ease test migration from WebKit to W3C WPT.
> 
> Some rules can guide whether adding tests to LayoutTests/wpt or 
> LayoutTests/imported/w3c/web-platform-tests:
> - WebKit specific tests (crash tests, tests using internals...) in 
> LayoutTests/wpt
> - Spec conformance/interoperability tests in 
> LayoutTests/imported/w3c/web-platform-tests
> 
>y
> 
> [1]: bug 171479 
> 
> 
> ___
> 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

[webkit-dev] Another WPT bite

[youenn fablet]

Hi all,

Discussing with some WebKittens, testharness.js is more and more used in
WebKit.
Is it time to make testharness.js the recommended way of writing
LayoutTests?

To continue moving forward, some of us are proposing to serve all tests in
LayoutTests/wpt through the WPT server [1].
This would serve some purposes like increasing the use of WPT goodies:
file-specific headers, templated tests (*.any.js), IDLParser, server-side
scripts...
It could also ease test migration from WebKit to W3C WPT.

Some rules can guide whether adding tests to LayoutTests/wpt or
LayoutTests/imported/w3c/web-platform-tests:
- WebKit specific tests (crash tests, tests using internals...) in
LayoutTests/wpt
- Spec conformance/interoperability tests in
LayoutTests/imported/w3c/web-platform-tests

   y

[1]: bug 171479 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Clang tidy

[Ryosuke Niwa]

On Wed, May 3, 2017 at 8:31 PM, Maciej Stachowiak  wrote:
>
>
> On May 3, 2017, at 6:31 PM, Olmstead, Don  wrote:
>
> I took some time today to see how clang-tidy can be run on WebKit code and
> openedhttps://bugs.webkit.org/show_bug.cgi?id=171632 with some examples on
> how to run things. I also attached some output from the modernizer fixes
> that can be applied.
>
> I was thinking of running any code we move from WebCore/platform through
> clang-tidy during the process of moving it to PAL. Documentation for the
> checks can be found at
> http://clang.llvm.org/extra/clang-tidy/checks/list.htmlif anyone wants to
> take a look at what should potentially be run.
>
>
> I think moving code should be done with the bare minimum changes needed to
> do the move (file paths, etc). Any code cleanup script should be done
> separately. Any change can break things (though we hope both moving files
> and running clang-tidy would have no behavioral effect). Therefore it's best
> not to mix unrelated changes, so if a regression occurs, it's easier to see
> what caused it.

I agree with Maciej and Konstantin that these code changes should be
made separately due to the risk of inadvertently introducing
regressions.

In addition, I don't really like code churns like this (as they make
SVN/Git blame less useful) unless we're fixing violations of WebKit
code style guideline: https://webkit.org/code-style-guidelines/

Many of the changes made in the aforementioned bug appear to be more
of nits that aren't explicitly called out in our guideline.

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

Re: [webkit-dev] ccache on mac

[Ben Kelly]

On Mon, May 8, 2017 at 10:25 AM, Alex Christensen 
wrote:

> It would be nice if we could just get the CMake built WebKit working with
> run-safari and run-webkit-tests.  That’s something I’ve been meaning to do
> for a while but haven’t gotten around to it.  Something is wrong with the
> xpc service locations and plists, but I think everything else should be ok
> since run-minibrowser works fine with WebKit1.  Let me know if you want to
> help out with this approach and I’ll give you more details
>

Ah, ok.  It wasn't obvious to me what was fully or partially supported.
Unfortunately I don't think I'll have time to work on the build system.  I
want to try to focus on web facing stuff if I can.

For the time being I worked around the issue with a few scripts using the
xcode build:

A clang wrapper like this:

#!/bin/bash
export CCACHE_CPP2=true
_xcode_path=`/usr/bin/xcode-select -p`
_xcode_clang="${_xcode_path}/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
exec /usr/local/bin/ccache "$_xcode_clang" "$@"

And then a build-webkit wrapper to pass them on the command line:

#!/bin/bash
build-webkit CC="/srv/bin/ccache-clang" CXX="/srv/bin/ccache-clang++" "$@"

Seems to be working.  I didn't realize before I could just pass CC/CXX on
the command line like this.

I guess I'll have to make this smarter or have separate scripts if I want
to build for ios or the simulator.

Anyway, just thought I would post that in case anyone else ran into the
same problem.

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

[Maciej Stachowiak]

> On May 8, 2017, at 1:30 PM, Michael Catanzaro  wrote:
> 
> On Mon, May 8, 2017 at 3:13 PM, Maciej Stachowiak  wrote:
>> 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?
> 
> I think it works just fine with our normal UA string, as it does with our 
> current Firefox quirk, actually. We could try adding url.host() != 
> talkgadget.google.com and url.host != hangouts.google.com checks to the 
> urlRequiresFirefoxBrowser function, but I don't see any need to do so. I only 
> mentioned Hangouts here to note that it prevents us from using a macOS quirk 
> for Google unless we're able to target a specific subdomain, which is not 
> always possible (e.g. maps.google.com is now just a redirect to 
> google.com/maps). If we try sending different quirks based on the URL path, 
> then getting the quirk to work becomes quite tricky because it requires 
> figuring out the right set of subresources on the page for which to receive 
> the quirk. So far, I've managed to avoid that mess.

I see, so your Google UA string is a tricky balancing act between the weird 
needs of many sites.

> 
> By the way, the icing on the cake is that X11 is only in the user agent for 
> compatibility purposes... Fedora has replaced X11 with Wayland now, and 
> Ubuntu will too in its next release this October. But removing X11 breaks 
> some websites (including Google Calendar), so it's going to have stay forever.

We have seriously considered freezing our UA string forever because even 
smaller changes than this can cause compat issues.

Regards,
Maciej

___
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 Mon, May 8, 2017 at 3:13 PM, Maciej Stachowiak  wrote:
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?


I think it works just fine with our normal UA string, as it does with 
our current Firefox quirk, actually. We could try adding url.host() != 
talkgadget.google.com and url.host != hangouts.google.com checks to the 
urlRequiresFirefoxBrowser function, but I don't see any need to do so. 
I only mentioned Hangouts here to note that it prevents us from using a 
macOS quirk for Google unless we're able to target a specific 
subdomain, which is not always possible (e.g. maps.google.com is now 
just a redirect to google.com/maps). If we try sending different quirks 
based on the URL path, then getting the quirk to work becomes quite 
tricky because it requires figuring out the right set of subresources 
on the page for which to receive the quirk. So far, I've managed to 
avoid that mess.


By the way, the icing on the cake is that X11 is only in the user agent 
for compatibility purposes... Fedora has replaced X11 with Wayland now, 
and Ubuntu will too in its next release this October. But removing X11 
breaks some websites (including Google Calendar), so it's going to have 
stay forever.


Cheers,

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 7, 2017, at 8:11 PM, Michael Catanzaro  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.

Regards,
Maciej

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

Re: [webkit-dev] ccache on mac

[Ben Kelly]

On Mon, May 8, 2017 at 12:32 AM, youenn fablet  wrote:

> 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 guess I'm hesitant to fiddle with Base.xcconfig because I don't want to
accidentally include those changes in patches, etc.

What is the syntax for overriding CC/CXX on the command line with
build-webkit?  (Or for the make build, although its unclear how to
configure that.)

I guess I was also hoping there was some way to specify a
'user-override.xcconfig' that the webkit build would try to pull-in
automatically where this stuff could be set.

Thanks.

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