Bug 81299 – WebKitTestRunner layoutTestController.pathToLocalResource needs to be updated to work with WKTR

• Status: NEW
• Component: Tools / Tests

[Jessie Berlin]

http://trac.webkit.org/changeset/94976 and http://trac.webkit.org/changeset/95588 for https://bugs.webkit.org/show_bug.cgi?id=65781 updated pathToLocalResource for DRT, but did not update it for WKTR.

This is causing the following tests to fail on WK2:

fast/loader/local-CSS-from-local.html
fast/loader/local-JavaScript-from-local.html
fast/loader/local-image-from-local.html

http://build.webkit.org/results/Lion%20Intel%20Debug%20(WebKit2%20Tests)/r110925%20(4979)/fast/loader/local-CSS-from-local-pretty-diff.html
http://build.webkit.org/results/Lion%20Intel%20Debug%20(WebKit2%20Tests)/r110925%20(4979)/fast/loader/local-JavaScript-from-local-pretty-diff.html
http://build.webkit.org/results/Lion%20Intel%20Debug%20(WebKit2%20Tests)/r110925%20(4979)/fast/loader/local-image-from-local-pretty-diff.html

[Jessie Berlin]

Added expected failing results to get the bots green in http://trac.webkit.org/changeset/110928.

[Radar WebKit Bug Importer]

<rdar://problem/11061007>

[Jonathan Bedard]

Created attachment 332603 [details]
Patch

[Jonathan Bedard]

Comment on attachment 332603 [details]
Patch

Fairly certain that more layout test expectations are relying on the old behavior, I still need to track those down.

[EWS Watchlist]

Comment on attachment 332603 [details]
Patch

Attachment 332603 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/6255378

New failing tests:
http/tests/plugins/post-url-file.html

[EWS Watchlist]

Created attachment 332613 [details]
Archive of layout-test-results from ews104 for mac-sierra-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104  Port: mac-sierra-wk2  Platform: Mac OS X 10.12.6

[Alexey Proskuryakov]

Comment on attachment 332603 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=332603&action=review

> Tools/TestRunnerShared/SharedPathToLocalResource.h:31
> +JSStringRef sharedPathToLocalResource(JSStringRef localResourceJSString, JSStringRef testURL);
> +JSStringRef sharedPathToLocalResource(JSStringRef localResourceJSString, const std::string& testURL);

I don't think that "shared" should be in the name. The caller doesn't care where it's implemented, and readers will just wonder what a "shared path" is.

[Jonathan Bedard]

*** Bug 95043 has been marked as a duplicate of this bug. ***

[Jonathan Bedard]

(In reply to Jonathan Bedard from comment #8)
> *** Bug 95043 has been marked as a duplicate of this bug. ***

This is incorrect. Bug 95043 requires this bug to be fixed, but there seems to be another problem with http/tests/security/local-user-CSS-from-remote.html beyond the obvious.

[Jonathan Bedard]

Created attachment 332827 [details]
Patch

[Alexey Proskuryakov]

The latest patch was never marked for review, should it be?

[Jonathan Bedard]

(In reply to Alexey Proskuryakov from comment #11)
> The latest patch was never marked for review, should it be?

This was in support for on-device testing, which was de-prioritized around this time....there was some problem with the patch (which I don't recall) and I was trying to make sure that the change didn't get lost.

In short, no, it shouldn't be marked for review, but I should probably take another look at this and get something like it landed.