third_party/WebKit/LayoutTests/http/tests/origin_trials/webexposed/budget-origin-trial-interfaces-in-service-worker.html - Issue 2812223004: Adding an origin trial for Budget API

Side by Side Diff: third_party/WebKit/LayoutTests/http/tests/origin_trials/webexposed/budget-origin-trial-interfaces-in-service-worker.html

Issue 2812223004: Adding an origin trial for Budget API (Closed)

Patch Set: Fix expected output for virtual LayoutTests Created 3 years, 8 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

« no previous file with comments | « third_party/WebKit/LayoutTests/http/tests/origin_trials/webexposed/budget-origin-trial-interfaces.html ('k') | third_party/WebKit/LayoutTests/virtual/origin-trials-runtimeflags-disabled/http/tests/origin_trials/webexposed/budget-origin-trial-interfaces-expected.txt » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 <!DOCTYPE html>

	2 <html>

	3 <head>

	4 <!-- Generate token with the command:

	5 generate_token.py http://127.0.0.1:8000 BudgetQuery --expire-timestamp=2000 000000

	6 -- -->

	7 <meta http-equiv="origin-trial" content="AgFtR2Ps1Z9M/FW14Tgcwbajvq7kvzc/b1 SPPSaaucG/P4ba6xC/69I9v8Pqx4wbsJINoqMabs9GE/LxOnPRfQIAAABTeyJvcmlnaW4iOiAiaHR0cD ovLzEyNy4wLjAuMTo4MDAwIiwgImZlYXR1cmUiOiAiQnVkZ2V0UXVlcnkiLCAiZXhwaXJ5IjogMjAwMD AwMDAwMH0" />
	Peter Beverloo 2017/04/24 14:24:01 Ian, how does this work? The Service Worker will b Ian, how does this work? The Service Worker will be started as its own context, but more importantly, can be started without the document existing at all. a) Are we satisfied with the test coverage for this vs. the equivalent HTTP header? b) Do enabled origin trials always propagate to workers(/contexts) started from a hosting document? How would that work if two documents, one with the OT and one without, both "start" the same shared/service worker? iclelland 2017/04/24 14:45:33 If this test is passing, and it appears that the t Show quoted text On 2017/04/24 14:24:01, Peter Beverloo wrote: > Ian, how does this work? The Service Worker will be started as its own context, > but more importantly, can be started without the document existing at all. > > a) Are we satisfied with the test coverage for this vs. the equivalent HTTP > header? If this test is passing, and it appears that the trial is enabled when it should not be, I would suggest that we shouldn't be satisfied with the test coverage :) The tests in LayoutTests/http/tests/origin_trials will always see the budget feature available, because the runtime flag for experimental features is turned on, I believe. The tests there are useful for ensuring that the properties are bound correctly, because Chrome still uses the origin trials mechanism to attach them to the JS objects. Tests in LayoutTests/virtual/origin-trials-runtimeflags-disabled/ run with the runtime flag disabled, but you should still be able to turn the feature on with a trial token. The service worker tests should pass in this directory if we add the token as an HTTP header (see https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/http/test... as an example) Show quoted text > b) Do enabled origin trials always propagate to workers(/contexts) started > from a hosting document? Origin trials propagate to dedicated worker threads from the document which creates them, but not to shared workers or service workers. Those need to have the trial enabled by an HTTP header (we could probably add a JS interface, but have not done that yet for worker scripts). The token is cached with the service worker version, so that if the service worker is restarted without a network request, the token will still be enabled. Show quoted text > > How would that work if two documents, one with the OT and one without, both > "start" the same shared/service worker? In both cases, the presence of the token in the HTTP response which delivers the worker script will determine whether the trial is enabled in that context.
	8 <title>Budget interfaces available in a Service Worker</title>

	9 <script src="../../resources/testharness.js"></script>

	10 <script src="../../resources/testharnessreport.js"></script>

	11 <script src="../../serviceworker/resources/test-helpers.js"></script>

	12 <script src="../../notifications/resources/test-helpers.js"></script>

	13 </head>

	14 <body>

	15 <script>

	16 promise_test(function(test) {

	17 const script = '../../budget/resources/instrumentation-service-worker.js ';

	18 const scope = '../../budget/resources/scope/' + location.pathname;

	19 let port;
	Peter Beverloo 2017/04/24 14:24:01 nit: \|port\| can be local to the function on line 2 nit: \|port\| can be local to the function on line 22.
	20

	21 return getActiveServiceWorkerWithMessagePort(test, script, scope)

	22 .then(function(workerInfo) {

	23 port = workerInfo.port;

	24

	25 port.addEventListener('message', function(event) {

	26 if (typeof event.data != 'object' \|\| !event.data.command)

	27 assert_unreached('Invalid message from the service worker');

	28

	29 assert_equals(event.data.command, 'checkInterfaces');

	30 assert_true(event.data.success,

	31 'checkInterfaces should succeed but failed with error: ' +

	32 event.data.message);

	33 });

	34

	35 return sendCommand(port, { command: 'checkInterfaces' });
	Peter Beverloo 2017/04/24 14:24:01 Are we sure that the event listener on line 25 is Are we sure that the event listener on line 25 is being executed before the returned promise resolves? Since the sendCommand() function resolves the promise with the event's data, we can do something like this: return sendCommand(..) .then(data => { assert_equals(...); });
	36 })

	37 }, 'BudgetQuery interfaces should be available in a Service Worker.');

	38 </script>

	39 </body>

	40 </html>

OLD	NEW