Hi Wonik, The use of blink::IsXMLMimeType in chrome/browser/actor/execution_engine.cc isn't web exposed AFAICT, so the risks related to that are best handled as part of regular code review. But good to hear that there's no concern from the reviewer.
Best regards, Philip On Fri, Oct 9, 2026 at 1:56 PM Wonik Choi <[email protected]> wrote: > Hi Philip, all, > > Thanks for the review and LGTM, Philip. > > I noticed that I accidentally pasted the compatibility text into section 5 > of my previous reply, leaving out the Actor update. Sorry about that. > > There is one other affected caller: Actor’s navigation check. Chris > reviewed this interaction and explained that the checks help prevent the > model from ingesting potentially sensitive structured data that could be > targeted for exfiltration through prompt injection. He wrote: > > *From that perspective I think these changes are appropriate for the Actor > code; I have no concerns about default enablement of the > SpecCompliantXmlMimeTypes feature.* > > The Resource Timing value for image/svg+xml stays unchanged, but the > shared XML helper changes its classification, which can affect Actor’s > blocking decisions when those checks are enabled. > > The browser tests did not exercise Actor. I also haven’t separately > confirmed whether the earlier security review covered this interaction. > > Thanks, Wonik > > 2026년 10월 9일 금요일 오후 8시 14분 36초 UTC+9에 Philip Jägenstedt님이 작성: > >> Oops. I answered my own question about object embedding and >> blink::IsXMLMimeType isn't used in that code path. (Forgot to edit before >> sending.) >> >> On Fri, Oct 9, 2026 at 1:09 PM Philip Jägenstedt <[email protected]> >> wrote: >> >>> Hi Wonik, >>> >>> Thank you for the testing current behavior. My interpretation of your >>> results: >>> >>> - Object embedding: Firefox and Safari disagree, so we need to take >>> care. Is this code path affected by blink::IsXMLMimeType though? >>> - Direct navigation: Not interoperable, but as you say "Recognizing >>> something as XML does not, by itself, establish that the browser will >>> display it as an XML document when navigated to." >>> - XHR document responses: Interoperable, phew! >>> - XHR text decoding: Firefox and Safari disagree, but this might not >>> be because of "+xml", it could be due to how invalid XML is generally >>> treated. >>> >>> >>> In terms of the compat risk, since `contentType` is an attribute >>> there's no meaningful way to measure the risk of the value changing. But if >>> blink::IsXMLMimeType >>> only affects this one attribute, it seems low risk enough that we should >>> just try to ship it and be ready to revert if there are bug reports. >>> >>> LGTM1 >>> >>> Best regards, >>> Philip >>> >>> >>> On Fri, Oct 9, 2026 at 12:23 PM Wonik Choi <[email protected]> wrote: >>> >>>> Hi Daniel, Mike and Philip, >>>> >>>> Thanks for the questions. I’ve reviewed the affected code paths, >>>> checked the Actor interaction, and completed the browser comparisons. I’ll >>>> address the points together below. >>>> >>>> *1. Specification basis and motivation* >>>> >>>> I should have linked the MIME minimization algorithm directly, rather >>>> than only the XML MIME type definition. >>>> >>>> The XML definition includes text/xml, application/xml, and MIME types >>>> whose subtype ends in +xml. >>>> >>>> The minimization algorithm preserves image/svg+xml in step 3 and >>>> returns application/xml for other XML MIME types in step 4: >>>> >>>> >>>> - https://mimesniff.spec.whatwg.org/#xml-mime-type >>>> - https://mimesniff.spec.whatwg.org/#minimize-a-supported-mime-type >>>> >>>> Fetch uses this algorithm when recording response information for >>>> Resource Timing, and PerformanceResourceTiming.contentType exposes that >>>> recorded value: >>>> >>>> >>>> - https://fetch.spec.whatwg.org/#fetch-response-handover >>>> - >>>> >>>> https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-contenttype >>>> >>>> This is a conformance change, not a fix motivated by a particular >>>> security vulnerability. It changes the MIME value recorded for Resource >>>> Timing. It does not rewrite the server’s HTTP Content-Type header or >>>> response body, and the timing value does not select a parser or external >>>> application. >>>> >>>> There is a separate effect on Actor because it uses the same >>>> classification helper; I address that below. >>>> >>>> *2. Implementation scope and classifier unification* >>>> >>>> The implementation is here: >>>> >>>> https://chromium-review.googlesource.com/c/chromium/src/+/8301932 >>>> >>>> This CL changes blink::IsXMLMimeType, which is used by Resource Timing >>>> minimization and Actor’s MIME checks. >>>> >>>> MIMETypeRegistry::IsXMLMIMEType is a separate implementation. It >>>> already recognizes non-application +xml types in cases such as those tested >>>> here, and this CL does not change it. XHR uses that implementation, as do >>>> renderer document-type and decoder-selection paths. >>>> >>>> Object embedding and navigation also involve MIME-support and download >>>> decisions. Recognizing something as XML does not, by itself, establish that >>>> the browser will display it as an XML document when navigated to. >>>> >>>> The proposed unification of the two classifiers is outside this CL. >>>> That work would need a separate assessment of the callers and behavior >>>> differences before proceeding. >>>> >>>> *3. Browser comparisons and feature OFF/ON results* >>>> >>>> I tested the following installed release browsers on macOS 26.5.1 >>>> (25F80), without changing experimental flags: >>>> >>>> - Safari 26.5 (21624.2.5.11.4) >>>> - Firefox 157.0.1 >>>> - Google Chrome 154.0.8037.58 >>>> >>>> I used a local HTTP server to serve a small XML document with different >>>> Content-Type headers. Requests were same-origin. The results below focus on >>>> text/example+xml, image/example+xml and font/example+xml. >>>> >>>> The tests were run on October 9, 2026. The normal response body was a >>>> small XML document with a probe element containing XML_TEST_OK. XHR, >>>> decoding and Resource Timing results were collected automatically. For >>>> objects, I recorded document information as well as the displayed result; >>>> direct navigation was checked manually. >>>> >>>> Object embedding: >>>> >>>> I checked each response with the object’s type attribute omitted and >>>> explicitly set. >>>> >>>> >>>> - For text/example+xml, all three browsers displayed source text >>>> without the attribute. With it specified, Chrome and Firefox displayed >>>> source text, while Safari displayed fallback content. >>>> - For image/example+xml and font/example+xml, Firefox and Safari >>>> displayed fallback in both cases. Chrome showed a blank view without >>>> type >>>> and fallback with it. The blank cases still had pending events when >>>> sampled, so I can’t say whether they had reached a final state. >>>> >>>> Direct navigation: >>>> >>>> >>>> - All three browsers displayed text/example+xml as source text and >>>> downloaded image/example+xml and font/example+xml. >>>> >>>> XHR document responses: >>>> >>>> >>>> - All three parsed these responses as XML in both the default >>>> response mode and responseType="document". >>>> >>>> XHR text decoding: >>>> >>>> I served an XML declaration specifying windows-1252, with body bytes >>>> representing “café” in that encoding. >>>> >>>> >>>> - The returned text matched across browsers. Default XHR without an >>>> HTTP charset used the XML declaration and returned “café”. Explicit >>>> responseType="text" returned “caf�”. Adding an HTTP charset=utf-8 also >>>> produced “caf�” in both modes. >>>> - There was a separate responseXML difference in that deliberately >>>> invalid UTF-8 case: Firefox returned null, while Chrome and Safari >>>> returned >>>> a document containing the replacement character. >>>> >>>> Effect of this CL: >>>> >>>> I repeated these checks with the same local Chromium 157.0.8092.0 >>>> build, with SpecCompliantXmlMimeTypes disabled and enabled in separate >>>> profiles. >>>> >>>> >>>> - I observed no differences in these four areas between OFF and ON. >>>> - The recorded differences were the Resource Timing contentType >>>> values for the three MIME types above, which became application/xml with >>>> the feature enabled. >>>> >>>> So the engines agree on XML parsing for these normal XHR fixtures, but >>>> that does not extend to every use of the XML MIME definition. In >>>> particular, object handling differs, and direct navigation does not display >>>> these responses as XML documents. >>>> >>>> These are observations from local tests on one OS, not an official WPT >>>> run. >>>> >>>> The implementation also includes C++ tests for both feature states. The >>>> WPT additions for Resource Timing minimization are here: >>>> >>>> https://github.com/web-platform-tests/wpt/pull/62420 >>>> >>>> *4. Compatibility and RUM providers* >>>> >>>> Code that branches on the old contentType values, or uses them to group >>>> resources in reports, could behave differently when it receives >>>> application/xml. >>>> >>>> I don’t have usage measurements or RUM-provider feedback showing how >>>> often sites rely on those values. The tests above tell us what changes, but >>>> not how much breakage to expect. >>>> >>>> I don’t have a RUM-provider request or issue to point to; this change >>>> is driven by spec conformance. This intent thread is where I’ve raised the >>>> behavior change for review. >>>> >>>> I also don’t have evidence that enterprise applications are more likely >>>> to be affected. I shouldn’t have singled them out in the original >>>> description. The same concern applies to any application relying on the >>>> previous values. >>>> >>>> For the application/atom+xml example, Chrome already reports >>>> application/xml in both the installed version and the local build. That >>>> value is not newly changed by this feature. >>>> >>>> *5. Actor* >>>> >>>> This change is driven by spec conformance; I don’t have a RUM-provider >>>> request or issue to point to. I’ve raised the behavior change in this >>>> intent thread, but haven’t contacted RUM providers directly. >>>> >>>> Code that branches on the previous contentType values, or uses them to >>>> group resources in reports, could behave differently when those values >>>> become application/xml. The local tests show which values change, but I >>>> don’t have usage measurements or provider feedback to estimate how often >>>> this would cause problems. >>>> >>>> There’s no evidence that enterprise applications are more likely to be >>>> affected, so I shouldn’t have singled them out in the original description. >>>> The same concern applies to any application relying on the previous values. >>>> >>>> For the application/atom+xml example, Chrome already reports >>>> application/xml in both the installed version and the local build. That >>>> value is not newly changed by this feature. >>>> >>>> *6. Mozilla and WebKit positions* >>>> >>>> I followed up on the existing position issues to ask whether they cover >>>> this change. >>>> >>>> Mozilla: >>>> https://github.com/mozilla/standards-positions/issues/705#issuecomment-6030333458 >>>> >>>> WebKit: >>>> https://github.com/WebKit/standards-positions/issues/88#issuecomment-6030345052 >>>> >>>> WebKit confirmed that its existing position covers this, since >>>> minimization was a condition of its support. The Mozilla link is my >>>> follow-up question, rather than a confirmation from Mozilla. >>>> >>>> Thanks, Wonik >>>> 2026년 10월 8일 목요일 오후 9시 19분 25초 UTC+9에 Philip Jägenstedt님이 작성: >>>> >>>>> 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/CAARdPYfT1LqgbXaTgevcrza8HrCSbdLVOS88ULhoYbfF_7r0Mg%40mail.gmail.com.
