Hi Wonik, I'd like to understand the compat and interop risks a little better here. The change is to Chromium's implementation of https://mimesniff.spec.whatwg.org/#xml-mime-type, and in specs that affects a lot more than resource timing.
*Compat risk* Starting from https://dontcallmedom.github.io/webdex/x.html#XML%20MIME%20type%40%40mimesniff%25%25dfn, I found these places: - https://html.spec.whatwg.org/#the-object-element, where it seems we might treat more responses as XML and render them instead of treating as unsupported - https://html.spec.whatwg.org/#loading-a-document, which presumably affects navigation directly to such resources - https://xhr.spec.whatwg.org/#document-response, which I think will cause more responses to be parsed as XML - https://xhr.spec.whatwg.org/#text-response, seems to only affect how encoding is detected (less likely to break things badly) Will all of these also change in Chromium, or are they all part of the MIMETypeRegistry::IsXMLMIMEType unification? *Interop risk* Can you test what Gecko and WebKit do for the above cases connected to the same definition? You mentioned Gecko's XHR implementation and WebKit's XML MIME classification code, but which of the cases in the spec does this map to? To ensure all engines align on a change that won't break existing content, having test cases and their results across all the engines in their stable configuration would be very helpful. As it is, I can't judge if Firefox+Safari already completely match the spec and Chrome is the outlier, or if it's more complicated. Best regards, Philip On Wed, Oct 7, 2026 at 4:30 PM Mike Taylor <[email protected]> wrote: > \On 10/7/26 12:38 a.m., Wonik Choi wrote: > > Hi Mike, > > I’ve documented the Actor interaction in this bug comment #12 > <https://issues.chromium.org/u/1/issues/362282752#comment12>. Could you > point me to the appropriate Actor owner to review this? I’d also like to > confirm whether the existing security review covered these behavior changes. > > > https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/actor/OWNERS > has > a list of folks who can review. > > Thanks > > > 2026년 10월 6일 화요일 오후 7시 1분 28초 UTC+9에 [email protected]님이 작성: > >> On 10/5/26 11:24 p.m., Chromestatus wrote: >> >> *Contact emails* >> [email protected] >> >> *Specification* >> https://mimesniff.spec.whatwg.org/#xml-mime-type >> >> *Summary* >> Chrome is updating how it Detects XML MIME types to fully align with Web >> standards. Chrome will now recognize valid MIME types whose subtype ends in >> `+xml` as XML across Chrome and Android WebView, including non-application >> types such as `text/example+xml` and `image/example+xml`. For these >> responses, `PerformanceResourceTiming.contentType` returns application/xml. >> The value for image/svg+xml remains unchanged. Enterprise web applications >> that rely on previous `contentType` values may observe behavior changes. >> Chrome Actor also uses this shared XML classification for dangerous MIME >> type navigation checks, so it may block navigations to additional >> non-application +xml responses. IT admins should check whether their >> applications depend on these MIME types or the previous `contentType` >> values. >> >> *Blink component* >> Blink>Network >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%22> >> >> *Web Feature ID* >> *No information provided* >> >> *Motivation* >> Chromium currently applies generic +xml suffix matching only to >> application/* MIME types, although the WHATWG MIME Sniffing Standard >> defines any valid MIME type whose subtype ends in +xml as an XML MIME type. >> As a result, non-application types such as text/example+xml are not >> minimized to application/xml in PerformanceResourceTiming.contentType. This >> change aligns Chromium's classification with the existing standard and >> improves interoperability. Implementation (merged behind an experimental >> feature): >> https://chromium-review.googlesource.com/c/chromium/src/+/8301932 >> >> *Initial public proposal* >> *No information provided* >> >> *TAG review* >> Requesting a TAG review exception for this small conformance change to >> the existing WHATWG MIME Sniffing Standard. The change broadens XML MIME >> type suffix matching to include non-application types. No new API surface >> or API design is introduced. >> >> *TAG review status* >> Not applicable >> >> *Goals for experimentation* >> None >> >> *Risks* >> >> >> *Interoperability and Compatibility* >> This change aligns XML MIME type classification with the existing WHATWG >> MIME Sniffing Standard. The web-visible change is that >> PerformanceResourceTiming.contentType returns "application/xml" for >> additional non-application MIME types whose subtype ends in "+xml". Code >> that depends on the previous contentType value may observe a different >> result. The special handling of "image/svg+xml" is preserved. The change is >> controlled by SpecCompliantXmlMimeTypes, allowing the previous behavior to >> be restored by disabling the feature. >> >> From what I can tell this change is just scoped to resource timing, so >> only a handful of RUM providers would be affected (in the hypothetical >> that some script is expecting "application/atom+xml" via >> PerformanceResourceTiming.contentType but now seeing "application/xml" and >> exploding). Is there some issue where RUM providers are asking for this / >> might find out about the change? >> >> Even so, I'd love to better understand the compat risk of this proposed >> change. Above it mentions "Enterprise web applications that rely on >> previous `contentType` values may observe behavior changes" - do we think >> enterprises are more likely to be affected by this change? Are we able to >> estimate or reason about breakage for non-enterprise use cases? e.g., some >> site is expecting "application/atom+xml" via >> PerformanceResourceTiming.contentType but now seeing "application/xml" >> going to break something (that sounds far-fetched, I dunno)? >> >> As an aside, >> https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/actor/execution_engine.cc;l=288-299 >> should probably be looked at by the security reviewer/other owners for this >> change. "image/svg+xml" will start to return true here with this change, >> when it return false before, if I'm reading the code correctly. >> >> I see in your CL >> <https://chromium-review.git.corp.google.com/c/chromium/src/+/8301932/comments/dabacf37_52e1d902> >> you wrote "MIMETypeRegistry::IsXMLMIMEType unification is intentionally >> left as follow-up" - can you explain your plan there? That seems like a >> riskier change to me, since it will affect navigation & loading. >> >> >> *Gecko*: No signal Firefox recognizes non-application "+xml" MIME types >> in its XHR implementation, but the Resource Timing minimization behavior >> differs. In the WPT PR #62420 run dated 2026-09-04, Firefox Nightly 157.0a1 >> failed all five added XML cases. For example, contentType returned >> "text/example+xml" instead of "application/xml". Results: >> https://wpt.fyi/results/resource-timing/content-type-minimization.html?run_id=6323630396145664 >> No formal standards position has been requested. An exception is requested >> for this small conformance change, subject to API owner review. >> >> We should probably request a formal position at >> https://github.com/mozilla/standards-positions, because the ideal >> outcome is all browsers are doing the same thing rather than diverging in >> subtle ways. >> >> >> *WebKit*: No signal WebKit recognizes non-application "+xml" MIME types >> in its XML MIME classification code. This does not establish support for >> PerformanceResourceTiming.contentType. In the WPT PR #62420 run dated >> 2026-09-04, Safari Technology Preview 251 failed all five added XML cases >> because contentType was undefined. Results: >> https://wpt.fyi/results/resource-timing/content-type-minimization.html?run_id=5125540410556416 >> No formal standards position has been requested. An exception is requested >> for this small conformance change, subject to API owner review. >> >> Ditto here - https://github.com/WebKit/standards-positions please. >> >> >> *Web developers*: No signals >> >> *Other signals*: >> >> *Ergonomics* >> No new API or calling convention is introduced. Developers continue to >> read PerformanceResourceTiming.contentType through the existing Resource >> Timing API. >> >> *Activation* >> No developer opt-in is required. Applications that rely on the previous >> contentType value for non-application "+xml" responses may need to adjust >> their expectations. >> >> *Security* >> The change broadens the MIME types classified as XML by >> blink::IsXMLMimeType. It does not change the existing response-access >> checks that govern exposure of PerformanceResourceTiming.contentType. The >> shared helper is also used by Chrome Actor's dangerous-MIME-type navigation >> checks. When those checks and SpecCompliantXmlMimeTypes are enabled, >> additional non-application "+xml" types may be blocked. >> >> *WebView application risks* >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> Applications that inspect PerformanceResourceTiming.contentType may >> observe "application/xml" for additional non-application "+xml" MIME types. >> Applications that depend on the previous value may behave differently. The >> change is guarded by SpecCompliantXmlMimeTypes, which provides a way to >> restore the previous behavior. >> >> >> *Debuggability* >> 1. Basic support Manually checked on macOS using Content Shell with >> --enable-features=SpecCompliantXmlMimeTypes and DevTools attached to the >> test page. Console evaluation and autocomplete worked during the check. >> Chrome DevTools for agents was not separately tested. 2. Inspectability A >> local server returned Content-Type: text/example+xml. The response was >> fetched and its PerformanceResourceTiming entry was obtained through >> PerformanceObserver. Reading entry.contentType in the DevTools Console >> returned "application/xml" as expected. Autocomplete for contentType was >> also verified. The server's original Content-Type header and the minimized >> Resource Timing value are distinct. 3. Extended support No dedicated >> DevTools workflow is proposed. The changed value can be inspected through >> existing Console functionality. 4. Automated testing Yes. The existing WPT >> resource-timing/content-type-minimization.html exercises the added >> non-application "+xml" cases. Implementation: >> https://chromium-review.googlesource.com/c/chromium/src/+/8301932 WPT >> export: https://github.com/web-platform-tests/wpt/pull/62420 >> >> *Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)?* >> Yes >> The change uses shared Chromium MIME classification code with no >> platform-specific restrictions. Support is intended for Windows, macOS, >> Linux, ChromeOS, Android, and Android WebView. >> >> *Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> Yes >> The implementation adds test cases to: >> mimesniff/mime-types/resources/mime-types-minimized.json These cases are >> exercised by: resource-timing/content-type-minimization.html Coverage >> includes text/example+xml, image/example+xml, font/example+xml, uppercase >> MIME types, and MIME parameters. Parameterized C++ unit tests cover both >> enabled and disabled feature states, existing XML MIME types, additional >> "+xml" types, and invalid MIME inputs. Implementation and tests: >> https://chromium-review.googlesource.com/c/chromium/src/+/8301932 WPT >> export: https://github.com/web-platform-tests/wpt/pull/62420 The WPT >> additions were merged upstream on September 30, 2026: >> https://github.com/web-platform-tests/wpt/pull/62420 PR-level browser >> results are available, including the five added XML cases: >> https://wpt.fyi/results/resource-timing/content-type-minimization.html?run_id=6323630396145664&run_id=5125540410556416 >> >> *Flag name on about://flags* >> enable-experimental-web-platform-features >> >> *Finch feature name* >> SpecCompliantXmlMimeTypes >> >> *Rollout plan* >> Will ship enabled for all users >> >> *Requires code in //chrome?* >> False >> >> *Tracking bug* >> https://issues.chromium.org/issues/362282752 >> >> *Measurement* >> No dedicated UseCounter is added by this change. The occurrence of >> affected non-application "+xml" MIME types is not separately measured by >> this implementation. >> >> *Availability expectation* >> Expected to be available by default on Blink platforms after launch >> approval and default enablement of SpecCompliantXmlMimeTypes. >> >> *Adoption expectation* >> Existing users of PerformanceResourceTiming.contentType will receive >> spec-compliant values for additional XML MIME types without changing their >> API usage. No quantitative adoption estimate is available. >> >> *Adoption plan* >> Communicate the behavior change through the Blink intent process and >> track any necessary documentation and browser compatibility updates. >> >> *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? >> None. The implementation uses Chromium code and its existing open-source >> dependencies. >> >> *Estimated milestones* >> Shipping on desktop 158 >> Shipping on Android 158 >> Shipping on WebView 158 >> >> *Anticipated spec changes* >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> None anticipated. This change implements the existing XML MIME type >> definition and MIME type minimization rules in the WHATWG MIME Sniffing >> Standard. >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/5092584283308032?gate=6712519581368320 >> >> *Links to previous Intent discussions* >> Intent to Prototype: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a922400.e8a51b51.6abb3.033c.GAE%40google.com >> >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com>. >> >> -- >> 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 [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ac46a00.082f26cb.22c2b.02d5.GAE%40google.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ac46a00.082f26cb.22c2b.02d5.GAE%40google.com?utm_medium=email&utm_source=footer> >> . >> >> -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2c8015ee-38c6-4ccf-ad3b-8213cef63aba%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2c8015ee-38c6-4ccf-ad3b-8213cef63aba%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcFsdTD6M3%3Df8xaROb8MfK8xcXjRcDDxNM16QRzPWwcMA%40mail.gmail.com.
