review some initial tests for resource timing

[siusin]

review tests from pull request #402

• RT Level 1 indicated that aborted requests or requests that don't return a response may be included as PerformanceResourceTiming objects in the Performance Timeline of the relevant context, but later versions would like to included these aborted requests in the Perf Timeline.

[wpt-pr-bot]

Notifying @haoxli, @igrigorik, @plehegar, @toddreifsteck, @yoavweiss, and @zqzhang. (Learn how reviewing works.)

[igrigorik]

Nitpick: drop "all of the"? I don't think we want to enumerate all of the element types here, and implying all and testing a subset is slightly confusing.

[siusin]

done!

[igrigorik]

Might be worth adding a comment above, explaining that we're counting on second request of same resource to reuse the socket..

[siusin]

Yeah. Please look at commit #b1bbb10

[igrigorik]

RT Level 1 indicated that aborted requests or requests that don't return a response may be included as PerformanceResourceTiming objects in the Performance Timeline of the relevant context, but later versions would like to included these aborted requests in the Perf Timeline.

Yikes, looks like we introduced some confusion here.

• RT L1 (section 4.2) states: "Aborted requests or requests that don't return a response may be included as PerformanceResourceTiming objects in the Performance Timeline of the relevant context."
• RT L2 changes via Clarify presence of requests that don't return a response w3c/resource-timing#12:
  1. w3c/resource-timing@0eb0f69 landed an update stating that aborted requests MUST be included, but it didn't update the processing section..
  2. After that was landed we re-opened discussion once more, concluded that it is (in fact) the correct behavior, and Wes started working on updating the processing section.
  3. At TPAC we concluded that we'll push Wes's update to L3, but we never backed out (i).

The end result, as of right now, is that L2 states that failed resources MUST be surfaced, but doesn't have the processing section updated.

---

1. I think "MAY" for L1 is correct, and we shouldn't change that -- some browsers surface such requests, and that's good.
2. We need to revisit how we want to treat this in L2:
   1. We can carry over MAY from L1, back out w3c/resource-timing@0eb0f69, and target that + processing update to L3.
   2. We can revisit our earlier decision to push MUST to L3...

I believe the reason we went with (i) at TPAC is that it would make existing L2 implementations (e.g. IE, which is not going to change?) incompatible... Which hints that we should stick with that.

@toddreifsteck @plehegar wdyt?

[plehegar]

For L2, I'd rather use (i) since doing (ii) would probably require hooking ourselves into Fetch, which is for L3.

[toddreifsteck]

I agree that we should go with (i) for L2 and push any further specification to L3.

[siusin]

Shall we drop the test case for L1 (resource_ignore_failures_level1.html) in that case? I'm not sure if a test case for a "MAY" will make sense, knowing that it produces different test results among the major browsers.

[plehegar]

@siusin imho, we should drop it. Until we better define what it means in L3, it might be harmful to have a test related to resource failures in the test suite.

[igrigorik]

+1 to removing those tests. Also, opened w3c/resource-timing#85 for spec update, ptal.

@siusin other then removing the test, everything else looks good to me!

[siusin]

Ok, thanks!

[plehegar]

LGTM