On Mon, May 15, 2017 at 10:07 PM, Anne van Kesteren wrote:
> On Tue, May 16, 2017 at 5:45 AM, Ryosuke Niwa wrote:
>>> I think the main problem with not running a server is that behavior
>>> for file URLs is not defined. And browsers tend to impose different
It makes sense to run WPT tests as HTTP URLs for conformance/regression
It is fine to run WPT tests as file based URLs for development purposes.
Tooling should make it possible to run WPT tests as HTTP URLs for
development purposes with minimum to no cost.
We are not there yet.
On Tue, May 16, 2017 at 5:45 AM, Ryosuke Niwa wrote:
>> I think the main problem with not running a server is that behavior
>> for file URLs is not defined. And browsers tend to impose different
>> restrictions there. So you might end up debugging something only to
I see two main cases:
- Writer of the patch is making sure to upstream WPT test changes at WebKit
landing time. It is ok to make the changes directly in
- Writer plans to upstream WPT test changes at some point but wants more
time. It is better to
Youenn is working on a patch to automatically create a GitHub PR to
export tests from a WebKit patch which includes changes to
That raises a question as to where we should put new tests or modified
tests intended to be exported to web-platform-tests from WebKit.
On Sun, May 14, 2017 at 12:35 AM, Anne van Kesteren wrote:
> On Sun, May 14, 2017 at 8:24 AM, Maciej Stachowiak wrote:
>> For the engineer use case, we can make a command-line tool to launch the
>> server and load the test. But it's kind of sad that in ~95% of
Mail list logo