Update core dependencies

[typescript-bot]

Automated changes by create-pull-request GitHub action

[github-actions]

Thanks for the PR!

This section of the codebase is owned by @saschanaz - if they write a comment saying "LGTM" then it will be merged.

[saschanaz]

mdn/browser-compat-data#25733 🤔

[HolgerJeromin]

Full Safari and firefox support is there.
https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/responseStart#browser_compatibility

[saschanaz]

MDN hasn't been updated yet, but I don't think the BCD PR is right.

[tunetheweb]

I don't understand why we're deleting this? responseStart has been supported for a long time. It's just what "responseStart" mean changed slightly in Chrome 115, and has been changed back since Chrome 133. See: https://chromestatus.com/feature/5158830722514944. That's why we updated BCD to make a noted of that.

But in terms of typescript, reponseStart was always present and was always a DOMHighResTimeStamp. So that note shouldn't change anything in typescript.

[tunetheweb]

Add back incorrectly removed responseStart

Suggested change

	readonly responseEnd: DOMHighResTimeStamp;
	readonly responseEnd: DOMHighResTimeStamp;
	/** [MDN Reference](https://developer.mozilla.org/docs/Web/API/PerformanceResourceTiming/responseStart) */
	readonly responseStart: DOMHighResTimeStamp;

[tunetheweb]

Add back incorrectly removed responseStart

Suggested change

	readonly responseEnd: DOMHighResTimeStamp;
	readonly responseEnd: DOMHighResTimeStamp;
	/** [MDN Reference](https://developer.mozilla.org/docs/Web/API/PerformanceResourceTiming/responseStart) */
	readonly responseStart: DOMHighResTimeStamp;

[tunetheweb]

Add back incorrectly removed responseStart

Suggested change

	readonly responseEnd: DOMHighResTimeStamp;
	readonly responseEnd: DOMHighResTimeStamp;
	/** [MDN Reference](https://developer.mozilla.org/docs/Web/API/PerformanceResourceTiming/responseStart) */
	readonly responseStart: DOMHighResTimeStamp;

[tunetheweb]

Add back incorrectly removed responseStart

Suggested change

	readonly responseEnd: DOMHighResTimeStamp;
	readonly responseEnd: DOMHighResTimeStamp;
	/** [MDN Reference](https://developer.mozilla.org/docs/Web/API/PerformanceResourceTiming/responseStart) */
	readonly responseStart: DOMHighResTimeStamp;

[tunetheweb]

Add back incorrectly removed responseStart

Suggested change

	readonly responseEnd: DOMHighResTimeStamp;
	readonly responseEnd: DOMHighResTimeStamp;
	/** [MDN Reference](https://developer.mozilla.org/docs/Web/API/PerformanceResourceTiming/responseStart) */
	readonly responseStart: DOMHighResTimeStamp;

[tunetheweb]

Add back incorrectly removed responseStart:

Suggested change

	readonly responseEnd: DOMHighResTimeStamp;
	readonly responseEnd: DOMHighResTimeStamp;
	/** [MDN Reference](https://developer.mozilla.org/docs/Web/API/PerformanceResourceTiming/responseStart) */
	readonly responseStart: DOMHighResTimeStamp;

[saschanaz]

This is because now surprisingly there are two sources of truth in BCD for responseStart. I strongly believe BCD should remove that, but until then we have a way to override BCD data.

[tunetheweb]

This is because now surprisingly there are two sources of truth in BCD for responseStart. I strongly believe BCD should remove that, but until then we have a way to override BCD data.

Can you explain what you mean by that? I did the BCD updates so can see if there's a better way to do this (I'm not totally happy how it shows on MDN either).

But, as per, #1891 (comment) the point was to note that Chrome diverged from the definition for a short period and this might surprise some developers—hence why we wanted it documented in MDN/BCD.

[tunetheweb]

Reverting the problematic updates in BCD here: #25876

[saschanaz]

This is because now surprisingly there are two sources of truth in BCD for responseStart. I strongly believe BCD should remove that, but until then we have a way to override BCD data.

Can you explain what you mean by that? I did the BCD updates so can see if there's a better way to do this (I'm not totally happy how it shows on MDN either).

Here the two sources means the support data with alternative_name from the finalResponseHeadersStart and the data from the responseStart.

• We have to consider both data because alternative_name is often about things that are still supported by browsers.
• alternative_name had always been the sole source for the name before the responseStart change.
• After the change, we have data from two sources saying removal and addition, and the code is not ready for that

We can somehow deal with it by merging support data (we have that for mixins), but I don't think that's worth given responseStart is the only source of conflict we had for years.

[tunetheweb]

Looks like the responseStart deletions have been removed with that latest update from BCD.