Run the Worker tests for resolveLocalFileSystemURL that were added

Run the Worker tests for resolveLocalFileSystemURL that were added
in http://trac.webkit.org/changeset/81640.

Includes updates to the testing framework to mirror the way NRWT
runs HTTP tests.

R=michaeln@chromium.org

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=79434

[adamk, 2011-03-22 20:24:47]

Tests pass locally, but not on try bots.  Investigating...

[adamk, 2011-03-22 21:25:10]

On 2011/03/22 20:24:47, adamk wrote:
> Tests pass locally, but not on try bots.  Investigating...

Can't reproduce the failure. I successfully git cl patched this onto a clean
branch on a different machine and was still able to pass the tests.  Not sure
where to look next...any hints on debugging try bot failures?  The main special
thing about these tests is their dependency on an HTTP server.

[levin, 2011-03-22 21:31:04]

On 2011/03/22 21:25:10, adamk wrote:
> On 2011/03/22 20:24:47, adamk wrote:
> > Tests pass locally, but not on try bots.  Investigating...
> 
> Can't reproduce the failure. I successfully git cl patched this onto a clean
> branch on a different machine and was still able to pass the tests.  Not sure
> where to look next...any hints on debugging try bot failures?  The main
special
> thing about these tests is their dependency on an HTTP server.

Does the output from the bot give you enough information to narrow it down? If
not, what other information do you need and can you add it?

(This will likely not be the last time something fails on the bot and not your
machine so investing a little here may pay off.)

[michaeln, 2011-03-22 21:32:50]

http://codereview.chromium.org/6727001/diff/1/chrome/test/ui/ui_layout_test.cc
File chrome/test/ui/ui_layout_test.cc (right):

http://codereview.chromium.org/6727001/diff/1/chrome/test/ui/ui_layout_test.c...
chrome/test/ui/ui_layout_test.cc:136:
new_layout_test_dir_.AppendASCII("js-test-resources");
Geez... so the fast/js/resources are also used for http tests? How are the files
picked up from this directory by the executing tests?

http://codereview.chromium.org/6727001/diff/1/chrome/test/ui/ui_layout_test.c...
chrome/test/ui/ui_layout_test.cc:226: StringPrintf("http://127.0.0.1:%d/", port)
+
+1 on this change

http://codereview.chromium.org/6727001/diff/1/content/worker/worker_uitest.cc
File content/worker/worker_uitest.cc (right):

http://codereview.chromium.org/6727001/diff/1/content/worker/worker_uitest.cc...
content/worker/worker_uitest.cc:737: RunLayoutTest(tests[i], 8000);
should 8000 by UILayoutTest::kHttpPort?

[michaeln, 2011-03-22 21:34:22]

Bot sayz...

Uncaught ReferenceError: debug is not defined," source:
http://127.0.0.1:8000/filesystem/resources/fs-worker-test-util.js"

[adamk, 2011-03-22 21:37:07]

On 2011/03/22 21:34:22, michaeln wrote:
> Bot sayz...
> 
> Uncaught ReferenceError: debug is not defined," source:
> http://127.0.0.1:8000/filesystem/resources/fs-worker-test-util.js%22

Right, which indicates that for some reason the reference to js-test-pre.js
isn't being picked up.  resolve-url.html tries to load it from
"/js-test-resources/js-test-pre.js".  My only explanation for this is that for
some reason that js-test-resources directory isn't being properly created on the
bots.

[adamk, 2011-03-22 21:41:00]

http://codereview.chromium.org/6727001/diff/1/chrome/test/ui/ui_layout_test.cc
File chrome/test/ui/ui_layout_test.cc (right):

http://codereview.chromium.org/6727001/diff/1/chrome/test/ui/ui_layout_test.c...
chrome/test/ui/ui_layout_test.cc:136:
new_layout_test_dir_.AppendASCII("js-test-resources");
On 2011/03/22 21:32:50, michaeln wrote:
> Geez... so the fast/js/resources are also used for http tests? How are the
files
> picked up from this directory by the executing tests?

<script src="/js-test-resources/js-test-pre.js">.  This is the same way it's
done when these tests are run under NRWT.

http://codereview.chromium.org/6727001/diff/1/chrome/test/ui/ui_layout_test.c...
chrome/test/ui/ui_layout_test.cc:226: StringPrintf("http://127.0.0.1:%d/", port)
+
On 2011/03/22 21:32:50, michaeln wrote:
> +1 on this change

Yeah, this is something that brings us in line with NRWT.  I was happy to see it
didn't break anything else.

http://codereview.chromium.org/6727001/diff/1/content/worker/worker_uitest.cc
File content/worker/worker_uitest.cc (right):

http://codereview.chromium.org/6727001/diff/1/content/worker/worker_uitest.cc...
content/worker/worker_uitest.cc:737: RunLayoutTest(tests[i], 8000);
On 2011/03/22 21:32:50, michaeln wrote:
> should 8000 by UILayoutTest::kHttpPort?

I don't think so, because 8000 seems to be NRWT's default.  Since the port is
referenced explicitly in the tests, this is needed to make sure the same JS can
run in DRT or here.

[michaeln, 2011-03-22 21:45:05]

> I don't think so, because 8000 seems to be NRWT's default.  Since the port is
> referenced explicitly in the tests, this is needed to make sure the same JS
can
> run in DRT or here.

Elsewhere in your test you're using kHttpPort, see the call to
InitializeForLayoutTest() on line 723.

[adamk, 2011-03-22 21:48:00]

On Tue, Mar 22, 2011 at 2:45 PM, <michaeln@chromium.org> wrote:

> I don't think so, because 8000 seems to be NRWT's default.  Since the port
>> is
>> referenced explicitly in the tests, this is needed to make sure the same
>> JS
>>
> can
>
>> run in DRT or here.
>>
>
> Elsewhere in your test you're using kHttpPort, see the call to
> InitializeForLayoutTest() on line 723.


Turns out this code is super-crufty: that kHttpPort is used only to trigger
some special behavior, it's not actually passed to anything that cares what
the number is.  See:

http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/chrome/test/ui/ui_l...

I could try to clean this up while I'm nearby, but I really don't think it
explains the trybot failures.  Fwiw, the server seems to have started up
properly on 8000, since it was able to serve fs-worker-test-util.js.

[adamk, 2011-03-22 23:03:42]

On Tue, Mar 22, 2011 at 2:47 PM, Adam Klein <adamk@chromium.org> wrote:

> On Tue, Mar 22, 2011 at 2:45 PM, <michaeln@chromium.org> wrote:
>
>>  I don't think so, because 8000 seems to be NRWT's default.  Since the
>>> port is
>>> referenced explicitly in the tests, this is needed to make sure the same
>>> JS
>>>
>> can
>>
>>> run in DRT or here.
>>>
>>
>> Elsewhere in your test you're using kHttpPort, see the call to
>> InitializeForLayoutTest() on line 723.
>
>
> Turns out this code is super-crufty: that kHttpPort is used only to trigger
> some special behavior, it's not actually passed to anything that cares what
> the number is.  See:
>
>
>
http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/chrome/test/ui/ui_l...
>
> I could try to clean this up while I'm nearby, but I really don't think it
> explains the trybot failures.  Fwiw, the server seems to have started up
> properly on 8000, since it was able to serve fs-worker-test-util.js.
>

I think I've figured it out, but I don't yet know what the solution is.  May
involve some hacking in WebKit/Tools/Scripts/webkitpy/...

[adamk, 2011-03-23 00:11:08]

On Tue, Mar 22, 2011 at 4:03 PM, Adam Klein <adamk@chromium.org> wrote:

> On Tue, Mar 22, 2011 at 2:47 PM, Adam Klein <adamk@chromium.org> wrote:
>
>> On Tue, Mar 22, 2011 at 2:45 PM, <michaeln@chromium.org> wrote:
>>
>>>  I don't think so, because 8000 seems to be NRWT's default.  Since the
>>>> port is
>>>> referenced explicitly in the tests, this is needed to make sure the same
>>>> JS
>>>>
>>> can
>>>
>>>> run in DRT or here.
>>>>
>>>
>>> Elsewhere in your test you're using kHttpPort, see the call to
>>> InitializeForLayoutTest() on line 723.
>>
>>
>> Turns out this code is super-crufty: that kHttpPort is used only to
>> trigger some special behavior, it's not actually passed to anything that
>> cares what the number is.  See:
>>
>>
>>
http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/chrome/test/ui/ui_l...
>>
>> I could try to clean this up while I'm nearby, but I really don't think it
>> explains the trybot failures.  Fwiw, the server seems to have started up
>> properly on 8000, since it was able to serve fs-worker-test-util.js.
>>
>
> I think I've figured it out, but I don't yet know what the solution is.
>  May involve some hacking in WebKit/Tools/Scripts/webkitpy/...
>

Success!

http://build.chromium.org/p/tryserver.chromium/builders/linux/builds/18137/st...

Note that this will involve a change in WebKit first.

[adamk, 2011-03-23 00:26:43]

Now blocking on https://bugs.webkit.org/show_bug.cgi?id=56884

[adamk, 2011-03-24 19:20:05]

One WebKit bug down, one to go: now blocking on
https://bugs.webkit.org/show_bug.cgi?id=57041.

[adamk, 2011-03-25 17:02:33]

Okay, this is ready for a final look.  Putting it on the trybots now...

[levin, 2011-03-25 17:11:11]

LGTM