<div dir="ltr">Thanks for your work on this, Žan!<div><br></div><div>That PR is now up at <a href="https://github.com/w3c/web-platform-tests/pull/9666">https://github.com/w3c/web-platform-tests/pull/9666</a> and in it I linked to <a href="https://github.com/w3c/web-platform-tests/pull/8979">https://github.com/w3c/web-platform-tests/pull/8979</a>, which is a PR I updated last week to support Safari, including Technology Review. I wish I'd payed closer attention to webkit-dev to see this thread earlier :)</div><div><br></div><div>Given that safaridriver and webkitdriver aren't the same piece of code, it makes sense to treat them as separate products in wpt run, and whether some code is shared is wpt-internal concern.</div><div><br></div><div>The reason I tried to get Safari (TP) running is ultimately for wpt.fyi and, and I don't imagine it'll be useful for WebKit CI.</div><div><br></div><div>Brian, I'll ask you on the PR about the WebDriver tests specifically.</div><div><br></div><div class="gmail_quote"><div dir="ltr">On Fri, Feb 23, 2018 at 7:25 PM <<a href="mailto:zan@falconsigh.net">zan@falconsigh.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
in case of no additional comments against this, I'll be opening a pull request to merge the web-platform-tests changes into that repository in the following days. The WebKit changes will follow after some further work.<br>
<br>
Cheers,<br>
Zan<br>
<br>
On Mon, Feb 12, 2018, at 4:06 PM, <a href="mailto:zan@falconsigh.net" target="_blank">zan@falconsigh.net</a> wrote:<br>
> Hi,<br>
><br>
> the web-platform-tests repository includes tooling that enables running<br>
> those tests against a supported browser product. I'd like to propose<br>
> adding generic WebKit support there.<br>
><br>
><br>
> Current changes only assume usage of the WebDriver protocol, and the<br>
> WebDriver binary accepting the --port flag. Selenium executors are used<br>
> for test harness and reftests. Same WebDriver implementation can also be<br>
> tested against the WebDriver tests included in the web-platform-tests<br>
> directory, presuming the tests are enabled or explicitly specified.<br>
><br>
> Only port-specific bit is the specification of capabilities that are<br>
> passed to the WebDriver binary, idea being that these capabilities are<br>
> the same as those supported by the WebDriver implementation.<br>
><br>
> GTK is for now the only port that's supported, and it's leveraging the<br>
> WebDriver implementation under Source/WebDriver/ in WebKit. WPE will be<br>
> doing the same. Safari I suppose could use its own WebDriver<br>
> implementation, or perhaps even a separate product.<br>
><br>
> Here's the current set of changes:<br>
> <a href="https://github.com/zdobersek/web-platform-tests/commit/c2ee920876ca6df7c4739feb8a6e03c77dffdb7f" rel="noreferrer" target="_blank">https://github.com/zdobersek/web-platform-tests/commit/c2ee920876ca6df7c4739feb8a6e03c77dffdb7f</a><br>
><br>
><br>
> The web-platform-tests suite can then be run like this for the GTK port,<br>
> assuming a tip-of-trunk build:<br>
><br>
> $ /work/web-platform-tests/wpt run --webkit-port=gtk \<br>
>     --webdriver-binary=WebKitBuild/Release/bin/WebKitWebDriver \<br>
>     --binary=WebKitBuild/Release/bin/MiniBrowser \<br>
>     --binary-arg=--automation \<br>
>     --binary-arg=--javascript-can-open-windows-automatically=true \<br>
>     --binary-arg=--enable-xss-auditor=false \<br>
>     webkit /2dcontext<br>
><br>
> This can be further wrapped into a python script and run as part of the<br>
> continuous integration system. These changes add a run-web-platform-<br>
> tests script that invokes the web-platform-tests runner tool, also<br>
> allowing each port to specify what tests to enable and what the expected<br>
> failures are:<br>
> <a href="https://github.com/Igalia/webkit/commit/df1aeeb9476c6dd220067f4fc3c6ad69a8f948ba" rel="noreferrer" target="_blank">https://github.com/Igalia/webkit/commit/df1aeeb9476c6dd220067f4fc3c6ad69a8f948ba</a><br>
><br>
> Only a small subset of tests is enabled there, for prototype purposes.<br>
> The expected results system could also be improved to avoid each<br>
> expected failure having to be marked as such in separate .ini files.<br>
><br>
><br>
> But foremost, I'd like to have a consensus of sorts about how various<br>
> WebKit ports should be handled in the web-platform-tests repository, so<br>
> that the changes there can proceed -- whether it's fine to implement a<br>
> generic WebKit product, or whether Safari would like to be treated as a<br>
> separate browser[1], etc.<br>
><br>
><br>
> Regards,<br>
> Zan<br>
><br>
><br>
> [1] There's for instance this from a year ago (though not sure about its<br>
> functionality):<br>
> <a href="https://github.com/w3c/web-platform-tests/tree/wptrunner-safari" rel="noreferrer" target="_blank">https://github.com/w3c/web-platform-tests/tree/wptrunner-safari</a><br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" rel="noreferrer" target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
</blockquote></div></div>