Intent to Ship : Content-type in Resource Timing

[Abin Paul]

Contact emails

abin....@gmail.com

Explainer

https://github.com/abinpaul1/resource-timing/blob/explainer-content-type/Explainers/Content-Type.md

Specification

Resource Timing PR : https://github.com/w3c/resource-timing/pull/341

Fetch PR : https://github.com/whatwg/fetch/pull/1481

Summary

Adds a field to PerformanceResourceTiming that holds a string corresponding to the Content-type header of the fetched resource when the resource was fetched.

Blink component

Blink>PerformanceAPIs>ResourceTiming

TAG review

https://github.com/w3ctag/design-reviews/issues/785

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/705)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/88)

Web developers: 

Developer interest for the feature : https://github.com/w3c/resource-timing/issues/203

Other signals:

Ergonomics

No

Activation

No risks

Security

No risks

WebView application risks

Does this intent deprecate or change behaviour of existing APIs, such that it has potentially high risk for Android WebView-based applications? No

Debuggability

The new attribute shows up in Devtools. No implementation changes are required.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/resource-timing/content-type.html?label=master&label=experimental&aligned

https://wpt.fyi/results/resource-timing/content-type-parsing.html?label=master&label=experimental&aligned

Flag name

#enable-experimental-web-platform-features

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1366706

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No

Estimated milestones

Chrome for desktop 115

Chrome for Android 115

Android Webview 115

Anticipated spec changes

No ongoing discussion that could lead to future changes

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5156068351541248

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Dk2uL_gXpZc/m/OhY2ZomeAwAJ

[Yoav Weiss]

Thanks for working on this Abin and for pushing this over the line!! (I'm recusing myself as an API owner, as I was involved in that work)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM2ZH3c1k1fLSb-GmSPEs9MsZDY-O3TaGn9PuvT7DL2NATWFPQ%40mail.gmail.com.

[Mike Taylor]

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUjfO88eOh3k1xdp1dSJKDdx%3DA2-6_qQD1KoowbfkGZmQ%40mail.gmail.com.

[Daniel Bratell]

/LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7dd0e397-123b-57f6-bab6-8df4087529ee%40chromium.org.

[Rick Byers]

Hi Abin (or Yoav?),

What's blocking this spec PR from landing? As discussed here, our standard process is to do what we can to get spec changes fully landed if possible.

Thanks,

   Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9b8cf680-9647-1ca7-a6fe-d034e737e9da%40gmail.com.

[Yoav Weiss]

On Wed, Apr 19, 2023 at 6:03 PM Rick Byers <rby...@chromium.org> wrote:

Hi Abin (or Yoav?),

What's blocking this spec PR from landing?

Nothing is blocking AFAICT. Just a matter of someone with permissions clicking the button.

  

As discussed here, our standard process is to do what we can to get spec changes fully landed if possible.

I think this can wait a few days until the button-clicking happens.

[Yoav Weiss]

Update: +Anne van Kesteren has been working on a new MimeSniff spec concept that will enable this feature to only expose supported mime types, rather than any arbitrary one. (to prevent a threat model Apple folks are concerned with, without harming the use-cases the feature is tackling)

We'd need to modify the spec PR and implementation to rely on that concept.

[Mike Taylor]

I see that both the Resource Timing and Fetch PRs have landed - does that mean this I2S is unblocked now (and just needs an LGTM3)?

[Yoav Weiss]

On Mon, May 15, 2023 at 4:43 PM Mike Taylor <mike...@chromium.org> wrote:

I see that both the Resource Timing and Fetch PRs have landed - does that mean this I2S is unblocked now (and just needs an LGTM3)?

I believe so.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6388a806-7b9e-c8c1-6b52-f84e7b473558%40chromium.org.

[Rick Byers]

Thanks, LGTM3

[Barry Pollard]

I've just discovered this was never shipped by default. I can't see a reason why and speaking to Yoav who was involved at the time, and digging through the CLs and bugs I think this was simply an oversight. The work is done, so I'd like to enable this by default. I don't think the original owner (Abin) is still involved (feel free to tell me if that's not the case, or if you remember any more background here Abin!), but I'm happy to do the small amount of work to see this through.

The bug (https://issues.chromium.org/issues/40239837) shows some complication with landing it due to test failures and it was reverted several times, but eventually landed (behind a flag) over two years ago. Perhaps this explains the confusion in ensuring it eventually landed by default? It has been running on our non-stable channels ever since.

We had API owner approval back then, and Firefox have also shipped this API in the meantime. However, it's been nearly three years since this was approved, so it would be good to get API approvals again. I can't seem to reset it in chromestatus but will hold off until I get confirmation here.

Let me know if you have any questions (or if any of you have any more relevant background here?).

Thanks,

Barry

[Rick Byers]

Thanks Barry. This seems small and non-controversial, you can consider previous API owners LGTM3 to still apply. Let us know if you think there are new material tradeoffs we should weigh in on, but otherwise I see no need for you to block on getting further API owner approval.

Rick

[Mike Taylor]

I don't think you need re-approvals - thanks for catching this and good luck with the rollout. But please come back and report if you run into any issues that xrequire you to back it out/pause the launch.