[webkit-dev] Another WPT bite

[Ryosuke Niwa]

On Sun, May 14, 2017 at 12:35 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Sun, May 14, 2017 at 8:24 AM, Maciej Stachowiak <mjs at apple.com> 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 cases, the only value provided by the server is resolving the path to testharness.js. If tests referenced testharness.js via relative path, then most of the time they could be loaded as local files just fine, which would be more convenient (as well as, I believe, solving the "external trac link" issue).
>
> 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
> later found out it didn't work due to file URL restrictions. And you
> can't guarantee that something will work from a file URL, because
> there's no agreement on what will.

That's not an issue with most ref or testharness.js tests which tests
WebIDL, CSS OM, etc... because none of them have to do network
requests.

> I personally just keep web-platform-tests running and don't notice
> much overhead (MacBook Air, Mid 2012).

People at Apple tend to reboot their machines and install new OS all
the time so this is clearly an annoyance for us. I've rarely debugged
or created our own HTTP tests for the extra step that involves.

Even with all the shadow DOM and custom elements I wrote, I used
relative paths when I write them, and only removed relative path right
before I uploaded them to WPT repository. Furthermore, whenever I
debug those tests, the first thing I do is to rewrite the paths to
relative paths although these days, I've worked around that by adding
symlinks from /resources to LayoutTests/resources/ on multiple OS
installations.  Nonetheless, this remains to be one of the biggest
issue I have with WPT tests.

- R. Niwa