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

the path to interop here might take longer than we've hoped, it's very clear from the abundant linked documentation that the team has done everything possible to set this feature

ICU 74.2 to ICU 77.1, the current latest release. ICU 77 contains CLDR 46 > and other changes to support Unicode 16. The web-exposed changes are mainly > the Intl and RegExp APIs

client ID to the IdP. With this proposal, if the API is called from within a cross-site iframe (and allowed by the embedder via a permissions policy), the browser will also send the top

concrete way to further reduce the uncertainty >> beyond manually checking hundreds of sites and making a judgment call >> about whether each is improved or not, which

> issues to make it better: > - https://chromium-review.googlesource.com/c/chromium/src/+/6937127 > - https://chromium-review.googlesource.com/c/chromium

approving this intent related to > Web Feature ID. Are you able to check this entry and help us understand why > the error showed up? > > Best, > > Alex > > On Monday

landing this to M142. FYI, I wanted to call out the two part shipping plan for this (in case the "Non-finch justification" in the original post was not obvious): - The IDL change

most people to bcc to avoid noise. Hi Jonathan (and Domenic): I already spotted executor.sub.html because that is the only *test resource* file to use test_driver.Actions(). Unfortunately

we need to go first is much higher than >>>> when closing compatibility gaps. >>>> >>>> This explainer doesn't indicate why anyone needs

> Back to the original intent, the only outstanding question I see > is the status of the WPTs. I see the CL > > has added 4 WPTs > > which are now passing in experimental

we expect to see. Can you please draft a separate document for this feature and address questions raised in the GH thread in that doc? Thanks, Alex On Tuesday, September 9, 2025 at 5:33

stay tuned to bug reports as well as metrics while Finching this. >> >> On Monday, September 8, 2025 at 11:15:38 AM UTC+2 Steinar H Gunderson >> wrote: >> >

enables authors to > specify that the target of an SVG hyperlink should be > downloaded rather than navigated to, mirroring the behavior > already supported in HTMLAnchorElement

this as to their specific use case. My goal is to improve our understanding of the motivation because right now it's unclear how to balance the benefits vs the risks of the feature

be useful to update that existing doc > for `CSS if()` to include this range syntax and the developer motivation > for it, along with the other suggestions from the TAG. The TAG

right place to ask but I'm curious what the status of this is? I'm on WebView 141 and it is still sending the X-Requested-With header. On Wednesday, April 19, 2023 at 2:55:38

> *To Vlad's questions:* >> >> > - I assume direct navigation to a local network is fine and remains >> without permission? (like navigating to your router's

> LGTM1 to ship async. > > On Fri, Aug 29, 2025 at 7:06 AM 'Virali Purbey' via blink-dev < > blink-dev@chromium.org> wrote: > >> Hi Daniel, >

locally due to issues with my machine. I think it would be best to run try jobs to identify any remaining modifications needed before the CL can be merged. Could you please run them for

be good to decide on a path forward. Based on the use counter call sites , these are the properties in question: - Intl.Locale.prototype.calendars - Intl.Locale.prototype.collations

LGTM3

the explainer to be light on details. I'm fine with it just pointing to example sections in the spec, but I think it'd be good to beef up these sections and explain what parts are

be renamed to `.tentative` until those discussions >>> settle? >>> >>> On Thu, Aug 21, 2025 at 7:42 PM Guido Urdaneta >>> wrote: >>>

The extension to a property bag carries some compat risk, but >> presumably that is reduced with the property bag casting to `true`, and all >> of its values being some version

so responsive to all the concerns raised to date. > > On Wednesday, August 20, 2025 at 11:37:40 AM UTC-7 janewman via > Chromestatus wrote: > >> The [spec PR](https

the explainer to move a code >>>> example to the beginning of the proposal and have also added examples for >>>> the considered alternatives. >>>

` option to >>> navigateEvent.intercept(), similar to `handler`, would defer the >>> commit until that handler (and all other precommit handlers) are >>

is willing to ship breaking changes to the feature based on future feedback, that's an acceptable risk. On Wednesday, August 20, 2025 at 5:02:20 AM UTC+2 Rick Byers wrote: >

restricting access to the Device >> Attributes API, which is available only for policy-installed kiosk web apps >> and policy-installed Isolated Web Apps, both only