On Sun, May 14, 2017 at 12:35 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Sun, May 14, 2017 at 8:24 AM, Maciej Stachowiak <m...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
