Resource Timing + beacon test

toddreifsteck commented 6 years ago

http://w3c-test.org/beacon/headers/header-content-type.html

In 'Test content-type header for a body string', the test seems to require that the performance entry for sendBeacon is NOT exposed to the performance timeline when the sendBeacon call is made.

In Microsoft Edge, the operation is so fast that (or the costs of completing the sendBeacon call is so slow) that the entry IS exposed to the timeline.

The test should be updated to remove the line I've commented below:

function testContentTypeHeader(what, contentType, title) {
  function wait(ms) {
    return new Promise(resolve => step_timeout(resolve, ms));
  }
  promise_test(async t => {
    const id = self.token();
    const testUrl = new Request(RESOURCES_DIR + "content-type.py?cmd=put&id=" + id).url;
    assert_true(navigator.sendBeacon(testUrl, what), "SendBeacon Succeeded");
    assert_equals(performance.getEntriesByName(testUrl).length, 0); //REMOVE

igrigorik commented 6 years ago

Hmm, if I'm reading the test correctly..

  promise_test(async t => {
    const id = self.token();
    const testUrl = new Request(RESOURCES_DIR + "content-type.py?cmd=put&id=" + id).url;
    assert_true(navigator.sendBeacon(testUrl, what), "SendBeacon Succeeded");
    assert_equals(performance.getEntriesByName(testUrl).length, 0);
    do {
      await wait(50);
    } while (performance.getEntriesByName(testUrl).length === 0);
    assert_equals(performance.getEntriesByName(testUrl).length, 1);

I don't believe the intent is to check that the entry is not added to performance timeline. Rather, it looks like it's checking that the entry doesn't exist but is then added to the timeline. Except, the "not here" check is done after sendBeacon, which is kinda odd.

The fix here should be to move the line above sendBeacon call, not remove it?

toddreifsteck commented 6 years ago

Sure, that would be a fair fix.

w3c / beacon

Resource Timing + beacon test #58