Enable Worker-based FileSystem API ui_tests.

Enable Worker-based FileSystem API ui_tests.

Also add tests created since this test framework was originally created,
one of which is temporarily disabled waiting on a fix in WebKit and a roll.

BUG=32277
TEST=ui_tests

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

[kinuko, 2011-03-03 23:49:41]

Ah yes the similar change was in my local env for some time but was totally
forgotten.  Thanks for making them work!

LGTM assuming the tests pass.

[adamk, 2011-03-04 00:51:14]

On 2011/03/03 23:49:41, kinuko wrote:
> Ah yes the similar change was in my local env for some time but was totally
> forgotten.  Thanks for making them work!
> 
> LGTM assuming the tests pass.

Sigh, looks like these are flaky on Linux.  Will investigate a bit...

[adamk, 2011-03-04 00:58:50]

On 2011/03/04 00:51:14, Adam Klein wrote:
> On 2011/03/03 23:49:41, kinuko wrote:
> > Ah yes the similar change was in my local env for some time but was totally
> > forgotten.  Thanks for making them work!
> > 
> > LGTM assuming the tests pass.
> 
> Sigh, looks like these are flaky on Linux.  Will investigate a bit...

Actually, while the Mac failure looks like flakiness, the Linux failure seems
reproduceable: it's an assert in 


third_party/WebKit/Source/JavaScriptCore/wtf/CryptographicallyRandomNumber.cpp(146)
: uint32_t WTF::<unnamed>::ARC4RandomNumberGenerator::randomNumber()

[adamk, 2011-03-04 01:13:11]

On 2011/03/04 00:58:50, Adam Klein wrote:
> On 2011/03/04 00:51:14, Adam Klein wrote:
> > On 2011/03/03 23:49:41, kinuko wrote:
> > > Ah yes the similar change was in my local env for some time but was
totally
> > > forgotten.  Thanks for making them work!
> > > 
> > > LGTM assuming the tests pass.
> > 
> > Sigh, looks like these are flaky on Linux.  Will investigate a bit...
> 
> Actually, while the Mac failure looks like flakiness, the Linux failure seems
> reproduceable: it's an assert in 
> 
> 
>
third_party/WebKit/Source/JavaScriptCore/wtf/CryptographicallyRandomNumber.cpp(146)
> : uint32_t WTF::<unnamed>::ARC4RandomNumberGenerator::randomNumber()

Filed a bug: https://bugs.webkit.org/show_bug.cgi?id=55728

That'll hold this CL for a bit.

[adamk, 2011-03-04 23:03:33]

On 2011/03/04 01:13:11, Adam Klein wrote:
> On 2011/03/04 00:58:50, Adam Klein wrote:
> > On 2011/03/04 00:51:14, Adam Klein wrote:
> > > On 2011/03/03 23:49:41, kinuko wrote:
> > > > Ah yes the similar change was in my local env for some time but was
> totally
> > > > forgotten.  Thanks for making them work!
> > > > 
> > > > LGTM assuming the tests pass.
> > > 
> > > Sigh, looks like these are flaky on Linux.  Will investigate a bit...
> > 
> > Actually, while the Mac failure looks like flakiness, the Linux failure
seems
> > reproduceable: it's an assert in 
> > 
> > 
> >
>
third_party/WebKit/Source/JavaScriptCore/wtf/CryptographicallyRandomNumber.cpp(146)
> > : uint32_t WTF::<unnamed>::ARC4RandomNumberGenerator::randomNumber()
> 
> Filed a bug: https://bugs.webkit.org/show_bug.cgi?id=55728
> 
> That'll hold this CL for a bit.

Besides the webkit bug, it looks like these are generally flaky, which worries
me. Would it be bad to check them in all with FLAKY attached?

[kinuko, 2011-03-05 03:37:54]

The Mac trybots result have an assertion failure-- is it flaky and not 100%
reproducible?

(I don't have Mac build env right now, except for mac book, and cannot verify
it.)

On 2011/03/04 23:03:33, Adam Klein wrote:
> On 2011/03/04 01:13:11, Adam Klein wrote:
> > On 2011/03/04 00:58:50, Adam Klein wrote:
> > > On 2011/03/04 00:51:14, Adam Klein wrote:
> > > > On 2011/03/03 23:49:41, kinuko wrote:
> > > > > Ah yes the similar change was in my local env for some time but was
> > totally
> > > > > forgotten.  Thanks for making them work!
> > > > > 
> > > > > LGTM assuming the tests pass.
> > > > 
> > > > Sigh, looks like these are flaky on Linux.  Will investigate a bit...
> > > 
> > > Actually, while the Mac failure looks like flakiness, the Linux failure
> seems
> > > reproduceable: it's an assert in 
> > > 
> > > 
> > >
> >
>
third_party/WebKit/Source/JavaScriptCore/wtf/CryptographicallyRandomNumber.cpp(146)
> > > : uint32_t WTF::<unnamed>::ARC4RandomNumberGenerator::randomNumber()
> > 
> > Filed a bug: https://bugs.webkit.org/show_bug.cgi?id=55728
> > 
> > That'll hold this CL for a bit.
> 
> Besides the webkit bug, it looks like these are generally flaky, which worries
> me. Would it be bad to check them in all with FLAKY attached?

[adamk, 2011-03-07 18:28:49]

On Fri, Mar 4, 2011 at 7:37 PM, <kinuko@chromium.org> wrote:

> The Mac trybots result have an assertion failure-- is it flaky and not 100%
> reproducible?
>

It's flaky: I first put this change together on a Mac, and everything
passed.


> (I don't have Mac build env right now, except for mac book, and cannot
> verify
> it.)
>
>
> On 2011/03/04 23:03:33, Adam Klein wrote:
>
>> On 2011/03/04 01:13:11, Adam Klein wrote:
>> > On 2011/03/04 00:58:50, Adam Klein wrote:
>> > > On 2011/03/04 00:51:14, Adam Klein wrote:
>> > > > On 2011/03/03 23:49:41, kinuko wrote:
>> > > > > Ah yes the similar change was in my local env for some time but
>> was
>> > totally
>> > > > > forgotten.  Thanks for making them work!
>> > > > >
>> > > > > LGTM assuming the tests pass.
>> > > >
>> > > > Sigh, looks like these are flaky on Linux.  Will investigate a
>> bit...
>> > >
>> > > Actually, while the Mac failure looks like flakiness, the Linux
>> failure
>> seems
>> > > reproduceable: it's an assert in
>> > >
>> > >
>> > >
>> >
>>
>
>
>
third_party/WebKit/Source/JavaScriptCore/wtf/CryptographicallyRandomNumber.cpp(146)
>
>> > > : uint32_t WTF::<unnamed>::ARC4RandomNumberGenerator::randomNumber()
>> >
>> > Filed a bug: https://bugs.webkit.org/show_bug.cgi?id=55728
>> >
>> > That'll hold this CL for a bit.
>>
>
>  Besides the webkit bug, it looks like these are generally flaky, which
>> worries
>> me. Would it be bad to check them in all with FLAKY attached?
>>
>
>
>
> http://codereview.chromium.org/6609040/
>

[adamk, 2011-03-07 19:42:08]

On 2011/03/07 18:28:49, Adam Klein wrote:
> On Fri, Mar 4, 2011 at 7:37 PM, <mailto:kinuko@chromium.org> wrote:
> 
> > The Mac trybots result have an assertion failure-- is it flaky and not 100%
> > reproducible?
> >
> 
> It's flaky: I first put this change together on a Mac, and everything
> passed.

Looking at the code, this might be a legitimate bug in the code.  I suspect the
object being destroyed is a WorkerFileSystemCallbacksBridge, but it's a bit
tricky to track down what's triggering this assert without a stack trace.
 
> 
> > (I don't have Mac build env right now, except for mac book, and cannot
> > verify
> > it.)
> >
> >
> > On 2011/03/04 23:03:33, Adam Klein wrote:
> >
> >> On 2011/03/04 01:13:11, Adam Klein wrote:
> >> > On 2011/03/04 00:58:50, Adam Klein wrote:
> >> > > On 2011/03/04 00:51:14, Adam Klein wrote:
> >> > > > On 2011/03/03 23:49:41, kinuko wrote:
> >> > > > > Ah yes the similar change was in my local env for some time but
> >> was
> >> > totally
> >> > > > > forgotten.  Thanks for making them work!
> >> > > > >
> >> > > > > LGTM assuming the tests pass.
> >> > > >
> >> > > > Sigh, looks like these are flaky on Linux.  Will investigate a
> >> bit...
> >> > >
> >> > > Actually, while the Mac failure looks like flakiness, the Linux
> >> failure
> >> seems
> >> > > reproduceable: it's an assert in
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >
> >
> >
>
third_party/WebKit/Source/JavaScriptCore/wtf/CryptographicallyRandomNumber.cpp(146)
> >
> >> > > : uint32_t WTF::<unnamed>::ARC4RandomNumberGenerator::randomNumber()
> >> >
> >> > Filed a bug: https://bugs.webkit.org/show_bug.cgi?id=55728
> >> >
> >> > That'll hold this CL for a bit.
> >>
> >
> >  Besides the webkit bug, it looks like these are generally flaky, which
> >> worries
> >> me. Would it be bad to check them in all with FLAKY attached?
> >>
> >
> >
> >
> > http://codereview.chromium.org/6609040/
> >

[kinuko, 2011-03-07 20:04:33]

On Mon, Mar 7, 2011 at 11:42 AM, <adamk@chromium.org> wrote:

> On 2011/03/07 18:28:49, Adam Klein wrote:
>
>  On Fri, Mar 4, 2011 at 7:37 PM, <mailto:kinuko@chromium.org> wrote:
>>
>
>  > The Mac trybots result have an assertion failure-- is it flaky and not
>> 100%
>> > reproducible?
>> >
>>
>
>  It's flaky: I first put this change together on a Mac, and everything
>> passed.
>>
>
> Looking at the code, this might be a legitimate bug in the code.  I suspect
> the
> object being destroyed is a WorkerFileSystemCallbacksBridge, but it's a bit
> tricky to track down what's triggering this assert without a stack trace.


Ah looks like that's the case.   Would you mind filing a webkit bug for that
and cc me?

 > (I don't have Mac build env right now, except for mac book, and cannot
>> > verify
>> > it.)
>> >
>> >
>> > On 2011/03/04 23:03:33, Adam Klein wrote:
>> >
>> >> On 2011/03/04 01:13:11, Adam Klein wrote:
>> >> > On 2011/03/04 00:58:50, Adam Klein wrote:
>> >> > > On 2011/03/04 00:51:14, Adam Klein wrote:
>> >> > > > On 2011/03/03 23:49:41, kinuko wrote:
>> >> > > > > Ah yes the similar change was in my local env for some time but
>> >> was
>> >> > totally
>> >> > > > > forgotten.  Thanks for making them work!
>> >> > > > >
>> >> > > > > LGTM assuming the tests pass.
>> >> > > >
>> >> > > > Sigh, looks like these are flaky on Linux.  Will investigate a
>> >> bit...
>> >> > >
>> >> > > Actually, while the Mac failure looks like flakiness, the Linux
>> >> failure
>> >> seems
>> >> > > reproduceable: it's an assert in
>> >> > >
>> >> > >
>> >> > >
>> >> >
>> >>
>> >
>> >
>> >
>>
>
>
>
third_party/WebKit/Source/JavaScriptCore/wtf/CryptographicallyRandomNumber.cpp(146)
>
>> >
>> >> > > : uint32_t
>> WTF::<unnamed>::ARC4RandomNumberGenerator::randomNumber()
>> >> >
>> >> > Filed a bug: https://bugs.webkit.org/show_bug.cgi?id=55728
>> >> >
>> >> > That'll hold this CL for a bit.
>> >>
>> >
>> >  Besides the webkit bug, it looks like these are generally flaky, which
>> >> worries
>> >> me. Would it be bad to check them in all with FLAKY attached?
>> >>
>> >
>> >
>> >
>> > http://codereview.chromium.org/6609040/
>> >
>>
>
>
>
> http://codereview.chromium.org/6609040/
>

[adamk, 2011-03-07 21:47:07]

On Mon, Mar 7, 2011 at 12:04 PM, Kinuko Yasuda <kinuko@chromium.org> wrote:

> On Mon, Mar 7, 2011 at 11:42 AM, <adamk@chromium.org> wrote:
>
>> On 2011/03/07 18:28:49, Adam Klein wrote:
>>
>>  On Fri, Mar 4, 2011 at 7:37 PM, <mailto:kinuko@chromium.org> wrote:
>>>
>>
>>  > The Mac trybots result have an assertion failure-- is it flaky and not
>>> 100%
>>> > reproducible?
>>> >
>>>
>>
>>  It's flaky: I first put this change together on a Mac, and everything
>>> passed.
>>>
>>
>> Looking at the code, this might be a legitimate bug in the code.  I
>> suspect the
>> object being destroyed is a WorkerFileSystemCallbacksBridge, but it's a
>> bit
>> tricky to track down what's triggering this assert without a stack trace.
>
>
> Ah looks like that's the case.   Would you mind filing a webkit bug for
> that and cc me?
>

Filed as https://bugs.webkit.org/show_bug.cgi?id=55895.

I've updated this patch to disable the tests we know don't work on Linux and
sent them through the trybots for another go.  If Mac keeps failing on the
EntrySync test, I'd be inclined to mark that one FLAKY, point at the bug
above, and submit, so we can get these tests running regularly.

[kinuko, 2011-03-09 01:53:39]

On 2011/03/07 21:47:07, Adam Klein wrote:
> On Mon, Mar 7, 2011 at 12:04 PM, Kinuko Yasuda <mailto:kinuko@chromium.org>
wrote:
> 
> > On Mon, Mar 7, 2011 at 11:42 AM, <mailto:adamk@chromium.org> wrote:
> >
> >> On 2011/03/07 18:28:49, Adam Klein wrote:
> >>
> >>  On Fri, Mar 4, 2011 at 7:37 PM, <mailto:kinuko@chromium.org> wrote:
> >>>
> >>
> >>  > The Mac trybots result have an assertion failure-- is it flaky and not
> >>> 100%
> >>> > reproducible?
> >>> >
> >>>
> >>
> >>  It's flaky: I first put this change together on a Mac, and everything
> >>> passed.
> >>>
> >>
> >> Looking at the code, this might be a legitimate bug in the code.  I
> >> suspect the
> >> object being destroyed is a WorkerFileSystemCallbacksBridge, but it's a
> >> bit
> >> tricky to track down what's triggering this assert without a stack trace.
> >
> >
> > Ah looks like that's the case.   Would you mind filing a webkit bug for
> > that and cc me?
> >
> 
> Filed as https://bugs.webkit.org/show_bug.cgi?id=55895.

Thanks.  It took me a while to rebuild/debug things on my Macbook, but I think I
found the cause... just uploaded a patch.

> I've updated this patch to disable the tests we know don't work on Linux and
> sent them through the trybots for another go.  If Mac keeps failing on the
> EntrySync test, I'd be inclined to mark that one FLAKY, point at the bug
> above, and submit, so we can get these tests running regularly.

[adamk, 2011-03-09 19:25:34]

On 2011/03/09 01:53:39, kinuko wrote:
> On 2011/03/07 21:47:07, Adam Klein wrote:
> > On Mon, Mar 7, 2011 at 12:04 PM, Kinuko Yasuda <mailto:kinuko@chromium.org>
> wrote:
> > 
> > > On Mon, Mar 7, 2011 at 11:42 AM, <mailto:adamk@chromium.org> wrote:
> > >
> > >> On 2011/03/07 18:28:49, Adam Klein wrote:
> > >>
> > >>  On Fri, Mar 4, 2011 at 7:37 PM, <mailto:kinuko@chromium.org> wrote:
> > >>>
> > >>
> > >>  > The Mac trybots result have an assertion failure-- is it flaky and not
> > >>> 100%
> > >>> > reproducible?
> > >>> >
> > >>>
> > >>
> > >>  It's flaky: I first put this change together on a Mac, and everything
> > >>> passed.
> > >>>
> > >>
> > >> Looking at the code, this might be a legitimate bug in the code.  I
> > >> suspect the
> > >> object being destroyed is a WorkerFileSystemCallbacksBridge, but it's a
> > >> bit
> > >> tricky to track down what's triggering this assert without a stack trace.
> > >
> > >
> > > Ah looks like that's the case.   Would you mind filing a webkit bug for
> > > that and cc me?
> > >
> > 
> > Filed as https://bugs.webkit.org/show_bug.cgi?id=55895.
> 
> Thanks.  It took me a while to rebuild/debug things on my Macbook, but I think
I
> found the cause... just uploaded a patch.

So that will hopefully take care of the flakiness on Mac.  But I still see
flakiness on Windows.  If you have some time later today, I'd like to sit down
and dig into this a little bit.

> > I've updated this patch to disable the tests we know don't work on Linux and
> > sent them through the trybots for another go.  If Mac keeps failing on the
> > EntrySync test, I'd be inclined to mark that one FLAKY, point at the bug
> > above, and submit, so we can get these tests running regularly.

[adamk, 2011-03-09 21:30:34]

Looks like the Windows failures aren't actually flakiness, but instead are a
problem in BlobURLRequestJob doing File I/O: only the FileWriter tests are
failing.

Working on getting a stack trace...

[adamk, 2011-03-09 22:57:12]

On 2011/03/09 21:30:34, Adam Klein wrote:
> Looks like the Windows failures aren't actually flakiness, but instead are a
> problem in BlobURLRequestJob doing File I/O: only the FileWriter tests are
> failing.
> 
> Working on getting a stack trace...

Found it, fix up for review at http://codereview.chromium.org/6612051/

[adamk, 2011-03-10 01:13:49]

On 2011/03/09 22:57:12, Adam Klein wrote:
> On 2011/03/09 21:30:34, Adam Klein wrote:
> > Looks like the Windows failures aren't actually flakiness, but instead are a
> > problem in BlobURLRequestJob doing File I/O: only the FileWriter tests are
> > failing.
> > 
> > Working on getting a stack trace...
> 
> Found it, fix up for review at http://codereview.chromium.org/6612051/

I've disabled the Windows tests for now to decouple these changes.  Will
re-enable them with 6612051 when I land it (if this one beats it).

[kinuko, 2011-03-10 01:40:15]

LGTM

http://codereview.chromium.org/6609040/diff/11002/chrome/worker/worker_uitest.cc
File chrome/worker/worker_uitest.cc (right):

http://codereview.chromium.org/6609040/diff/11002/chrome/worker/worker_uitest...
chrome/worker/worker_uitest.cc:754: // TODO(adamk): Enable these when landing
http://codereview.chromium.org/6612051
It would be great if you file a bug and refer the crbug url instead of
codereview one.

[adamk, 2011-03-10 01:47:35]

On Wed, Mar 9, 2011 at 5:40 PM, <kinuko@chromium.org> wrote:

> LGTM
>
>
>
>
http://codereview.chromium.org/6609040/diff/11002/chrome/worker/worker_uitest.cc
> File chrome/worker/worker_uitest.cc (right):
>
>
>
http://codereview.chromium.org/6609040/diff/11002/chrome/worker/worker_uitest...
> chrome/worker/worker_uitest.cc:754: // TODO(adamk): Enable these when
> landing http://codereview.chromium.org/6612051
> It would be great if you file a bug and refer the crbug url instead of
> codereview one.


Done, filed as 75548 and changed the comment to refer to that.


>
>
> http://codereview.chromium.org/6609040/
>