[blink-dev] Intent to Ship: AbortSignal.timeout() Static Method

[Scott Haseley]

Contact emailsshase...@chromium.org

Explainerhttps://github.com/whatwg/dom/pull/1032#issue-1058779111

Specificationhttps://dom.spec.whatwg.org/#dom-abortsignal-timeout

Summary

Returns a new AbortSignal object that is automatically aborted after a
given number of milliseconds. This method can be used by developers to
easily implement timeouts for signal-accepting async APIs, e.g. fetch().

Blink componentBlink>DOM


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/711

Note: the TAG review is still pending (we replied to their initial set of
questions and are awaiting response). Since filing the issue, however, the
DOM spec PR has been merged and Safari and Firefox have implemented the
feature, meaning this should be exempt from TAG review.

TAG review statusPending

Risks

Interoperability and Compatibility

Low risk. This feature is already part of the DOM standard, has web
platform tests, and is implemented by Safari and Firefox. We'll improve
eventual interop by shipping this feature.


Gecko: Shipped/Shipping (
https://bugzilla.mozilla.org/show_bug.cgi?id=1753309). Available in FF 100

WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=236039).
Available in Safari TP Release 141:
https://developer.apple.com/safari/technology-preview/release-notes/

Web developers: Positive. Positive reception to Chrome, Safari, and Node
tweets:
- https://twitter.com/tomayac/status/1494575885785174016
- https://twitter.com/chris_dumez/status/1489297763082772481
- https://twitter.com/simonplend/status/1494309000824954882

Other signals: This has also shipped in Node and Deno.

Ergonomics

We think this API is useful on its own, but also think it will benefit from
an API to combine AbortSignals, e.g. combining a timeout with user
cancellation, which we're currently working on:
https://github.com/shaseley/abort-signal-any/blob/main/README.md.

Activation

The feature has already been implemented in both Safari and Firefox, but it
would benefit from a polyfill for use in older browser versions.

Security

None.

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?

No, this change is strictly additive.


Debuggability

Basic tooling only, i.e. autocomplete support for the new AbortSignal
method will be provided.

Is this feature fully tested by web-platform-tests

?Yes

Flag name--enable-blink-features=AbortSignalTimeout

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1181925

Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1292159

Measurement
https://chromestatus.com/metrics/feature/popularity#AbortSignalTimeout

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open
source repository and its open-source dependencies to function?
No.

Sample links
https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/timeout

Estimated milestones

103

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).

None.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5768400507764736

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ21UGV-atHU38es8AtFC4tYX7PQrMCoq-zObxo36z4ELQ%40mail.gmail.com



This intent message was generated by Chrome Platform Status
.

-- 
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/CAKXGoJ3TAcMOMsYtEVbDubh5NLVT%3Dm6TANkvAWYAZO8Mhn-15A%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Restrict Gamepad usage

['Tarek ElBahnasawy' via blink-dev]

Hi guys,

Any other comments or concerns?

Tarek ElBahnasawy

Sr. Technical Program Manager

Web Platform

telbahnas...@google.com


On Wed, Apr 20, 2022 at 10:38 PM Yoav Weiss  wrote:

> LGTM1
>
> On Wednesday, April 20, 2022 at 7:54:48 PM UTC+2 mattre...@google.com
> wrote:
>
>> > Is it correct to think that since this intent doesn't change the secure
>> context requirements for the API, this signal is not meaningful here?
>>
>> Yes, this was feedback for the secure context change and isn't relevant
>> here. We decided to communicate the secure context change in a separate
>> intent but forgot to remove the feedback.
>>
>> > More broadly, since the Permission Policy's default will be `*`, the
>> top-level origin would need to change their policy for embedded contexts to
>> lose their permission, right?
>>
>> Correct.
>> On Wednesday, April 20, 2022 at 4:45:26 AM UTC-7 yoav...@chromium.org
>> wrote:
>>
>>> On Wed, Apr 20, 2022 at 3:51 AM 'Tarek ElBahnasawy' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Contact emailsmattre...@google.com

>>>
 Explainer

 https://hacks.mozilla.org/2020/07/securing-gamepad-api/

 Specification

 https://www.w3.org/TR/gamepad/

 https://github.com/w3c/gamepad/pull/112

 Design docs


 https://docs.google.com/document/d/1Dj_7EpT9ttnI96BuNXtLEJkHEq0orHgoLeYaOBz9xsU/edit?usp=sharing

 Summary

 Adds a "gamepad" permissions policy-controlled feature. Information
 about connected gamepads is only provided to contexts that are allowed to
 access the "gamepad" feature.  Default policy allows cross-origin iframes
 and does not change behavior on existing sites.

 Note that the Securing Gamepad API
  article and 
 Chrome
 Platform Status entry
  also describe a
 change to require Secure Context. This intent only applies to the
 policy-controlled feature. The secure context requirement will be
 communicated in a separate Intent.

 Blink component

 Blink>GamepadAPI
 

 TAG review

 N/A

 Risks

 Interoperability and Compatibility

 Firefox initially rolled out this change with the default allowlist set
 to 'self' which broke some sites that accessed gamepads from a cross-origin
 iframe. To avoid breakage, the default allowlist was changed to '*' (all)
 which has the same behavior as the current implementation. Since the
 behavior is the same we do not anticipate any breakage.

 Gecko: Shipped in Firefox 82

 WebKit: No signals

 Web developers: Strongly Negative (
 https://github.com/w3c/gamepad/issues/145) Chris from Megapixel VR
 asked not to restrict to secure contexts due to breaking locally hosted
 (but not localhost) services and the use of self-signed certificates.

>>> Is it correct to think that since this intent doesn't change the secure
>>> context requirements for the API, this signal is not meaningful here?
>>> More broadly, since the Permission Policy's default will be `*`, the
>>> top-level origin would need to change their policy for embedded contexts to
>>> lose their permission, right?
>>>
>>>

 Other signals: None


 Is this feature fully tested by web-platform-tests
 
 ?

 Yes

 Flag name

 chrome://flags/#restrict-gamepad-access

 Requires code in //chrome?

 False

 Tracking bug

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

 Link to entry on the Chrome Platform Status

 https://chromestatus.com/feature/5138714634223616

>>>
 Tarek ElBahnasawy

 Sr. Technical Program Manager

 Web Platform

>>> telbah...@google.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/CAKfE4fJX8VOe1imhcv1AGZdg7EKMoDeO-_So5OemGv2pCeGiRQ%40mail.gmail.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+unsubscr...@chromium.org.
To view this discussion on the web visit 

Re: [blink-dev] Intent to Ship: Same-origin prerendering triggered by the speculation rules API

[Hiroki Nakagawa]

Hi Dave,

Yes, this is for Android only. Sorry, we should have clarified that point.
We're going to send separate I2P and I2S for the desktop.

Thanks,
Hiroki

On Sat, Apr 23, 2022 at 2:53 AM Dave Tapuska  wrote:

> This intent is for Android only, correct?
> Will there be another Intent to Ship on Desktop?
> Presumably desktop is blocked on extensions and the compatibility risk
> regarding those. (I recently discussed this at the WECG
> 
> meeting).
>
> dave.
>
> On Fri, Apr 22, 2022 at 1:27 PM 'Angel Raposo' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> noam.j.rosent...@gmail.com
>> dome...@chromium.org, jbro...@chromium.org, nhir...@chromium.org,
>> navigation-...@chromium.org
>>
>> Explainer
>>
>> This feature:
>>
>> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>>
>> Larger project:
>> https://github.com/WICG/nav-speculation/blob/main/README.md
>>
>> Specification
>>
>> https://wicg.github.io/nav-speculation/prerendering.html
>>
>> Design docs
>>
>>
>> https://docs.google.com/document/d/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>>
>> Summary
>>
>> Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
>> Web page before the user actually navigates to it. The main goal of
>> prerendering is to make the next page navigation faster, or ideally nearly
>> instant.
>>
>> Sites can tell the user agents about which pages the user may likely
>> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
>> user is at page A and will likely navigate to page B next). Once the
>> prerender is triggered, the browser pre-fetches the main resource,
>> instantiates a hidden page, and processes the main resource to fetch and
>> process more subresources.
>>
>> We would like to ship same-origin speculation rules prerendering. With
>> this feature, Chrome will start prerendering high-confidence URL
>> suggestions provided by the page using speculation rules. During the
>> prerendering process, a page will process and construct the full DOM tree,
>> including the execution of scripts (this differs from the prefetching
>> resources using No-state Prefetch
>> )
>>
>> This prerendering affects how the prerendered pages are processed. The
>> website gets loaded before the navigation is committed, and the
>> side-effects are delayed until activation (the actual navigation to the
>> website was committed). The website can know that it is being prerendered
>> (document.prerendering) and when it was activated (prerenderingchange
>> event, performance.activationStart timing). These APIs have already been
>> approved by the previous intent-to-ship for Omnibox prerendering
>> 
>> .
>>
>> Note that we are not shipping cross-origin speculation rules, which
>> allows a web page to prerender another page under a different domain
>> (external site). For details about our web exposed changes shipping plan,
>> please consult this doc: Interoperability Roadmap for Shipping
>> Prerender2 Incrementally
>> 
>> .
>>
>>
>> Blink component
>>
>> Internals>Preload>Prerender
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/667
>>
>> TAG review status
>>
>> Closed
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Compatibility
>>
>> There are some use cases that will need to know whether a page is being
>> prerendered by the user agent or navigated by the user, e.g. Ads and
>> analytics are likely examples of this.
>>
>> To solve this challenge, this feature exposes `document.prerendering`
>> which indicates if the page is prerendered or not. We understand that
>> there’s always a risk of sites, that would benefit from using this API, not
>> actually using it.
>>
>> We believe that this risk is tractable because:
>>
>> (1) triggering a prerender isn’t an entirely new behavior. E.g. Chrome
>> used to have a prerendering feature a long while ago
>> 
>> triggered by URLs entered in the navigation bar
>>
>> (2) Similar behaviors are already present in other browsers, e.g.
>> “Preload Top Hit” feature in Safari
>>
>> To give more flexibility to web authors (site owners) who want to
>> implement speculation rules, we are already including a header to network
>> requests as `Purpose: prefetch` so that origin servers can identify
>> requests for prerendered pages and decide how to handle them. A new header
>> will be included to provide a CORS safelist alternative 

Re: [blink-dev] Intent to Ship: Same-origin prerendering triggered by the speculation rules API

[Dave Tapuska]

This intent is for Android only, correct?
Will there be another Intent to Ship on Desktop?
Presumably desktop is blocked on extensions and the compatibility risk
regarding those. (I recently discussed this at the WECG

meeting).

dave.

On Fri, Apr 22, 2022 at 1:27 PM 'Angel Raposo' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> noam.j.rosent...@gmail.com
> dome...@chromium.org, jbro...@chromium.org, nhir...@chromium.org,
> navigation-...@chromium.org
>
> Explainer
>
> This feature:
>
> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>
> Larger project:
> https://github.com/WICG/nav-speculation/blob/main/README.md
>
> Specification
>
> https://wicg.github.io/nav-speculation/prerendering.html
>
> Design docs
>
>
> https://docs.google.com/document/d/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>
> Summary
>
> Prerendering is “pre”-rendering, it’s about pre-loading and rendering a
> Web page before the user actually navigates to it. The main goal of
> prerendering is to make the next page navigation faster, or ideally nearly
> instant.
>
> Sites can tell the user agents about which pages the user may likely
> visit, by asking to trigger a ‘prerendering’ for a particular URL (e.g.
> user is at page A and will likely navigate to page B next). Once the
> prerender is triggered, the browser pre-fetches the main resource,
> instantiates a hidden page, and processes the main resource to fetch and
> process more subresources.
>
> We would like to ship same-origin speculation rules prerendering. With
> this feature, Chrome will start prerendering high-confidence URL
> suggestions provided by the page using speculation rules. During the
> prerendering process, a page will process and construct the full DOM tree,
> including the execution of scripts (this differs from the prefetching
> resources using No-state Prefetch
> )
>
> This prerendering affects how the prerendered pages are processed. The
> website gets loaded before the navigation is committed, and the
> side-effects are delayed until activation (the actual navigation to the
> website was committed). The website can know that it is being prerendered
> (document.prerendering) and when it was activated (prerenderingchange
> event, performance.activationStart timing). These APIs have already been
> approved by the previous intent-to-ship for Omnibox prerendering
> 
> .
>
> Note that we are not shipping cross-origin speculation rules, which allows
> a web page to prerender another page under a different domain (external
> site). For details about our web exposed changes shipping plan, please
> consult this doc: Interoperability Roadmap for Shipping Prerender2
> Incrementally
> 
> .
>
>
> Blink component
>
> Internals>Preload>Prerender
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/667
>
> TAG review status
>
> Closed
>
> Risks
> Interoperability and Compatibility
>
> Compatibility
>
> There are some use cases that will need to know whether a page is being
> prerendered by the user agent or navigated by the user, e.g. Ads and
> analytics are likely examples of this.
>
> To solve this challenge, this feature exposes `document.prerendering`
> which indicates if the page is prerendered or not. We understand that
> there’s always a risk of sites, that would benefit from using this API, not
> actually using it.
>
> We believe that this risk is tractable because:
>
> (1) triggering a prerender isn’t an entirely new behavior. E.g. Chrome
> used to have a prerendering feature a long while ago
>  triggered
> by URLs entered in the navigation bar
>
> (2) Similar behaviors are already present in other browsers, e.g. “Preload
> Top Hit” feature in Safari
>
> To give more flexibility to web authors (site owners) who want to
> implement speculation rules, we are already including a header to network
> requests as `Purpose: prefetch` so that origin servers can identify
> requests for prerendered pages and decide how to handle them. A new header
> will be included to provide a CORS safelist alternative using
> `Sec-purpose: prefetch;prerender`
> https://fetch.spec.whatwg.org/#cors-safelisted-request-header
>
> https://chromestatus.com/feature/6247959677108224
>
> There’s also a future risk of the speculation rules specification changing
> :
> including new rules, modifying 

[blink-dev] Intent to Ship: Same-origin prerendering triggered by the speculation rules API

['Angel Raposo' via blink-dev]

Contact emails

noam.j.rosent...@gmail.com
dome...@chromium.org, jbro...@chromium.org, nhir...@chromium.org,
navigation-...@chromium.org

Explainer

This feature:

https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md

Larger project: https://github.com/WICG/nav-speculation/blob/main/README.md

Specification

https://wicg.github.io/nav-speculation/prerendering.html

Design docs

https://docs.google.com/document/d/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing

Summary

Prerendering is “pre”-rendering, it’s about pre-loading and rendering a Web
page before the user actually navigates to it. The main goal of
prerendering is to make the next page navigation faster, or ideally nearly
instant.

Sites can tell the user agents about which pages the user may likely visit,
by asking to trigger a ‘prerendering’ for a particular URL (e.g. user is at
page A and will likely navigate to page B next). Once the prerender is
triggered, the browser pre-fetches the main resource, instantiates a hidden
page, and processes the main resource to fetch and process more
subresources.

We would like to ship same-origin speculation rules prerendering. With this
feature, Chrome will start prerendering high-confidence URL suggestions
provided by the page using speculation rules. During the prerendering
process, a page will process and construct the full DOM tree, including the
execution of scripts (this differs from the prefetching resources
using No-state
Prefetch
)

This prerendering affects how the prerendered pages are processed. The
website gets loaded before the navigation is committed, and the
side-effects are delayed until activation (the actual navigation to the
website was committed). The website can know that it is being prerendered
(document.prerendering) and when it was activated (prerenderingchange
event, performance.activationStart timing). These APIs have already been
approved by the previous intent-to-ship for Omnibox prerendering

.

Note that we are not shipping cross-origin speculation rules, which allows
a web page to prerender another page under a different domain (external
site). For details about our web exposed changes shipping plan, please
consult this doc: Interoperability Roadmap for Shipping Prerender2
Incrementally

.


Blink component

Internals>Preload>Prerender


TAG review

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

TAG review status

Closed

Risks
Interoperability and Compatibility

Compatibility

There are some use cases that will need to know whether a page is being
prerendered by the user agent or navigated by the user, e.g. Ads and
analytics are likely examples of this.

To solve this challenge, this feature exposes `document.prerendering` which
indicates if the page is prerendered or not. We understand that there’s
always a risk of sites, that would benefit from using this API, not
actually using it.

We believe that this risk is tractable because:

(1) triggering a prerender isn’t an entirely new behavior. E.g. Chrome used
to have a prerendering feature a long while ago
 triggered
by URLs entered in the navigation bar

(2) Similar behaviors are already present in other browsers, e.g. “Preload
Top Hit” feature in Safari

To give more flexibility to web authors (site owners) who want to implement
speculation rules, we are already including a header to network requests as
`Purpose: prefetch` so that origin servers can identify requests for
prerendered pages and decide how to handle them. A new header will be
included to provide a CORS safelist alternative using  `Sec-purpose:
prefetch;prerender`
https://fetch.spec.whatwg.org/#cors-safelisted-request-header

https://chromestatus.com/feature/6247959677108224

There’s also a future risk of the speculation rules specification changing
:
including new rules, modifying previous ones, etc. We do not expect to make
backward-incompatible changes to the speculation rules format, but if we
did, the user agent wouldn’t be able to understand the rules (which would
define them as null), opting out of the prerender which wouldn’t cause any
visible effect (apart from a slower loading time for the next navigated
page as it won’t be prerendered).

We are working closely on the tracker
https://github.com/WICG/nav-speculation/issues which contains currently 8
non-blocking open discussions related with compatibility (1 of them
covering cross-origin which we are not shipping with this I2S)

Interoperability

We believe that some browsers already have prerendering 

Re: [blink-dev] Intend to extend experiment: User-Agent Reduction

[Chris Harrelson]

LGTM

On Mon, Apr 18, 2022 at 2:51 PM Ali Beyad  wrote:

> Note: please see the “Experiment Timeline” section for our extension
> request - the rest of the details are the same as before.
>
> Contact emails
>
> abe...@chromium.org, miketa...@chromium.org
> Original I2E
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/R0xKm1B7qoQ/
>
> Explainer
>
> https://developer.chrome.com/blog/user-agent-reduction-origin-trial/
>
> Specification
>
> None, but we intend to specify the reduced UA in
> https://compat.spec.whatwg.org/#ua-string-section as it ships.
>
> Summary
>
> We want to reduce the amount of information the User Agent string exposes
> in HTTP requests as well as in navigator.userAgent, navigator.appVersion,
> and navigator.platform. The browser's brand and significant version, its
> desktop/mobile distinction and the platform it is running on will continue
> to be sent.
>
> We would like to run an Origin Trial for sites to opt into the Reduced
> User-Agent (and related navigator properties) to proactively test for
> breakage. See below for more details.
>
> Design Doc
>
>
> https://docs.google.com/document/d/1feIxK9S7oNgT2oGGebbxE9X0O-4wTKcsP_gRaY99tq4/edit#heading=h.2navvbygwxwb
>
>
> Blink component
>
> Blink 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/640
>
> TAG review status
>
> Closed as “Satisfied with concerns” (
> https://github.com/w3ctag/design-reviews/issues/640)
>
> Risks: Interoperability and Compatibility
>
> The compatibility risk is low, as we’re planning to reduce the amount of
> information in the UA string, rather than remove the header. Most existing
> UA detection code should continue to work. It is only future UA detection
> code that will need to move to use the UA client hints instead. In the long
> term, we expect this change to improve compatibility, as UA detection based
> on UA-CH is bound to be more reliable than the current status quo. We hope
> this Origin Trial will help us flesh out site compat issues we can’t
> predict a priori.
>
> As for interoperability, other vendors are on board with UA information
> reduction, but not necessarily with the UA Client Hints mechanism that is
> supposed to replace it. That can create a tricky situation, where
> developers would need to rely on the User-Agent string for some browsers
> and on UA-CH for others.
>
> Edge: Positive signals (
> https://twitter.com/_scottlow/status/1206831008261132289)
>
> Firefox: Public support for reducing UA string information - “freezing the
> User Agent string without any client hints—seems worth-prototyping” (from
> https://github.com/mozilla/standards-positions/issues/202#issuecomment-558294095
> )
>
> Safari: Shipped to some extent. Safari has attempted to completely freeze
> the UA string
>  in the
> past, but somewhat reverted that decision
> . Nowadays, their UA
> string seems mostly frozen, with updates only to the browser version.
>
> Web developers: Mixed signals. Some positive comments on Twitter,
> blink-dev, etc., as well as some negative sentiment.
>
> Experiment Summary
>
> This experiment is going to be a bit different from a normal Origin Trial;
> the goal is less about gathering information on the design of a new API
> than it is about enabling developers and administrators to test and ensure
> compatibility with our proposed changes. This change represents a large
> compat challenge with very subtle pitfalls and vast dependencies, it’s
> incredibly important we give developers any opportunity to test systems at
> every level.
>
> As for engaging with the trial itself, there will be two components
> controlled by the same Origin Trial:
>
>1.
>
>Reducing the information in the associated JS getters, if the Origin
>Trial is enabled.
>2.
>
>A client hint that gets set when the Origin Trial is enabled, where
>the client hint indicates to the origin that the User-Agent request header
>contains the reduced value. Because of the experimental nature of this
>client hint, a valid Origin Trial token must be sent in the response header
>by the origin for the client hint to take effect or be stored (in order to
>prevent platform burn-in for this temporary client hint token).
>
>
> During the process of conducting the Origin Trial, we may find that we
> need to request an exception to the per-site (and possibly global) limits
> imposed by Origin Trials. In practice, Origin Trials rarely exceed their
> quota limits, but if necessary, there is time between when the limits have
> been exceeded and the Origin Trial is turned off, where we can work with
> the users on reducing their usage and/or lifting the limits.
>
> Please see the design document
> 

Re: [blink-dev] Request for Guidance

['Ajay Rahatekar' via blink-dev]

Ty Jeremy and Chris for the great responses and guidance. Much appreciated.

-Ajay

On Thu, Apr 21, 2022 at 5:01 PM Chris Harrelson 
wrote:

> Hi Ajay,
>
> Every new web-exposed feature, even if it's a small addition to an
> existing API, needs an intent to ship. This helps us make sure that all new
> features are tracked and understood by the community, and have the right
> level of open standards engagement, consensus and so on. Also, it happens
> surprisingly often that a feature that looks very simple ends up being more
> complicated than it looks, and the intent is one way to find out those
> complications before shipping so we can address them.
>
> If you consider this a very simple feature add-on, I recommend re-using
> the existing TAG review with a new comment on it, and also comments on the
> existing signals to other vendors from the prior intent. If you choose to
> do that, the API owners will in their review let you know if for some
> reason we feel it's a good idea to open an new TAG review or take some
> other step.
>
> Thanks,
> Chris
>
> On Thu, Apr 21, 2022 at 3:32 PM Jeremy Roman  wrote:
>
>> I'm not an API owner, but since it's shipped already I would suggest you
>> just do an Intent to Prototype & Ship. If it's a relatively small feature
>> then hopefully it will also be relatively quick for API owners to review.
>>
>> On Thu, Apr 21, 2022 at 5:34 PM 'Ajay Rahatekar' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Hello blink-dev owners,
>>>
>>> The Chrome team is planning on implementing screen labels defined in the
>>> draft spec for Multi-Screen Window Placement
>>> . The tracking
>>> bug for the implementation is here
>>> . Can
>>> you please advise if we need an Intent email for shipping the
>>> implementation? The Multi-Screen Window Placement API shipped
>>>  in Chrome M100.
>>>
>>> Please excuse and guide if this is not the appropriate forum for this
>>> request.
>>>
>>> Thanks in advance.
>>>
>>>
>>> --
>>> Ajay Rahatekar | Technical Program Manager | ajayrahate...@google.com |
>>> 650-797-1279 <(650)%20650-797-1279>
>>>
>>> --
>>> 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/CAHB%2BDAhiEjBpHNF00toJvZR%2Bm3qfVEm3iyq%3DFGVO2Tj7AQ2PNA%40mail.gmail.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+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13d2qfBzbJjWOrHFRjQHegqc-Fk%3Dp_kuTFVq4ygUAOJpmA%40mail.gmail.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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHB%2BDAgTpjms2a0jJ%3DAHyBP5rtqa8E-jWhmOtGU1rdy_ciFZ%2Bg%40mail.gmail.com.