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/CAARdPYfs6S0U7pLPZTUXC8B0E-%3DxRpouKFXSsZegc4_kpgRw2Q%40mail.gmail.com.
