[blink-dev] Re: Intent to Experiment: Crash Reporting key-value API

> > I've noted a few issues, which do not block origin trial but might be > worth addressing beforehand since they change the observable impact of the > API: Thanks! Everything has now either been commented on, or is on its way to being addressed. I hope to get any API changes in before the M140

Re: [blink-dev] Re: Intent to Ship: Controlled Frame API (available only to IWAs)

As one of this feature's spec mentors, I'd like to offer a spec maturity statement . Since this feature was last discussed, Robbie and the team have made the changes that API OWNERs and spec reviewers, including myself, have

Re: [blink-dev] Intent to Ship: Crash Reporting API: is_top_level & visibility_state

Thanks for pointing this oversight out! It's been addressed in the spec, and the impl is up for review and looking good. So I'm hopeful that reviews here can proceed now. On Wed, May 14, 2025 at 12:53 AM Domenic Denicola wrote:

Re: [blink-dev] Re: Intent to Ship: Call stacks in crash reports from unresponsive web pages

eve this should block the I2S. We will continue to work on stabilizing >> the tests and aim to have them enabled as soon as possible. >> On Thursday, March 27, 2025 at 1:33:35 PM UTC-7 mike...@chromium.org >> wrote: >> >>> Thanks Dom - that's not a great scena

Re: [blink-dev] Re: Intent to Ship: Call stacks in crash reports from unresponsive web pages

Non API OWNER here, but when looking through this feature I noticed that there are no tests for it. This line in reporting_browsertest.cc dis

Re: [blink-dev] Re: Intent to Ship: Observable API

a meeting with Dominic and I now understand why it happens. It still > seems unusual, but given that this hasn't come up for anyone else looking > at the API (people who have way more experience with observables than I > do), I guess it's just that I'm unfamiliar with these pat

Re: [blink-dev] Re: Intent to Ship: Observable API

he second subscription rolls around, the iterator has been exhausted. But you still don't "miss the end" since the `complete()` handler fires. Hopefully that makes sense. Either way, it's entirely possible this thread isn't the best place to hash all of this out :) On Fri,

Re: [blink-dev] Re: Intent to Ship: Observable API

't want to use > SuppressedError for most callbacks. If I misunderstood, then we should > delay until that gets straightened out. > > On Thu, Feb 27, 2025 at 5:53 AM Jake Archibald > wrote: > >> On Wed, 26 Feb 2025 at 20:39, Dominic Farolino wrote: >> >>>

[blink-dev] Re: Intent to Ship: Observable API

mentation, per https://x.com/BenLesh/status/1893053275995357608 and https://github.com/ReactiveX/rxjs/issues/6367. On Wed, Feb 26, 2025 at 3:39 PM Dominic Farolino wrote: > https://codepen.io/jaffathecake/pen/raNWMmK?editors=0012 - it seems >> inconsistent that two of the calls to ob.ma

[blink-dev] Re: Intent to Ship: Observable API

> > https://codepen.io/jaffathecake/pen/raNWMmK?editors=0012 - it seems > inconsistent that two of the calls to ob.map create a new subscriber, > whereas the other picks up the observable half way through. Right, the idea that a subscription doesn't have side effects if an existing subscription i

Re: [blink-dev] Re: Intent to Ship: DOM `moveBefore()` method, for state-preserving atomic move

uppose we'll debate this exact thing over in the spec PR <https://github.com/whatwg/dom/pull/1307>. On Thu, Nov 21, 2024 at 3:22 PM Jeffrey Yasskin wrote: > On Wed, Nov 20, 2024 at 12:55 PM Dominic Farolino > wrote: > >> What's preventing the PR from landing? >> >

Re: [blink-dev] Re: Intent to Ship: DOM `moveBefore()` method, for state-preserving atomic move

> > What's preventing the PR from landing? Just the fact that it hasn't been fully reviewed yet. We've received initial comments, but are waiting for a full round and LGTMs, and are confident they'll come soon. There was a lengthy discussion about this at WHATWG before and as a result > of the T

[blink-dev] Intent to Ship: DOM `moveBefore()` method, for state-preserving atomic move

Contact emails...@chromium.org, nrosent...@chromium.org ExplainerExplainer Specificationhttps://github.com/whatwg/dom/pull/1307 Summary This feature adds a new DOM primitive (Node.prototype.moveBefore()) that allows movin

[blink-dev] Intent to Prototype: Observable API

Contact emails...@chromium.org Explainerhttps://github.com/WICG/observable SpecificationNone Summary Observables are a popular reactive-programming paradigm to handle an asynchronous stream of push-based events. They can be thought of as Promises but for multiple events, and aim to do what Prom

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

> > It looks like the spec PR here has been dormant for something like ~9 > months. Are there any plans to help drive it to the finish line, > especially given the TODOs listed in the OP? How should we all think about > whatever work might remain there, and possibly deviate from what Chrome > plans

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

> > *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1532642) > In implementation. "In implementation" and "No signal" sound a little conflicting. Is the feature *definitely* being implemented in Firefox? Can we file for a proper standards signal to be sure? Specificationhttps://

Re: [blink-dev] Re: Intent to Prototype: Web environment integrity API

At the very least, an explicit commitment to a holdback would seem to quell *some* of the concerns about this feature. But one thing I'm concerned about is if there'd be a difference in holdback between Chrome and WebView. Since WebView isn't always considered a "real browser" I could see this as a

Re: [blink-dev] Intent to Ship: Inherit Base URL snapshot for about:blank and about:srcdoc, with about:blank inheriting from initiator, not parent.

The niche-ness of these changes plus the fact that they've been rolled out on Canary+Dev for some time *and* that we've already smoked out some compat issues at that level of experimentation for the adjacent work the team looked into (censoring the base URL for sandboxed about:srcdoc Documents) mak

Re: [blink-dev] Intent to Ship (I2S): Protected Audience

As the spec mentor for this feature I'll offer a spec maturity summary

Re: [blink-dev] Developer pain as a result of "introducing blink_wpt_tests"

I first saw the >>>>> original blink-dev email, I thought "generic baselines" meant something >>>>> like "non-web platform test baselines", not "WPT expectation files that >>>>> are >>>>> platform-agnostic"

[blink-dev] Developer pain as a result of "introducing blink_wpt_tests"

I write a lot of web platform tests as a Web Platform engineer; recently I wrote one in external/wpt/ (the external web platform tests directory), and was shocked to find the eradication of `-expect