Intent to extend origin trial: Pending Beacon API

[Ming-Ying Chung]

API owners,

We would like to extend the origin trial for 3 additional milestones, with the extension starting in 110 continuing through 112. The initial experiment was approved for the OT running from 107 through 109.

Contact emails

my...@chromium.org, fer...@chromium.org, deno...@chromium.org, pending-beac...@google.com

Explainer

https://github.com/WICG/pending-beacon/blob/main/README.md

Specification

https://wicg.github.io/pending-beacon/

Design docs

https://docs.google.com/document/d/1QIFUu6Ne8x0W62RKJSoTtZjSd_bIM2yXZSELxdeuTFo/edit?pli=1

Summary

A stateful PendingBeacon API allows website authors to specify one or more beacons (HTTP requests) that should be sent reliably when the page is being unloaded.

 

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

UI>Browser>Navigation>BFCache

TAG review

https://github.com/w3ctag/design-reviews/issues/776

TAG review status

Pending

Risks

N/A

 

Interoperability and Compatibility

 

 

Gecko: No signal: https://github.com/mozilla/standards-positions/issues/703

 

WebKit: No signal: https://github.com/WebKit/standards-positions/issues/85

 

Web developers: No signals

 

Other signals:

 

Ergonomics

N/A

 

 

Activation

 

Security

 

Goals for experimentation

• Collect usability feedback about the current API shape to decide how to improve the API design

• Collect stability metrics of the current API implementation

Reason this experiment is being extended

We have received feedback, resulting in a few additional implementation changes. The extension of OT will allow the OT participants to validate them. Specifically, they are:

 

• Address privacy around network changes and beacon timeout (issues/3, issues/30)

• API/IDL change to limit in secure context & HTTPS (issues/51) 

• Support dedicated worker (issues/39)

• Address other potential API shape change discussion (list)

 

Ongoing technical constraints

See “What’s not supported”

 

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?

Yes

 

Flag name

--enable-features=PendingBeaconAPI

or via Origin Trial Token

 

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1293679

 

Launch bug

https://launch.corp.google.com/launch/4200808

 

Estimated milestones

OriginTrial desktop last (new request)	112
OriginTrial desktop last	109
OriginTrial desktop first	107

OriginTrial desktop last (new request)	112
OriginTrial Android last	109
OriginTrial Android first	107

 

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/g/blink-dev/c/tPTRZkSmlbg/m/6oYq7FtHBAAJ

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/Vd6RTIfxkiY/m/HECcgiDOAAAJ

Read for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/CE3ngAKFil4/m/wG-ziOFGAQAJ

[Yoav Weiss]

LGTM to continue experimentation till M112 inclusive. Note that any extensions beyond that would require showing substantive progress towards shipping (evidence of feedback addressed, draft specification, etc).

Thanks for addressing that feedback! :)

 

--
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/CAH3JASW-db1jo0XCG_DCStyjvhUa6Y-UJUi2PP%2B8wfyjZBTQEQ%40mail.gmail.com.

[Fergal Daly]

On Mon, 28 Nov 2022 at 14:55, Yoav Weiss <yoav...@chromium.org> wrote:

LGTM to continue experimentation till M112 inclusive. Note that any extensions beyond that would require showing substantive progress towards shipping (evidence of feedback addressed, draft specification, etc).

Having moved to a 4-week release, you get the email telling you "it's time to make a decision on your OT" about 2 weeks after it hits stable. With the old release schedule, I think you would have had 6 weeks of stable before receiving that mail.

It seems like the 3 releases rule needs to be updated for the new schedule,

F

[Fergal Daly]

On Mon, 28 Nov 2022 at 15:18, Fergal Daly <fer...@google.com> wrote:

On Mon, 28 Nov 2022 at 14:55, Yoav Weiss <yoav...@chromium.org> wrote:

LGTM to continue experimentation till M112 inclusive. Note that any extensions beyond that would require showing substantive progress towards shipping (evidence of feedback addressed, draft specification, etc).

Having moved to a 4-week release, you get the email telling you "it's time to make a decision on your OT" about 2 weeks after it hits stable. With the old release schedule, I think you would have had 6 weeks of stable before receiving that mail.

It seems like the 3 releases rule needs to be updated for the new schedule,

For the record, it seems this was already discussed and agreed. The typical length should be 4 cycles and the max extension is 9. However it does not seem to have stuck in the consciousness and some docs do not match.

I have brought the docs to the attention of the OT team,

F