Test [[CanBlock]] in various agents

[domenic]

Follows whatwg/html#2521. This downgrades the resources submodule due to #5568 which prevents these tests (and many, many other tests in WPT) from working.

FYI @binji @mtrofin on the Blink side, @lars-t-hansen on the Gecko side. Failures:

• Chrome allows atomics in service workers, against the emerging spec. This is not likely to change.
  • Filed https://bugs.chromium.org/p/chromium/issues/detail?id=711809
• Firefox throws the wrong error type in windows and service workers
  • Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1356697
• Firefox disallows atomics in shared workers, against the emerging spec. This is still under some minor discussion in the PR.
• Safari passes the applicable two tests (window and dedicated workers)

Worklets are not tested at this time due to spec uncertainty.

---

This change is 

[wpt-pr-bot]

Notifying @jdm, @jgraham, @zcorpan, and @zqzhang. (Learn how reviewing works.)

[w3c-bots]

View the complete job log.

Lint

Passed

[w3c-bots]

View the complete job log.

Firefox (nightly channel)

Testing web-platform-tests at revision c83536c
Using browser at version BuildID 20170425101537; SourceStamp a30dc237c3a600a5231f2974fc2b85dfb5513414
Starting 10 test iterations
All results were stable

All results

4 tests ran

/html/webappapis/scripting/processing-model-2/integration-with-the-javascript-agent-formalism/canblock-dedicatedworker.html

Subtest	Results	Messages
	OK
[[CanBlock]] in a DedicatedWorkerGlobalScope	PASS	{}

/html/webappapis/scripting/processing-model-2/integration-with-the-javascript-agent-formalism/canblock-serviceworker.https.html

Subtest	Results	Messages
	OK
Service worker test setup	PASS
[[CanBlock]] in a ServiceWorkerGlobalScope	PASS	{}

/html/webappapis/scripting/processing-model-2/integration-with-the-javascript-agent-formalism/canblock-sharedworker.html

Subtest	Results	Messages
	OK
[[CanBlock]] in a SharedWorkerGlobalScope	FAIL	waiting is not allowed on this thread

/html/webappapis/scripting/processing-model-2/integration-with-the-javascript-agent-formalism/canblock-window.html

Subtest	Results	Messages
	OK
[[CanBlock]] in a similar-origin window agent	PASS

[w3c-bots]

View the complete job log.

Chrome (unstable channel)

Testing web-platform-tests at revision c83536c
Using browser at version 59.0.3071.25 dev
Starting 10 test iterations
All results were stable

All results

4 tests ran

/html/webappapis/scripting/processing-model-2/integration-with-the-javascript-agent-formalism/canblock-dedicatedworker.html

Subtest	Results	Messages
	OK
[[CanBlock]] in a DedicatedWorkerGlobalScope	FAIL	SharedArrayBuffer is not defined

/html/webappapis/scripting/processing-model-2/integration-with-the-javascript-agent-formalism/canblock-serviceworker.https.html

Subtest	Results	Messages
	OK
Service worker test setup	PASS
[[CanBlock]] in a ServiceWorkerGlobalScope	FAIL	SharedArrayBuffer is not defined

/html/webappapis/scripting/processing-model-2/integration-with-the-javascript-agent-formalism/canblock-sharedworker.html

Subtest	Results	Messages
	OK
[[CanBlock]] in a SharedWorkerGlobalScope	FAIL	SharedArrayBuffer is not defined

/html/webappapis/scripting/processing-model-2/integration-with-the-javascript-agent-formalism/canblock-window.html

Subtest	Results	Messages
	OK
[[CanBlock]] in a similar-origin window agent	FAIL	Uncaught ReferenceError: SharedArrayBuffer is not defined

[annevk]

This looks okay in general, but I wish we could annotate these tests somehow for removal if we ever get proper test262 integration going.

Also, should the .js resources be in a resources directory? It's never clear to me what the convention is there, if anything.

[annevk]

Can we assert the return value to be "ok"?

[domenic]

@binji @lars-t-hansen can you help get this test passing? It seems that in a dedicated worker, in both Chrome and Firefox, the following code gives "timed-out" instead of "ok":

"use strict";
importScripts("/resources/testharness.js");

test(() => {
  const sab = new SharedArrayBuffer(16);
  const ta = new Int32Array(sab);

  assert_equals(Atomics.wait(ta, 0, 0, 10), "ok");
}, `[[CanBlock]] in a ${self.constructor.name}`);

done();

Presumably this is me not understanding something about SABs/Atomics.wait.

However this test passes in Chrome in shared workers, somehow.

[syg]

@domenic Atomics.wait would return "ok" if it's explicitly woken by Atomics.wake. Is there something that's waking it?

[domenic]

Oh, I thought it would return "ok" if the value successfully became the target value (which it already is). So "timed-out" is correct? Any suggestions for a better test?

Is it a Chrome bug that it returns "ok" in shared workers?

[syg]

@domenic "timed-out" is fine here, I think, if the point is that it doesn't throw. BTW if the TA value isn't equal to the supplied value, you get "not-equal".

[binji]

Hm, I'm not sure why this test would return "ok" in any context, it should either timeout or throw, as syg mentioned.

[lars-t-hansen]

What @syg said. Additionally, observe that [[CanBlock]] is tested early so (a) a timeout of 0 is fine here, and you should still get "timed-out"; or (b) leaving off the timeout while first setting ta[0]=1 so that you get "not-equal" is also a valid test of [[CanBlock]].

[domenic]

Thanks for the help all. I just updated the test to require "timed-out". Chrome seems to be passing now; I'm not sure what was going on there locally, but maybe I had an old version of the test open or something and was being caught out by shared workers being... shared... between tabs.

[annevk]

Since service workers require HTTPS I renamed the resource to include .https. I believe that's the correct thing to do.

[annevk]

I had to force push because I had to rebase to get past the failing Chrome bot that was disabled by a newer commit. I'll let someone else double check before landing.

See whatwg/html#2521 (comment) for the browser bug analysis. Led to one bug against Firefox.