Chromium: DRT should accept file path as an argument, not just url

[Dominic Mazzoni]

In the Mac port of DRT, you can give it a path to a test, for example:
  WebKitBuild/Release/DumpRenderTree LayoutTests/accessibility/textarea-line-for-index.html

In the Chromium port, this doesn't work - you have to give it a file:// url:
  out/Release/DumpRenderTree file:///home/user/.../chrome/src/third_party/WebKit/LayoutTests/accessibility/textarea-line-for-index.html

If you do try to pass a file path to the Chromium port of DRT, you get the render tree for the "file not found" page, which isn't at all obvious.

Let's just make DRT in Chromium accept a file path as an argument and automatically convert it to a file:// url.

[Eric Seidel (no email)]

This is a stupidly annoying bug.  Chromium is the odd-man out here.

[Dirk Pranke]

+1.

[Eric Seidel (no email)]

Mac uses NSURL to make this easy:

    NSURL *url;
    if ([pathOrURLString hasPrefix:@"http://"] || [pathOrURLString hasPrefix:@"https://"] || [pathOrURLString hasPrefix:@"file://"])
        url = [NSURL URLWithString:pathOrURLString];
    else
        url = [NSURL fileURLWithPath:pathOrURLString];
    if (!url) {
        fprintf(stderr, "Failed to parse \"%s\" as a URL\n", pathOrURL.c_str());
        return;
    }

It appears we have code to do this, it's just broken:
    params.testUrl = webkit_support::CreateURLForPathOrURL(command.pathOrURL);

[Eric Seidel (no email)]

http://code.google.com/searchframe#OAMlx_jo-ck/src/webkit/support/webkit_support.cc&exact_package=chromium&q=CreateURLForPathOrURL&type=cs&l=629

Looks like tkent is the last to touch that function.  It's possible we're just using it wrong.

[Tony Chang]

I think the problem is just with relative file names.  I pass in absolute paths all the time.

[Kent Tamura]

I have posted a patch: https://codereview.chromium.org/11366024/

[Eric Seidel (no email)]

Thank you.

[Kent Tamura]

crrev.com/165593 should fix this.