'd ship to Stable in 154. > > If that still doesn't leave 4 weeks lead time you can leave that > "Announcement lead time” box unchecked if it hasn't been unchanged

ready to ship? > > Is there a spec issue > tracking the nested frames case? I didn't see one in a quick scan, and I > notice TAG is asking about it as well. > > On Thu

intend to ship this additional behavior. >>>> >>>> >>>> >>>> Lastly, please request the other reviews in Chromestatus (Privacy

it should ship with the default of "start end" as specified in the spec. Current tests are here . The compat risk is only for the beginning and end of lines. I think it's

the original intent mentioning stubbing the >>>>> `fenced-frame-element.config.setSharedStorageContext()` API but that would >>>>> not

LGTM1 to ship once the test names are corrected >>>>> and assuming you'll check the wpt.fyi results after it lands and fix any >>>>> issues before

with the intent of the Background Fetch spec (that such >> requests go through the Fetch spec and have the same security policies >> applied to them, in this case Local Network

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

reviewing this Intent today, and I wanted to thank you >>> specifically for the work that has gone into characterizing the compat >>> risk. The linked Google Doc

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

this to Intent-to-Prototype-and-Ship. Do we need a new thread? On Monday, August 17, 2026 at 12:31:10 PM UTC-7 Alex Russell wrote: > Very exciting; any reason not to upgrade this

archive this Intent? > > Best, > > Alex > > On Monday, June 15, 2026 at 11:37:54 AM UTC-7 Alex Russell wrote: > >> Have there been updates related to any of

Owners Draft Intent to Ship email as it >>> did not appear I could edit any of the prefilled sections (I wanted to >>> include more information and change the Subject

LGTM1 to ship in 154, provided we continue to >> address any concerns or feedback that come in up to that point. >> >> On Wednesday, August 12, 2026 at 3:04:40 AM UTC

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

going to ship this change in WHATWG meetings and the spec PR several months ago. *Gecko*: No signal *WebKit*: No signal *Web developers*: No signals *Other signals*: *Ergonomics*

That makes sense. Thank you Geoff! Ray On Thursday, August 6, 2026 at 2:07:09 PM UTC-4 Geoff Lang wrote: > I would prefer not to enable

Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> *No information

Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> *No information

awogbemila@ pointed out in a fork of the thread that the spec PR is landed now. Thanks! LGTM3 On Monday, August 3, 2026 at 9:27:13 AM UTC-7 Dan Clark

Superfluous LGTM4; thanks for the flexibility, Edman. Best, Alex On Thursday, July 30, 2026 at 4:51:24 PM UTC-7 Chris Harrelson wrote: > LGTM3 >

first to ship a feature, we're always >>>>>> trying to answer the question "*does this feature solve an important >>>>>> problem

Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> Low. The

Does this intent deprecate or change behavior of > existing APIs, such that it has potentially high risk > for Android WebView-based applications? > > /No information

LGTM3 On Monday, July 27, 2026 at 11:46:02 AM UTC-7 sligh...@chromium.org wrote: > LGTM2 > > On Monday, July 27, 2026 at 9:52:37 AM UTC-7 Mike

we can ship it, I'd also be supportive of extending an OT to give your >> customers a bit more time (3 more months) to migrate to the shipped API. >> >> Rick >

permission to ship these webdriver-only changes. >>>> Webdriver classic is a little special in that there doesn't seem to be a >>>> sane way to flag

> and ship ASAP. We don't want OTs hanging out as "soft launch" mechanisms, >> and it sounds like you understand what bits of polish need to be added to >>

Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> *No information

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