Hi Ian,

There is no concern from the dev team. We can try to run the OT from M106
to M108 if possible.

On Sat, Sep 3, 2022 at 5:40 AM Ian Clelland <iclell...@chromium.org> wrote:

>
> On Wed, Aug 31, 2022 at 3:04 AM Ming-Ying Chung <m...@chromium.org> wrote:
>
>> 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.
>>
>
> Is it possible to extend this trial for a few releases? Most trials run
> for ~3 releases initially, and I think that would be useful here. I know of
> a number of external partners, eager to test the API, who might need more
> than a single release to be able to deploy this and get back sufficient
> data for constructive feedback.
>
>
>
>
>>
>> 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 <(816)%20678-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
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3JASU9Q8aJMnHhWBNtos_nLQEsUxebVDM--OUGaThE8DRyuQ%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/CA%2B_JMTzX5mni0CAqxKRaWNOecRB9N_PtHBmejbYiG1_1Ocy2fg%40mail.gmail.com.

Reply via email to