Hi all, Reviving this thread as we plan to conduct an Origin Trial for this feature in M106, with the following updates. Please take a look.
Explainer https://github.com/WICG/unload-beacon/blob/main/README.md Specification https://wicg.github.io/unload-beacon/ (In draft state) On Tue, Jun 28, 2022 at 11:23 PM Joe Medley <jmed...@google.com> wrote: > Daisuke, > > That makes it either a dev trial or an origin trial. Since you've recorded > a value for origin_trial_feature_name in runtime_enabled_features.json5 > that makes it an origin trial. I assume that's starting in 105? > > Joe > Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com | > 816-678-7195 > *If an API's not documented it doesn't exist.* > > > On Mon, Jun 27, 2022 at 7:14 PM Daisuke Enomoto <denom...@chromium.org> > wrote: > >> Joe, the API is behind the flag "PendingBeaconAPI". >> >> Mike, we came to discuss the new ideas of API design after we sent this >> I2E. We will update the I2E thread when we have clarity on the design >> discussion and the timeline when an experiment can start. >> >> Caleb, thank you for filing an issue. >> >> On Tue, Jun 28, 2022 at 3:09 AM Caleb Raitto <carai...@google.com> wrote: >> >>> Hi, I filed https://github.com/darrenw/docs/issues/3 about a time limit >>> on the duration from bfcache page freeze to beacons being sent -- could you >>> PTAL? >>> >>> Thanks, >>> -Caleb >>> >>> On Friday, June 24, 2022 at 9:36:15 AM UTC-4 mike...@chromium.org wrote: >>> >>>> Thanks - sounds good. >>>> >>>> Could you clarify the desired experiment timeline? Is it just for M104, >>>> or something else? >>>> >>>> On 6/20/22 12:31 AM, Fergal Daly wrote: >>>> >>>> Sorry, there were some details left out of this I2E. We actually have a >>>> lot of signals from web devs on this. There are some comments on >>>> >>>> >>>> https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776 >>>> >>>> but we also presented this to W3C WebPerf with a lot of positive >>>> signals. Minutes are here >>>> <https://w3c.github.io/web-performance/meetings/2022/2022-03-31/index.html> >>>> from >>>> the most recent one. >>>> >>>> We don't have any reaction from Mozilla or WebKit that I know of and we >>>> will file a TAG request shortly, >>>> >>>> F >>>> >>>> On Sat, 18 Jun 2022 at 02:57, Mike Taylor <mike...@chromium.org> wrote: >>>> >>>>> On 6/17/22 10:59 AM, Ming-Ying Chung wrote: >>>>> >>>>> Contact emails >>>>> >>>>> my...@chromium.org, fer...@chromium.org, deno...@chromium.org >>>>> >>>>> Explainer >>>>> >>>>> https://github.com/darrenw/docs/blob/main/explainers/beacon_api.md >>>>> >>>>> Specification >>>>> >>>>> https://clelland.github.io/page-unload-beacon/spec.html (In draft >>>>> state) >>>>> >>>>> Summary >>>>> >>>>> A stateful API for beacons that has the browser control the time >>>>> beacons are sent. >>>>> >>>>> Existing beacon APIs are all based around a developer constructing and >>>>> sending a beacon, and there's no good time for that "send" call to be >>>>> made. >>>>> (Handlers such as 'unload' are often ignored, for example.) This API >>>>> delegates the sending to the browser itself, so it can support beacons on >>>>> page unload or on page hide, without the developer having to implement >>>>> send >>>>> calls at exactly the right times. >>>>> >>>>> >>>>> Blink component >>>>> >>>>> Blink>Network >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork> >>>>> >>>>> TAG review >>>>> >>>>> None yet. >>>>> >>>>> I'd recommend filing a TAG review as well as asking for signals now, >>>>> to allow folks plenty of time to respond. >>>>> >>>>> TAG review status >>>>> >>>>> N/A >>>>> >>>>> Risks >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> Gecko: No signal >>>>> >>>>> WebKit: No signal >>>>> >>>>> Web developers: No signals >>>>> >>>>> Other signals: >>>>> >>>>> 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? >>>>> >>>>> >>>>> Goals for experimentation >>>>> >>>>> The intent is for experiments to learn that developers can easily >>>>> adopt the API shapes to achieve current use cases in addition to getting >>>>> feedback from them. The experiment also aims to test the stability and >>>>> reliability of the API. >>>>> >>>>> Ongoing technical constraints >>>>> >>>>> In M104, the API described in the explainer is not yet fully >>>>> developed, such that the API >>>>> >>>>> - >>>>> >>>>> Supports only the GET method. Setting it to POST will fall back to >>>>> GET. >>>>> - >>>>> >>>>> Does not support request payload, i.e. it does not send out data >>>>> set by setData(data). >>>>> - >>>>> >>>>> Does not support pageHideTimeout. >>>>> - >>>>> >>>>> Does not recover from browser crashes, forced closures, network >>>>> failure, etc. >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> There are no particular debugging APIs made available or Chrome >>>>> DevTools integrations for this OT. We plan to build an integration with >>>>> Chrome DevTools to provide a better developer experience. This OT will >>>>> allow us to get feedback that helps us build the right design. >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>> >>>>> Yes >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? >>>>> >>>>> No, basic tests are present and we will be adding more as we complete >>>>> more of the implementation. >>>>> >>>>> Flag name >>>>> >>>>> PendingBeaconAPI >>>>> >>>>> Requires code in //chrome? >>>>> >>>>> False >>>>> >>>>> Tracking bug >>>>> >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1293679 >>>>> >>>>> Launch bug >>>>> >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1323615 >>>>> >>>>> Estimated milestones >>>>> >>>>> M104 for off-by-default experiment >>>>> >>>>> Just to confirm, the request is only for a single milestone (104)? >>>>> >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5690553554436096 >>>>> >>>>> Links to previous Intent discussions >>>>> >>>>> Intent to prototype: >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG%2BRaU7yMQ%2BRkeSpXhgbfCSGb4BvpW-exTUFZzb_eMFRE%2B_syQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cag+rau7ymq+rkespxhgbfcsgb4bvpw-extufzzb_emfre+_...@mail.gmail.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 blink-dev+...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3JASV7pR%3D3poOA0x2sQgVLOobtjCyfxLE3kYsnasfBVSyOEg%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3JASV7pR%3D3poOA0x2sQgVLOobtjCyfxLE3kYsnasfBVSyOEg%40mail.gmail.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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3JASU9Q8aJMnHhWBNtos_nLQEsUxebVDM--OUGaThE8DRyuQ%40mail.gmail.com.
