Sounds good - we'll consider this Intent paused until we hear otherwise.
On 6/27/22 10:14 PM, Daisuke Enomoto 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 <[email protected]> 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 [email protected]
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
<[email protected]> wrote:
On 6/17/22 10:59 AM, Ming-Ying Chung wrote:
Contact emails
[email protected], [email protected],
[email protected]
Explainer
https://github.com/darrenw/docs/blob/main/explainers/beacon_api.md
<https://github.com/darrenw/docs/blob/main/explainers/beacon_api.md>
Specification
https://clelland.github.io/page-unload-beacon/spec.html
<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
<https://bugs.chromium.org/p/chromium/issues/detail?id=1293679>
Launch bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1323615
<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
<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 [email protected].
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ee757801-1588-f29a-8268-98bbad527908%40chromium.org.
