Import web-platform-tests/webstorage

Import web-platform-tests/webstorage

update-w3c-deps import using blink 3ede5e3bc34de02ff6df5ab5aa741807593705ab:

imported csswg-test@e33ea2b35c61182efffe45beb340a65357a3ad38
imported web-platform-tests@2f4e521222b7901f4d3a5e09a2489e773c8be424

BUG=505666, 362788
R=michaeln@chromium.org,dpranke@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=198341

[jsbell, 2015-06-30 00:33:36]

This assumes a clean import has been done first.

I'm not thrilled about how iframe/ is handled. Maybe we should rename it
upstream to one of the more common names before merging.

The idlharness.html failure is usual bindings cruft affecting every feature.

The builtins failure is bindings related; apparently in FF/Gecko the storage API
entry points (e.g. localStorage.key) can't be overwritten, but they can be in
Chrome/Blink. The spec doesn't say anything special here.

I haven't looked at the quota/timeout failures.

[michaeln, 2015-06-30 02:10:03]

lgtm

Changing /iframe to /resources would be an improvement. Do many other wc3 test
suites have one off subdirectory naming schemes? If so, a data driven way to
tell the importer about the one off names per-test-suite might make sense?

> I haven't looked at the quota/timeout failures.

Hmmm, they pass when running m44 beta against the tests at
http://w3c-test.org/webstorage/

How much time do these tests have to run and are they doing so in parallel with
many other tests? This test will have to exceed 10 MBytes of data before it
passes. Looks like it's using about 16 bytes per loop. More than half million
iterations and ipcs and something like 10x thread context switches before it
gets there. Maybe with contention it takes "too long". If so, much larger keys
&| values might help.

 16             var index = 0;
 17             var key = "name";
 18             var val = "user";
 19 
 20             assert_throws("QUOTA_EXCEEDED_ERR", function() {
 21                 while (true) {
 22                     index++;
 23                     sessionStorage.setItem("" + key + index, "" + index);
 24                 }

[jsbell, 2015-06-30 17:22:19]

On 2015/06/30 02:10:03, michaeln wrote:
> lgtm
> 
> Changing /iframe to /resources would be an improvement. Do many other wc3 test
> suites have one off subdirectory naming schemes? If so, a data driven way to
> tell the importer about the one off names per-test-suite might make sense?

I'll follow up with jgraham

> If so, much larger keys &| values might help.

I'll give this a whirl.

As an aside, just last night converted and then upstreamed the blink storage
tests to webstorage/ so I'll need to rerun this and pull them in too. Hopefully
they still pass.

[Dirk Pranke, 2015-06-30 17:44:16]

On 2015/06/30 00:33:36, jsbell wrote:
> This assumes a clean import has been done first.
> 
> I'm not thrilled about how iframe/ is handled. Maybe we should rename it
> upstream to one of the more common names before merging.
> 
> The idlharness.html failure is usual bindings cruft affecting every feature.
> 
> The builtins failure is bindings related; apparently in FF/Gecko the storage
API
> entry points (e.g. localStorage.key) can't be overwritten, but they can be in
> Chrome/Blink. The spec doesn't say anything special here.
> 
> I haven't looked at the quota/timeout failures.

renaming sounds like a good idea. I defer to Michael otherwise.

[jsbell, 2015-06-30 18:30:12]

PR for the rename: https://critic.hoppipolla.co.uk/r/5424

... but after discussing w/ jgraham, I filed crbug.com/505894 for identifying
test/resource files the canonical way. I don't know if they'll accept the PR. We
may want to just [Skip] for now.

Also, a bunch of the newly imported tests appear buggy. :( I'll see if I can
diagnose the cause before we import 'em.

[Dirk Pranke, 2015-07-01 19:49:04]

On 2015/06/30 18:30:12, jsbell wrote:
> PR for the rename: https://critic.hoppipolla.co.uk/r/5424
> 
> ... but after discussing w/ jgraham, I filed crbug.com/505894 for identifying
> test/resource files the canonical way. I don't know if they'll accept the PR.
We
> may want to just [Skip] for now.

I'm not personally a fan of requiring manifests in order for things to work, and
I think they should be following naming conventions where possible, so hopefully
they will accept the patch.

[jsbell, 2015-07-01 22:33:15]

Ms2ger and I got the upstream test issues sorted out. iframe->resources PR still
outstanding but it got an r+ pending a rebase so maybe?

https://codereview.chromium.org/1220543007/diff/20001/LayoutTests/TestExpecta...
File LayoutTests/TestExpectations (right):

https://codereview.chromium.org/1220543007/diff/20001/LayoutTests/TestExpecta...
LayoutTests/TestExpectations:1657: 
Ugh, I'll remove this whitespace.

https://codereview.chromium.org/1220543007/diff/20001/LayoutTests/http/tests/...
File LayoutTests/http/tests/resources/testharnessreport.js (right):

https://codereview.chromium.org/1220543007/diff/20001/LayoutTests/http/tests/...
LayoutTests/http/tests/resources/testharnessreport.js:19:
testRunner.setCanOpenWindows();
Some of the new webstorage tests pop open windows.

I don't see a disadvantage to turning these on for all testharness.js-based
tests, but others may...?

If we're concerned, I can [Skip] those tests for now and file a separate bug to
turn this on.

https://codereview.chromium.org/1220543007/diff/20001/LayoutTests/http/tests/...
File LayoutTests/http/tests/w3c/resources/testharnessreport.js (right):

https://codereview.chromium.org/1220543007/diff/20001/LayoutTests/http/tests/...
LayoutTests/http/tests/w3c/resources/testharnessreport.js:19:
testRunner.setCanOpenWindows();
And keep all copies in sync...

https://codereview.chromium.org/1220543007/diff/20001/LayoutTests/imported/we...
File
LayoutTests/imported/web-platform-tests/html/browsers/windows/browsing-context-names/browsing-context-default-name-expected.txt
(left):

https://codereview.chromium.org/1220543007/diff/20001/LayoutTests/imported/we...
LayoutTests/imported/web-platform-tests/html/browsers/windows/browsing-context-names/browsing-context-default-name-expected.txt:3:
FAIL A browsing context which is opened by window.open() method with '_blank'
parameter has no default name Cannot read property 'name' of undefined
... but this PASSes now, so yay!

https://codereview.chromium.org/1220543007/diff/20001/Tools/Scripts/webkitpy/...
File Tools/Scripts/webkitpy/w3c/test_importer.py (right):

https://codereview.chromium.org/1220543007/diff/20001/Tools/Scripts/webkitpy/...
Tools/Scripts/webkitpy/w3c/test_importer.py:205: DIRS_TO_INCLUDE = ('resources',
'support', 'iframe')
Still hoping the rename PR is accepted. I won't land until I know for sure.

[jsbell, 2015-07-06 19:53:13]

The CQ bit was checked by jsbell@chromium.org

[jsbell, 2015-07-06 19:53:13]

The patchset sent to the CQ was uploaded after l-g-t-m from
michaeln@chromium.org
Link to the patchset: https://codereview.chromium.org/1220543007/#ps60001
(title: "Remove unneeded [Skip] of now-defunct iframe/ dir")

[commit-bot: I haz the power, 2015-07-06 19:53:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1220543007/60001

[commit-bot: I haz the power, 2015-07-06 19:56:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-07-06 19:56:34]

Try jobs failed on following builders:
  android_blink_compile_dbg on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/android_blink_compile_db...)
  android_blink_compile_rel on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/android_blink_compile_re...)
  blink_presubmit on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/3...)
  linux_chromium_gn_rel on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/linux_chromium_gn_rel/bu...)

(exceeded global retry quota)

[jsbell, 2015-07-06 20:11:45]

iframe/ -> resources/ PR was accepted. Landing...

On 2015/06/30 02:10:03, michaeln wrote:
> How much time do these tests have to run and are they doing so in parallel
with
> many other tests? This test will have to exceed 10 MBytes of data before it
> passes. Looks like it's using about 16 bytes per loop. More than half million
> iterations and ipcs and something like 10x thread context switches before it
> gets there. Maybe with contention it takes "too long". If so, much larger keys
> &| values might help.

Filed PR https://github.com/w3c/web-platform-tests/pull/1971 to address this
upstream.

[jsbell, 2015-07-06 20:17:10]

The CQ bit was checked by jsbell@chromium.org

[jsbell, 2015-07-06 20:17:11]

The patchset sent to the CQ was uploaded after l-g-t-m from
michaeln@chromium.org
Link to the patchset: https://codereview.chromium.org/1220543007/#ps80001
(title: "Rebased")

[commit-bot: I haz the power, 2015-07-06 20:17:22]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1220543007/80001

[commit-bot: I haz the power, 2015-07-06 21:30:08]

Committed patchset #5 (id:80001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=198341