Closed Bug 1665102 Opened 4 years ago Closed 2 years ago

Web-Platform-Tests: resource-timing nextHopProtocol-tao-protected.https.html failure

Categories

(Core :: Performance, defect)

78 Branch
defect

Tracking

()

RESOLVED INVALID
Performance Impact none

People

(Reporter: nic, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36

Steps to reproduce:

From a triage[1] of currently failing WPT resource-timing tests[2], the following Firefox test failures may (or may not be) be related to TAO:

https://wpt.fyi/results/resource-timing/nextHopProtocol-tao-protected.https.html?label=master&label=experimental&aligned

[1] https://github.com/w3c/resource-timing/issues/233
[2] https://wpt.fyi/results/resource-timing?label=master&label=experimental&aligned

Actual results:

Test failure

Expected results:

Test pass

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Performance
Product: Firefox → Core
Flags: needinfo?(sefeng)
Whiteboard: [qf-]

This test doesn't exist anymore.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(sefeng)
Resolution: --- → INVALID

Re-opening per the comment above

Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Thanks!

Flags: needinfo?(sefeng)

Howdy!

Just a heads-up from your friendly neighbourhood Chromies: https://github.com/web-platform-tests/wpt/pull/32241 is a thing.

It's part of a Chrome change where we want to remove a special case for deciding when to expose nextHopProtocol. Previously, if the resource wasn't for a "document destination" (iframes and the like), we'd expose cross-origin nextHopProtocol attributes regardless of how the Timing-Allow-Origin check went. Probably not what we want :)

The details are in the Fetch spec1, but the old special case does not conform to the spec. Not sure exactly when/how it changed in the spec but not having a special case was an intentional goal here.

Changing this behaviour does affect what scripts will see in the wild, though, so I wanted to signal-boost this and see if there are any concerns from the FF side. Since this is a bug fix to align with the spec, we figured the whole intent-to-ship process wouldn't strictly be needed but we'd love to hear any feedback! I'll cc myself to this bug but also feel free to jump in on the Chrome Platform Status entry2.

Cheers,

  • Tom

Here's a small test to see whether cross-origin nextHopProtcol attributes are exposed regardless of TAO.

Right now, FF, Chrome and WebKit all expose the attribute but we shouldn't :(

<!doctype html>
<html>
<head>
</head>
<body>
<div>
  Without a Timing-Allow-Origin header, we expect the empty string. We got '<span id="nhp">pending</span>'
  <p>
  Timing-Allow-Origin: <span id="tao">pending</span>
</div>
<script>
const cross_origin_url = "https://example.com/";
new PerformanceObserver(entryList => {
  entryList.getEntries().forEach(entry => {
    if (entry.name == cross_origin_url) {
      nhp.textContent = entry.nextHopProtocol;
    }
    console.log(`entry.name: ${entry.name}`);
  })
}).observe({"type": "resource", "buffered": true});

// Get a cross-origin resource
fetch(cross_origin_url, {"mode": "no-cors"}).then(r => {
  let header_value = r.headers.get("Timing-Allow-Origin");
  if (header_value == null) {
    header_value = "--not set--";
  } else {
    header_value = "'" + header_value + "'";
  }
  tao.textContent = header_value;
}).catch(e => {
  console.log("fetch failed:", e);
});

</script>
</body>
</html>
Performance Impact: --- → -
Whiteboard: [qf-]

This test is now passing with the fix in bug 1768583.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago2 years ago
Flags: needinfo?(sefeng)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.