On Mon, May 15, 2017 at 10:07 PM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Tue, May 16, 2017 at 5:45 AM, Ryosuke Niwa <rn...@webkit.org> 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 >>> 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. > > Regardless of the feature, there's no defined agreement on how it > should work when loaded from a file URL. A test author cannot divide > "this can load from a file URL" from "this needs to be loaded over > HTTP(S)". Except that loading over HTTP(S) always ought to work as > that much we've written down in standards.
Given we're talking about how these tests are ran inside WebKit, whether there is an agreement about this or not is sort of irrelevant. If a test doesn't run as expected, we can run it inside a HTTP server. Also, I'm not aware of any browser putting restrictions on how script or link elements are loaded. For example, if z.js exits at /Volumes/Data/bin/ and /Volumes/Data/bin/x/y.html loads z.js by <script src="../z.js"></script> then Chrome, Firefox, and Safari all happily execute z.js. Always using HTTP just because that's the lowest common denominator is not great given that it significantly affects the common development workflow people follow in WebKit. I really don't think there is a viable path for importing and using testharness.js in WebKit if we required that everyone must use HTTP sever. Even I wouldn't do it even though I'm otherwise supportive of writing more tests using testharness.js and upstreaming those tests back to web-platform-tests. - R. Niwa _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
