Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Yoav Weiss]

On Thu, Sep 1, 2022 at 8:24 AM Takashi Toyoshima 
wrote:

> Thank you for the feedback.
>
> Yes, the Extensions is the thing we have paid the biggest attention to
> support Prerendering on Desktop.
>
> https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
> This is the document we discussed especially on Prerendering and
> Extensions. In the design discussion we tried finding the best choice to
> minimize possible compatibility breakage for most Extensions, but at the
> same time, we understood it's unavoidable that some Extensions may be
> surprised to see unexpected prerendering pages.
>
> So, our prepared mitigations are
> - Enterprise Policy to disable Prerendering completely
> - Users' report based incompatible Chrome Extensions list that disables
> Prerendering when a user installs one in the list.
>

That sounds reasonable, but I wonder if more communication to the
extensions community is warranted.

+Simeon Vincent  for thoughts


>
> It minimizes the risk to block the rollout for such unexpected Extensions
> compatibility breakages.
>
> For more visibility, here is the crbug entry to report such incompatible
> Extensions quickly.
> https://bugs.chromium.org/p/chromium/issues/detail?id=1351312
>
> 
> T hanks!
>
> On Thu, Sep 1, 2022 at 6:20 AM Daniel Bratell  wrote:
>
>> In addition to the LGTM, I want to point out that during our discussion
>> among the API Owners, we did specifically wonder about extension
>> compatibility. Since this will change things for extensions, I think it
>> will be important to look for compatibility problems popping up, and, if
>> necessary, delay until any such problems are fully understood.
>>
>> /Daniel
>> On 2022-08-31 16:34, Daniel Bratell wrote:
>>
>> LGTM3
>>
>> /Daniel
>> On 2022-08-30 10:58, Yoav Weiss wrote:
>>
>> LGTM2 to expand support for desktop.
>>
>> On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent  wrote:
>>
>>> LGTM1.
>>> It's pretty safe to expand support to desktop platforms, and it
>>> seems there are no negative signals.
>>>
>>> On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emails

 toyos...@chromium.org, angelrapo...@google.com

 Explainer

 This I2S aims to expand our efforts on Prerender2 (currently shipped
 only on Android) to Desktop.

 The full prerendering revamped explainer can be found at

 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/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs

 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 inform the user agent 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.

 After shipping Prerender2 for Android (I2S speculation rules triggered
 Prerender2
 
 and I2S for Omnibox triggered Prerender2
 ),
 we are now requesting approval to ship Prerender2 for Desktop. This release
 will enable the same triggers (speculation rules and Omnibox) for Desktop.

 With this feature, Chrome (Desktop) will start prerendering
 high-confidence URL suggestions provided by the page using speculation
 rules or directly by Omnibox. During the prerendering process, a page will
 process and construct the full DOM tree, including the execution of scripts
 (this differs from No-state Prefetch
 
 which only prefetches resources and doesn’t execute scripts).

 Note that we are not shipping cross-origin prerendering, which allows a
 web page to prerender another page on a different origin.


 Blink component

 Internals>Preload>Prerender
 

 TAG review

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

 TAG review status

 All issues have been addressed.

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Takashi Toyoshima]

Thank you for the feedback.

Yes, the Extensions is the thing we have paid the biggest attention to
support Prerendering on Desktop.
https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
This is the document we discussed especially on Prerendering and
Extensions. In the design discussion we tried finding the best choice to
minimize possible compatibility breakage for most Extensions, but at the
same time, we understood it's unavoidable that some Extensions may be
surprised to see unexpected prerendering pages.

So, our prepared mitigations are
- Enterprise Policy to disable Prerendering completely
- Users' report based incompatible Chrome Extensions list that disables
Prerendering when a user installs one in the list.

It minimizes the risk to block the rollout for such unexpected Extensions
compatibility breakages.

For more visibility, here is the crbug entry to report such incompatible
Extensions quickly.
https://bugs.chromium.org/p/chromium/issues/detail?id=1351312


T hanks!

On Thu, Sep 1, 2022 at 6:20 AM Daniel Bratell  wrote:

> In addition to the LGTM, I want to point out that during our discussion
> among the API Owners, we did specifically wonder about extension
> compatibility. Since this will change things for extensions, I think it
> will be important to look for compatibility problems popping up, and, if
> necessary, delay until any such problems are fully understood.
>
> /Daniel
> On 2022-08-31 16:34, Daniel Bratell wrote:
>
> LGTM3
>
> /Daniel
> On 2022-08-30 10:58, Yoav Weiss wrote:
>
> LGTM2 to expand support for desktop.
>
> On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent  wrote:
>
>> LGTM1.
>> It's pretty safe to expand support to desktop platforms, and it
>> seems there are no negative signals.
>>
>> On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> toyos...@chromium.org, angelrapo...@google.com
>>>
>>> Explainer
>>>
>>> This I2S aims to expand our efforts on Prerender2 (currently shipped
>>> only on Android) to Desktop.
>>>
>>> The full prerendering revamped explainer can be found at
>>>
>>> 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/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>>>
>>> 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 inform the user agent 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.
>>>
>>> After shipping Prerender2 for Android (I2S speculation rules triggered
>>> Prerender2
>>> 
>>> and I2S for Omnibox triggered Prerender2
>>> ),
>>> we are now requesting approval to ship Prerender2 for Desktop. This release
>>> will enable the same triggers (speculation rules and Omnibox) for Desktop.
>>>
>>> With this feature, Chrome (Desktop) will start prerendering
>>> high-confidence URL suggestions provided by the page using speculation
>>> rules or directly by Omnibox. During the prerendering process, a page will
>>> process and construct the full DOM tree, including the execution of scripts
>>> (this differs from No-state Prefetch
>>> 
>>> which only prefetches resources and doesn’t execute scripts).
>>>
>>> Note that we are not shipping cross-origin prerendering, which allows a
>>> web page to prerender another page on a different origin.
>>>
>>>
>>> Blink component
>>>
>>> Internals>Preload>Prerender
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/667
>>>
>>> TAG review status
>>>
>>> All issues have been addressed.
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risk: this feature is focused on enabling Prerender on
>>> Desktop, which is already launched and available for Android.
>>>
>>> We believe that some browsers already have prerendering implementations
>>> which are not specified and may differ from eac

Re: [blink-dev] Intent to Ship: AudioContext.setSinkId()

['Ajay Rahatekar' via blink-dev]

We have filed requests for position. Please see below:

Mozilla: https://github.com/mozilla/standards-positions/issues/683
Webkit: https://github.com/WebKit/standards-positions/issues/53

On Wed, Aug 31, 2022 at 8:54 AM Chris Harrelson 
wrote:

> Thanks for filing the TAG review. Could you also file for official
> positions from Mozilla and Webkit also? Thanks. I'm sure you're right about
> Mozilla, but they've requested going through the process in the past for
> other intents.
>
> On Wed, Aug 31, 2022 at 8:08 AM Hongchan Choi 
> wrote:
>
>> 1. Yes. The lack of implementation is one issue, but the relationship
>> between selectAudioOutput() and Web Audio API is not really specified or
>> documented.
>> 2. Since AudioElement.setSinkId() has been used for years, we believe it
>> makes more sense to use the same pattern for its low-level counterpart -
>> Web Audio API's AudioContext. This approach is more specific and focused.
>>
>>
>> On Tue, Aug 30, 2022 at 10:46 PM Philipp Hancke <
>> philipp.han...@googlemail.com> wrote:
>>
>>> the ID of the sink needs to be obtained from
>>> navigator.mediaDevices.enumerateDevices because
>>> https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/selectAudioOutput
>>> is not implemented anywhere?
>>>
>>> Am Di., 30. Aug. 2022 um 19:02 Uhr schrieb 'Ajay Rahatekar' via
>>> blink-dev :
>>>
 Contact emails

 hongc...@chromium.org, alvi...@chromium.org, mjwil...@chromium.org

 Explainer

 None

 Specification

 https://github.com/WebAudio/web-audio-api/pull/2498

 Summary

 AudioContext.setSinkId sets the ID of the audio device to use for
 output. This allows the AudioElement to route audio to a connected output
 device of user's choosing.


 Blink component

 Blink>WebAudio
 

 TAG review

 This is a small API change within Web Audio API. The WG was advised
 that this is too small for the TAG review.

 TAG review status

 Not applicable

 Risks

 Interoperability and Compatibility

 Gecko: Positive (https://github.com/WebAudio/web-audio-api/issues/2400)
 Mozilla is co-developing the spec change.

 WebKit: No signal

 Web developers: Positive (
 https://github.com/WebAudio/web-audio-api/issues/2400) Many developers
 chimed in the spec issue and the implementation crbug entry (
 crbug.com/1216187). Also several partners expressed the need for this
 API. We have not seen any negative feedback on this.

 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?


 Debuggability

 This adds a new method to AudioContext; the WebIDL change will be
 addressed by the DevTools automatically.


 Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux, Chrome OS, Android, and Android WebView)?

 Yes

 This is a part of Web Audio API, which is available on all platforms.


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

 Yes. The WPT will be added for this feature.

 Flag name

 –enable-blink-features=AudioContextSetSinkId

 Requires code in //chrome?

 False

 Tracking bug

 https://crbug.com/1355977

 Launch bug

 https://crbug.com/1216187

 Estimated milestones

 108


 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/5190163462881280

 This intent message was generated by Chrome Platform Status
 .


 --
 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%2BDAj6AJ01%3DgXdUepU9Aejf6DOt2qmsK%3DUm%2BJSEDoVRMeyqw%40mail.gmail.com
 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Daniel Bratell]

In addition to the LGTM, I want to point out that during our discussion 
among the API Owners, we did specifically wonder about extension 
compatibility. Since this will change things for extensions, I think it 
will be important to look for compatibility problems popping up, and, if 
necessary, delay until any such problems are fully understood.


/Daniel

On 2022-08-31 16:34, Daniel Bratell wrote:


LGTM3

/Daniel

On 2022-08-30 10:58, Yoav Weiss wrote:

LGTM2 to expand support for desktop.

On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent  wrote:

LGTM1.
It's pretty safe to expand support to desktop platforms, and it
seems there are no negative signals.

On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev
 wrote:

Contact emails

toyos...@chromium.org, angelrapo...@google.com


Explainer

This I2S aims to expand our efforts on Prerender2 (currently
shipped only on Android) to Desktop.

The full prerendering revamped explainer can be found at

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/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs




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 inform the user agent 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.


After shipping Prerender2 for Android (I2S speculation rules
triggered Prerender2

and
I2S for Omnibox triggered Prerender2

),
we are now requesting approval to ship Prerender2 for
Desktop. This release will enable the same triggers
(speculation rules and Omnibox) for Desktop.


With this feature, Chrome (Desktop) will start prerendering
high-confidence URL suggestions provided by the page using
speculation rules or directly by Omnibox. During the
prerendering process, a page will process and construct the
full DOM tree, including the execution of scripts (this
differs from No-state Prefetch

which
only prefetches resources and doesn’t execute scripts).


Note that we are not shipping cross-origin prerendering,
which allows a web page to prerender another page on a
different origin.



Blink component

Internals>Preload>Prerender




TAG review

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


TAG review status

All issues have been addressed.


Risks



Interoperability and Compatibility

Interoperability risk: this feature is focused on enabling
Prerender on Desktop, which is already launched and available
for Android.


We believe that some browsers already have prerendering
implementations which are not specified and may differ from
each other, or not always exposed to the platform. Our vision
is to produce a specification that can help improve
interoperability. There is a risk that other browsers do not
converge on a prerendering standard but we hope that we’ll be
able to address legitimate concerns if any are raised by
interested parties.


Compatibility risk: this feature is focused on enabling
Prerender on Desktop, which is already launched and available
for Android. 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 which are supported by already launched
features such as `document.prerendering` which lets a page
know that it’s being prerend

Re: [blink-dev] Intent to Ship: WebXR Raw Camera Access

[Alex Cooper]

Thanks Everyone! I've gone ahead and merged PR15 and Piotr will work on the
change to enable this!

On Wed, Aug 31, 2022 at 7:03 AM Yoav Weiss  wrote:

> LGTM3
>
> On Fri, Aug 26, 2022 at 3:13 PM Mike Taylor 
> wrote:
>
>> LGTM2 - thanks for improving the explainer in
>> https://github.com/immersive-web/raw-camera-access/pull/15/files.
>>
>> On 8/24/22 6:25 PM, Chris Harrelson wrote:
>>
>> LGTM1 to ship. In my view, the revised explainer is enough, and the
>> feature received a thorough going-over with the TAG.
>>
>> Side note: I greatly appreciate the team's responsiveness in discussions
>> with the TAG and in this thread.
>>
>> On Wed, Aug 24, 2022 at 8:55 AM Alex Russell 
>> wrote:
>>
>>> Hey Alex,
>>>
>>> I'd like to approve this ASAP, but the explainer is still lacking
>>> critical detail about considered alternatives and some aspects of how the
>>> design is going to stay in sync with the options that are available for
>>> getUserMedia().
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Tuesday, August 23, 2022 at 1:11:35 PM UTC-7 Alexander Cooper wrote:
>>>
 Thanks Alex,

 I believe I've responded to all of your questions on the github thread,
 but I still had a few follow up clarifications. We'd been hoping to get
 this out in M106, but since that has already branched I definitely want to
 make sure we can get this out in M107.

 Thanks,
 Alex Cooper

 On Fri, Aug 12, 2022 at 4:49 PM slightlyoff via Chromestatus <
 admin+slightly...@cr-status.appspotmail.com> wrote:

> I've left some questions about the design in an issue here:
> https://github.com/immersive-web/raw-camera-access/issues/14
>
 --
> 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/31066705e613ef2f%40google.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/6810925e-7d33-45f2-bc12-13563340101fn%40chromium.org
>>> 
>>> .
>>>
>> --
>> 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/CAOMQ%2Bw8dRgwg%3D%3D8mDkapu6AEyxyxTkK5ciDa4-94YvB3HBNaqA%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/7ae81c1d-db41-d3cc-09bf-6bc9bd4b1cdf%40chromium.org
>> 
>> .
>>
>

-- 
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/CAGOLbz1vpxiP%3Dj3ceSFNcq%3DEg6tAWYNsteue%3DQbHPvz%2BZHqMcw%40mail.gmail.com.

Re: [blink-dev] What are the criteria for passing the blink tests on LUCI

[Xianzhu Wang]

(I thought I had answered the question in another thread, but I just found
it's still in my Draft box. Sorry.)

For now we do have many blin_web_tests and blink_wpt_tests that don't pass.
A few are expected not to pass, e.g. harness-tests/crash.html. Most of them
are due to bugs. When a test starts to fail, and we can't find the culprit
change to revert or fix the failure immediately, we file a bug and add an
entry in TestExpectations

to
suppress the failure. Now these "expected failures" cause loss of several
percent of loss of test coverage. We are constantly fixing them to recover
test coverage.

On Wed, Aug 31, 2022 at 4:13 AM fang yiwei 
wrote:

> As we can see from the results.html, There are some failure cases. What
> kind of cases will not affect the passing criteria of the CI system。[image:
> 20220831190722.jpg]
>
> On Wednesday, August 31, 2022 at 12:17:54 AM UTC+8 Xianzhu Wang wrote:
>
>> You can see these tests in results.html
>> 
>>  by
>> clicking "Unexpected Flaky". The link to the results.html is available
>> under the "archive results for blink_web_tests" (or "archive results for
>> blink_wpt_tests") step.
>>
>> On Tue, Aug 30, 2022 at 9:14 AM Xianzhu Wang 
>> wrote:
>>
>>> The tests are unexpected flakes, i.e. they failed in the first round for
>>> various reasons, and succeeded in retry.
>>>
>>> For now we don't report them as errors, but collect the flaky data and
>>> try to fix highly flaky tests.
>>>
>>> On Tue, Aug 30, 2022 at 9:05 AM fang yiwei  wrote:
>>>
  Form luci platform
 ,
 blink_web_tests also run on Ubuntu-18.04, and some test cases also didn't
 run as expected, however the test step is judged to be passed. What are the
 criteria for the CI system to judge whether the test step pass or not.
 [image: 20220830210239.jpg]

 --
 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/aafa4b0f-fa81-4bf1-aa6b-f3ee7bbbe84cn%40chromium.org
 
 .

>>>

-- 
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/CADBxric2Wpx2k3q0Ub3oBbffU6sCqPt7vAqwsu2AH7zvAScTHg%40mail.gmail.com.

[blink-dev] Intent to Prototype: PerformanceResourceTiming.deliveryType

[Jeremy Roman]

Contact emailsjbro...@chromium.org

Explainerhttps://github.com/w3c/resource-timing/issues/332

Specificationhttps://github.com/w3c/resource-timing/pull/343

(This is a pull request pending further discussion in the Web Perf WG and
the authoring of suitable web platform tests.)

Summary

Expose information about how a resource was delivered. For example,
resources which were delivered from the cache (currently exposed through
transferSize) and navigations which were prefetched by the previous page
are useful to identify.

Blink componentBlink>PerformanceAPIs>ResourceTiming


Motivation

This provides a way for navigational prefetch to be detected by authors,
and additionally provides a more natural way to mark resources served from
the HTTP cache. Potentially also useful for marking resources served from
the preload (as in ) cache.

Initial public proposalhttps://github.com/w3c/resource-timing/issues/332

TAG reviewnone yet

TAG review statusPending

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?



Debuggability

Existing developer tools adequately cover the addition of a property.

Is this feature fully tested by web-platform-tests

?No, but WPT will be written alongside the implementation.

Flag nameNot landed yet, but likely "PerformanceResourceTimingDeliveryType".

Requires code in //chrome?False

Estimated milestones

No milestones specified


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

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/CACuR13cZU8%3D7Ka3SWSf4E2dgDuhRRBRt_fGgDeC6d%3DqHP%3Durrw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: tech() function support in @font-face src: descriptor

[Alex Russell]

We discussed this at today's API OWNERs meeting and, while I realise I 
should perhaps be directing most of these comments at the CSS WG more 
broadly, I'm concerned that the bundle of features that this function is 
designed to support are not clearly articulated, which argues for an 
explainer and perhaps a TAG review.

Specifically:


   - What problems do the "variations", "palettes", and "incremental" 
   values address? There should be clear enunciation of those issues in an 
   explainer, a discussion of considered alternatives, and example code 
   describing how this specfic design best meets those needs.
   - Related, why is "tech()" overloaded for whatever those values do as 
   well as explict named technologies and sub-features?
   - Since we're going first, and the only group that seems to have looked 
   at this is the CSS WG, shouldn't there be a TAG review?

The CSS WG continues to work outside of our incubation and explainer-based 
model for feature development, and as a general matter it's not OK.

I realise this feature is hostage to a bad work mode and it isn't the 
developer's of this syntax's fault, but we need to break the cycle.

Future CSS features that do not incubate, center developer feedback 
(perhaps through OT), and show signs of incubation may also invoke delays 
from me.

Regards,

Alex

On Wednesday, August 31, 2022 at 8:52:02 AM UTC-7 Philip Jägenstedt wrote:

> On Wed, Aug 31, 2022 at 4:11 PM Yoav Weiss  wrote:
>
>>
>>
>> On Monday, August 29, 2022 at 3:09:39 PM UTC+2 Dominik Röttsches wrote:
>>
>>> (re-sent from @chromium.org address)
>>>
>>> Contact emailsdr...@chromium.org
>>>
>>> ExplainerNone
>>>
>>
>> I think that a short explainer outlining exactly what you're planning to 
>> ship here and how you're expecting developers to use it would be helpful. 
>> Can you add one? (potentially even inline, if it's rather short)
>>
>
> Perhaps a small edit to 
> https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md 
> to say what this is for and give an example?
>
> Some text from https://drafts.csswg.org/css-fonts-4/#ex-color-if-supported 
> could be lifted. Spelling out what the different keywords in tech(keyword) 
> do in plain language would be helpful.
>

-- 
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/2379eaed-4592-4920-9424-f88ea7026fd4n%40chromium.org.

Re: [blink-dev] Intent to Ship: AudioContext.setSinkId()

[Chris Harrelson]

Thanks for filing the TAG review. Could you also file for official
positions from Mozilla and Webkit also? Thanks. I'm sure you're right about
Mozilla, but they've requested going through the process in the past for
other intents.

On Wed, Aug 31, 2022 at 8:08 AM Hongchan Choi  wrote:

> 1. Yes. The lack of implementation is one issue, but the relationship
> between selectAudioOutput() and Web Audio API is not really specified or
> documented.
> 2. Since AudioElement.setSinkId() has been used for years, we believe it
> makes more sense to use the same pattern for its low-level counterpart -
> Web Audio API's AudioContext. This approach is more specific and focused.
>
>
> On Tue, Aug 30, 2022 at 10:46 PM Philipp Hancke <
> philipp.han...@googlemail.com> wrote:
>
>> the ID of the sink needs to be obtained from
>> navigator.mediaDevices.enumerateDevices because
>> https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/selectAudioOutput
>> is not implemented anywhere?
>>
>> Am Di., 30. Aug. 2022 um 19:02 Uhr schrieb 'Ajay Rahatekar' via blink-dev
>> :
>>
>>> Contact emails
>>>
>>> hongc...@chromium.org, alvi...@chromium.org, mjwil...@chromium.org
>>>
>>> Explainer
>>>
>>> None
>>>
>>> Specification
>>>
>>> https://github.com/WebAudio/web-audio-api/pull/2498
>>>
>>> Summary
>>>
>>> AudioContext.setSinkId sets the ID of the audio device to use for
>>> output. This allows the AudioElement to route audio to a connected output
>>> device of user's choosing.
>>>
>>>
>>> Blink component
>>>
>>> Blink>WebAudio
>>> 
>>>
>>> TAG review
>>>
>>> This is a small API change within Web Audio API. The WG was advised that
>>> this is too small for the TAG review.
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Gecko: Positive (https://github.com/WebAudio/web-audio-api/issues/2400)
>>> Mozilla is co-developing the spec change.
>>>
>>> WebKit: No signal
>>>
>>> Web developers: Positive (
>>> https://github.com/WebAudio/web-audio-api/issues/2400) Many developers
>>> chimed in the spec issue and the implementation crbug entry (
>>> crbug.com/1216187). Also several partners expressed the need for this
>>> API. We have not seen any negative feedback on this.
>>>
>>> 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?
>>>
>>>
>>> Debuggability
>>>
>>> This adds a new method to AudioContext; the WebIDL change will be
>>> addressed by the DevTools automatically.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> Yes
>>>
>>> This is a part of Web Audio API, which is available on all platforms.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes. The WPT will be added for this feature.
>>>
>>> Flag name
>>>
>>> –enable-blink-features=AudioContextSetSinkId
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1355977
>>>
>>> Launch bug
>>>
>>> https://crbug.com/1216187
>>>
>>> Estimated milestones
>>>
>>> 108
>>>
>>>
>>> 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/5190163462881280
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>>
>>> --
>>> 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%2BDAj6AJ01%3DgXdUepU9Aejf6DOt2qmsK%3DUm%2BJSEDoVRMeyqw%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

Re: [blink-dev] Re: Intent to Ship: tech() function support in @font-face src: descriptor

[Philip Jägenstedt]

On Wed, Aug 31, 2022 at 4:11 PM Yoav Weiss  wrote:

>
>
> On Monday, August 29, 2022 at 3:09:39 PM UTC+2 Dominik Röttsches wrote:
>
>> (re-sent from @chromium.org address)
>>
>> Contact emailsdr...@chromium.org
>>
>> ExplainerNone
>>
>
> I think that a short explainer outlining exactly what you're planning to
> ship here and how you're expecting developers to use it would be helpful.
> Can you add one? (potentially even inline, if it's rather short)
>

Perhaps a small edit to
https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md
to say what this is for and give an example?

Some text from https://drafts.csswg.org/css-fonts-4/#ex-color-if-supported
could be lifted. Spelling out what the different keywords in tech(keyword)
do in plain language would be helpful.

-- 
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/CAARdPYewZjZnbWp9u89rSwzbr%2BCxFeoGVbgKOAC65K5cqy0xKg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: ContentVisibilityAutoStateChanged event

[Philip Jägenstedt]

LGTM3 on the assumption that the spec discussion will be sorted out and
spec fixed by the time this rolls out to stable.

On Wed, Aug 31, 2022 at 3:47 PM Yoav Weiss  wrote:

> LGTM2 conditional on driving the discussion on the Mozilla position thread
> to completion and making sure the spec text properly reflects it.
>
> On Thu, Aug 11, 2022 at 12:48 AM slightlyoff via Chromestatus <
> admin+slightly...@cr-status.appspotmail.com> wrote:
>
>> LGTM1
>>
>> --
>> 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/5788c005e5ead850%40google.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/CAL5BFfU%3DV6M7KXYdwwWm_RFyzH7APA8pymm3_eno3ep7SCNgCg%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/CAARdPYfUH%2B2XfktP%2BzOPyL5Q6CMP82Q4dTPG6BqHuDWbTTkHxQ%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Align Timers (including DOM timers) at 125 Hz

[Chris Harrelson]

LGTM to roll out the "optimistic shipping" plan up to beta. Then please
come back to this thread for final shipping approval.

On Wed, Aug 24, 2022 at 1:38 PM Chris Harrelson 
wrote:

>
>
> On Wed, Aug 24, 2022 at 1:35 PM Etienne Pierre-doray <
> etien...@chromium.org> wrote:
>
>> Ok. So your experiment is not an OT, but rather asking permission for an
>>> A/B (finch) experiment on those channels?
>>>
>> Correct, I very recently discovered the difference between finch and OT;
>> sorry for the confusion.
>>
>> This plan is designed to avoid the not-reproducible-bug issue, and also
>>> satisfy the need for us to test what is actually shipping on the beta
>>> channel.
>>>
>> That sounds like a reasonable plan.
>> Is it still ok to run 1% experiment on M105 stable meanwhile.
>> Per yoavweiss@ previous response, this is mostly aimed at evaluating
>> performance/power benefits.
>>
>
> I think that's fine.
>
>
>>
>> On Wed, Aug 24, 2022 at 3:16 PM Chelbi Owre  wrote:
>>
>>> Fuck off
>>>
>>> On Wed, Aug 24, 2022 at 12:15 PM Chris Harrelson 
>>> wrote:
>>>


 On Thu, Aug 11, 2022 at 8:48 AM Etienne Pierre-doray <
 etien...@chromium.org> wrote:

> Hi Blink API Owners,
> Thanks for taking the time to look into this feature.
>
>
>> Do I understand correctly that you're asking for experimentation only
>> in the 105?
>>
> This is correct. Although I imagined the following rollout plan, with
> a separate I2S once I gathered data on Stable:
> - (previously) 50% on canary/dev/beta M103/M104
> - 50% canary/dev/beta + 1% Stable on M105
> - 100% Stable on M106
>

 Ok. So your experiment is not an OT, but rather asking permission for
 an A/B (finch) experiment on those channels?


>
>  won't necessarily expose compat issues for sites that don't pay very
>> close attention (as it's easy to dismiss bugs in 1% of users as flakes).
>>
> What would be a suitable roll-out plan to expose compat issues? In
> similar performance interventions (e.g. Intensive throttling
> ),
> origin trial (on 50% Beta and 1% Stable) was able to surface issues and
> provide necessary feedback for launch to be LGTM-ed.
>

 We discussed this intent at the API owners meeting today. 50% beta may
 not yield the feedback you want, because developers or users may conclude
 that an apparent breakage is a non-reproducible bug because it only
 reproduces some of the time or on some computers. To correct for this, and
 given you hope to ship it in one release, I suggest an "optimistic
 shipping" strategy:

 1. Turn on (via finch) for canary/dev at 100% for canary / dev version N
 2. Continue to beta at 100% for version N assuming no bugs reported in
 step 1
 3. After 2.5 weeks at beta with no bugs reported, send an I2S to
 blink-dev, which we'd approve assuming no issues were reported
 4a. Assuming 3 succeeds, proceed to 100% stable when N ships
 4b. Assuming it fails, turn off the experiment in beta. This will still
 leave 1.5 weeks of testing without the change as part of the normal release
 cycle

 This plan is designed to avoid the not-reproducible-bug issue, and also
 satisfy the need for us to test what is actually shipping on the beta
 channel.

 At present N would be 107.


>
>
> On Thu, Aug 11, 2022 at 5:16 AM Yoav Weiss 
> wrote:
>
>> Do I understand correctly that you're asking for experimentation only
>> in the 105?
>>
>> We discussed this intent at the API owners meeting yesterday (Daniel,
>> Rego, MikeT and myself), and reached a conclusion that there are two 
>> goals
>> for this experiment, but only one of them can be achieved with 1% stable
>> experimentation.
>> We believe the experiment can show the potential benefits of such a
>> behavior change, but won't necessarily expose compat issues for sites 
>> that
>> don't pay very close attention (as it's easy to dismiss bugs in 1% of 
>> users
>> as flakes).
>> Hence, we think it's fine to run the experiment in order to figure
>> out the potential benefits, but would need a more elaborate plan to 
>> figure
>> out the compat implications and feasibility of shipping this.
>>
>> Does that make sense?
>>
>> On Fri, Aug 5, 2022 at 8:17 PM Stefan Zager 
>> wrote:
>>
>>> On Fri, Aug 5, 2022 at 11:00 AM Dave Tapuska 
>>> wrote:
>>>
 Stefan, this was just for "non-zero delay" timers? Are there still
 potential issues there?

>>>
>>> Ah, sorry, I missed that detail. In that case, I think none of my
>>> objections apply.
>>>
>>>

 On Fri, Aug 5, 2022 at 1:19 PM Stefan Zager 
 wrote:

> This i

Re: [blink-dev] Intent to Ship: AudioContext.setSinkId()

[Hongchan Choi]

1. Yes. The lack of implementation is one issue, but the relationship
between selectAudioOutput() and Web Audio API is not really specified or
documented.
2. Since AudioElement.setSinkId() has been used for years, we believe it
makes more sense to use the same pattern for its low-level counterpart -
Web Audio API's AudioContext. This approach is more specific and focused.


On Tue, Aug 30, 2022 at 10:46 PM Philipp Hancke <
philipp.han...@googlemail.com> wrote:

> the ID of the sink needs to be obtained from
> navigator.mediaDevices.enumerateDevices because
> https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/selectAudioOutput
> is not implemented anywhere?
>
> Am Di., 30. Aug. 2022 um 19:02 Uhr schrieb 'Ajay Rahatekar' via blink-dev <
> blink-dev@chromium.org>:
>
>> Contact emails
>>
>> hongc...@chromium.org, alvi...@chromium.org, mjwil...@chromium.org
>>
>> Explainer
>>
>> None
>>
>> Specification
>>
>> https://github.com/WebAudio/web-audio-api/pull/2498
>>
>> Summary
>>
>> AudioContext.setSinkId sets the ID of the audio device to use for output.
>> This allows the AudioElement to route audio to a connected output device of
>> user's choosing.
>>
>>
>> Blink component
>>
>> Blink>WebAudio
>> 
>>
>> TAG review
>>
>> This is a small API change within Web Audio API. The WG was advised that
>> this is too small for the TAG review.
>>
>> TAG review status
>>
>> Not applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Gecko: Positive (https://github.com/WebAudio/web-audio-api/issues/2400)
>> Mozilla is co-developing the spec change.
>>
>> WebKit: No signal
>>
>> Web developers: Positive (
>> https://github.com/WebAudio/web-audio-api/issues/2400) Many developers
>> chimed in the spec issue and the implementation crbug entry (
>> crbug.com/1216187). Also several partners expressed the need for this
>> API. We have not seen any negative feedback on this.
>>
>> 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?
>>
>>
>> Debuggability
>>
>> This adds a new method to AudioContext; the WebIDL change will be
>> addressed by the DevTools automatically.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes
>>
>> This is a part of Web Audio API, which is available on all platforms.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes. The WPT will be added for this feature.
>>
>> Flag name
>>
>> –enable-blink-features=AudioContextSetSinkId
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://crbug.com/1355977
>>
>> Launch bug
>>
>> https://crbug.com/1216187
>>
>> Estimated milestones
>>
>> 108
>>
>>
>> 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/5190163462881280
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>>
>> --
>> 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%2BDAj6AJ01%3DgXdUepU9Aejf6DOt2qmsK%3DUm%2BJSEDoVRMeyqw%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/CAGJqXNuLuQ0mv%2BqRu2YxvP9iu_E%3DF2FdVe5Ewz%3DeB-yNokJtFA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: AudioContext.setSinkId()

[Hongchan Choi]

Re: Alex - we kicked off the TAG review:
https://github.com/w3ctag/design-reviews/issues/766


On Tue, Aug 30, 2022 at 12:19 PM Hongchan Choi 
wrote:

> Hi Alex,
>
> In one of our WG teleconferences, we verbally asked the W3C liaison (Chris
> Lilley) about the TAG review but I was told this might be "too small to
> initiate the review". I can certainly start the TAG review (or FYI) if
> that's necessary.
>
> Cheers,
> Hongchan
>
>
> On Tue, Aug 30, 2022 at 11:54 AM Alex Russell 
> wrote:
>
>> Doesn't this require at least consulting former TAG members before
>> asserting no review is required?
>>
>> For avoidance of delay, please at least file an FYI with the TAG.
>>
>> Regards,
>>
>> Alex
>>
>> On Tue, Aug 30, 2022, 11:46 AM 'Ajay Rahatekar' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Apologies, the tracking and launch bugs in the original email are
>>> interchanged. The correct details are:
>>>
>>> *Tracking bug*
>>>
>>> https://crbug.com/1216187
>>> *Launch bug*
>>>
>>> https://crbug.com/1355977
>>>
>>> On Tuesday, August 30, 2022 at 10:02:18 AM UTC-7 Ajay Rahatekar wrote:
>>>
 Contact emails

 hong...@chromium.org, alv...@chromium.org, mjwi...@chromium.org

 Explainer

 None

 Specification

 https://github.com/WebAudio/web-audio-api/pull/2498

 Summary

 AudioContext.setSinkId sets the ID of the audio device to use for
 output. This allows the AudioElement to route audio to a connected output
 device of user's choosing.


 Blink component

 Blink>WebAudio
 

 TAG review

 This is a small API change within Web Audio API. The WG was advised
 that this is too small for the TAG review.

 TAG review status

 Not applicable

 Risks

 Interoperability and Compatibility

 Gecko: Positive (https://github.com/WebAudio/web-audio-api/issues/2400)
 Mozilla is co-developing the spec change.

 WebKit: No signal

 Web developers: Positive (
 https://github.com/WebAudio/web-audio-api/issues/2400) Many developers
 chimed in the spec issue and the implementation crbug entry (
 crbug.com/1216187). Also several partners expressed the need for this
 API. We have not seen any negative feedback on this.

 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?


 Debuggability

 This adds a new method to AudioContext; the WebIDL change will be
 addressed by the DevTools automatically.


 Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux, Chrome OS, Android, and Android WebView)?

 Yes

 This is a part of Web Audio API, which is available on all platforms.


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

 Yes. The WPT will be added for this feature.

 Flag name

 –enable-blink-features=AudioContextSetSinkId

 Requires code in //chrome?

 False

 Tracking bug

 https://crbug.com/1355977

 Launch bug

 https://crbug.com/1216187

 Estimated milestones

 108


 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/5190163462881280

 This intent message was generated by Chrome Platform Status
 .


 --
 Ajay Rahatekar | Technical Program Manager | ajayra...@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/34425811-7d74-4b1d-ad7a-cddeb7a0aadcn%40chromium.org
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving 

Re: [blink-dev] Intent to Prototype & Ship: Wildcards in Permissions Policy Origins

[Ari Chivukula]

I'll add a note, but this is actually deliberate.

*.foo.com does not match foo.com.

~ Ari Chivukula (Their/There/They're)

On Wed, Aug 31, 2022, 10:19 ayumi hamasaki  wrote:

> The example in the description is a bit confusing found here:
> https://chromestatus.com/feature/5170361717489664
>
> Before, a permissions policy might need to look like:
>
> ```
> permissions-policy: ch-ua-platform-version=(self "https://foo.com"; "
> https://cdn1.foo.com"; "https://cdn2.foo.com";)
> ```
>
> With this feature, it could look like: permissions-policy:
>
> ```
> ch-ua-platform-version=(self "https://foo.com"; "https://*.foo.com";)
> ```
>
> One would think why not just write: `ch-ua-platform-version=(self "
> https://*.foo.com";)` instead. As you're used `foo.com` twice!
>
> 
>
> Would it not be better to use `foo.com` and `example.com` instead e.g.
>
> Before, a permissions policy might need to look like:
>
> ```
> permissions-policy: ch-ua-platform-version=(self "https://example.com
> " "https://cdn1.foo.com"; "https://cdn2.foo.com";)
> ```
>
> With this feature, it could look like: permissions-policy:
>
> ```
> ch-ua-platform-version=(self "https://example.com " "
> https://*.foo.com";)
> ```
>
> Which would make more sense.
>
>
> On Wednesday, 31 August 2022 at 15:10:31 UTC+1 ari...@chromium.org wrote:
>
>> Sorry about that:
>> https://github.com/mozilla/standards-positions/issues/679
>> https://github.com/WebKit/standards-positions/issues/51
>>
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>> On Wed, Aug 31, 2022, 10:06 Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Fri, Aug 26, 2022 at 7:27 PM Ari Chivukula 
>>> wrote:
>>>
 Contact emails

 ari...@chromium.org, mike...@chromium.org

 Design Doc


 https://docs.google.com/document/d/1HtkQivbjO6TiP6uZdTt4KmTnWzbs5IZpEdrz59-fyYU/edit

 Specification

 https://github.com/w3c/webappsec-permissions-policy/issues/479

 Summary

 This feature will add support for wildcard in permissions policy
 structured like SCHEME://*.HOST:PORT (e.g., https://*.foo.com/) where
 a valid Origin could be constructed from SCHEME://HOST:PORT (e.g.,
 https://foo.com/). This requires that HOST is at least eTLD+1 (a
 registrable domain). This means that https://*.bar.foo.com/ works but
 https://*.com/ won’t (if you want to allow all domains to use the
 feature, you should just delegate to *). Wildcards in the scheme and port
 section will be unsupported and https://*.foo.com/ does not delegate
 to https://foo.com/.

 Before, a permissions policy might need to look like:

 permissions-policy: ch-ua-platform-version=(self "https://foo.com"; "
 https://cdn1.foo.com"; "https://cdn2.foo.com";)

 With this feature, it could look like:

 permissions-policy: ch-ua-platform-version=(self "https://foo.com";
 "https://*.foo.com";)



 Blink component

 Blink>PermissionsAPI
 



 Motivation

 The Permissions Policy specification
  “defines a
 mechanism that allows developers to selectively enable and disable use of
 various browser features and APIs.” One capability of this mechanism allows
 features to be enabled only on explicitly enumerated origins (e.g.,
 https://foo.com/). This mechanism is not flexible enough for the
 design of some CDNs, which deliver content via an origin that might be
 hosted on one of several hundred possible subdomains.

 TAG review

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

 Compatibility

 Depending on their user base, sites may want to entertain a transition
 period for older Chromium clients, where they enumerate all subdomains and
 include the wildcard in the permissions policy.


 Interoperability

 We would be the first to implement if approved.



 Gecko: Will ask



 WebKit: Will ask

>>>
>>> Links to signal requests?
>>>
>>>


 Web developers:
 https://github.com/w3c/webappsec-permissions-policy/issues/479
 

 Debuggability

 Future work might flag syntax errors in the Issues tab
 
 .

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

 No, but it will be.

 Tracking bug

 https://crbug.com/1345994

 Link to entry on the Chrome Platform Status

 https://chromestatus.com/feature/5170361717489664

 ~ Ari Chivukula (Their/There/They're)

 --
 You received this message because you are subscribed to the Google
 Groups "b

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Daniel Bratell]

LGTM3

/Daniel

On 2022-08-30 10:58, Yoav Weiss wrote:

LGTM2 to expand support for desktop.

On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent  wrote:

LGTM1.
It's pretty safe to expand support to desktop platforms, and it
seems there are no negative signals.

On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev
 wrote:

Contact emails

toyos...@chromium.org, angelrapo...@google.com


Explainer

This I2S aims to expand our efforts on Prerender2 (currently
shipped only on Android) to Desktop.

The full prerendering revamped explainer can be found at

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/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs




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 inform the user agent 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.


After shipping Prerender2 for Android (I2S speculation rules
triggered Prerender2

and
I2S for Omnibox triggered Prerender2

),
we are now requesting approval to ship Prerender2 for Desktop.
This release will enable the same triggers (speculation rules
and Omnibox) for Desktop.


With this feature, Chrome (Desktop) will start prerendering
high-confidence URL suggestions provided by the page using
speculation rules or directly by Omnibox. During the
prerendering process, a page will process and construct the
full DOM tree, including the execution of scripts (this
differs from No-state Prefetch

which
only prefetches resources and doesn’t execute scripts).


Note that we are not shipping cross-origin prerendering, which
allows a web page to prerender another page on a different origin.



Blink component

Internals>Preload>Prerender




TAG review

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


TAG review status

All issues have been addressed.


Risks



Interoperability and Compatibility

Interoperability risk: this feature is focused on enabling
Prerender on Desktop, which is already launched and available
for Android.


We believe that some browsers already have prerendering
implementations which are not specified and may differ from
each other, or not always exposed to the platform. Our vision
is to produce a specification that can help improve
interoperability. There is a risk that other browsers do not
converge on a prerendering standard but we hope that we’ll be
able to address legitimate concerns if any are raised by
interested parties.


Compatibility risk: this feature is focused on enabling
Prerender on Desktop, which is already launched and available
for Android. 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 which are supported by already launched
features such as `document.prerendering` which lets a page
know that it’s being prerendered.


Chrome Extensions have abilities to interact with web contents
and have widely used API surfaces. We’ve been keeping in mind
compatibility with Extensions’ compatibility, including giving
enough capability for Extensions to properly support
Prerender2 [1].


A similar concern applies to (P)NaCl/PPAPI. However, these
plugins are on a deprecation p

Re: [blink-dev] Intent to Prototype & Ship: Wildcards in Permissions Policy Origins

[ayumi hamasaki]

The example in the description is a bit confusing found 
here: https://chromestatus.com/feature/5170361717489664

Before, a permissions policy might need to look like: 

```
permissions-policy: ch-ua-platform-version=(self "https://foo.com"; "
https://cdn1.foo.com"; "https://cdn2.foo.com";) 
```

With this feature, it could look like: permissions-policy: 

```
ch-ua-platform-version=(self "https://foo.com"; "https://*.foo.com";)
```

One would think why not just write: `ch-ua-platform-version=(self "
https://*.foo.com";)` instead. As you're used `foo.com` twice!



Would it not be better to use `foo.com` and `example.com` instead e.g.

Before, a permissions policy might need to look like: 

```
permissions-policy: ch-ua-platform-version=(self "https://example.com 
" "https://cdn1.foo.com"; "https://cdn2.foo.com";) 
```

With this feature, it could look like: permissions-policy: 

```
ch-ua-platform-version=(self "https://example.com " "
https://*.foo.com";)
```

Which would make more sense.


On Wednesday, 31 August 2022 at 15:10:31 UTC+1 ari...@chromium.org wrote:

> Sorry about that:
> https://github.com/mozilla/standards-positions/issues/679
> https://github.com/WebKit/standards-positions/issues/51
>
>
> ~ Ari Chivukula (Their/There/They're)
>
> On Wed, Aug 31, 2022, 10:06 Yoav Weiss  wrote:
>
>>
>>
>> On Fri, Aug 26, 2022 at 7:27 PM Ari Chivukula  
>> wrote:
>>
>>> Contact emails
>>>
>>> ari...@chromium.org, mike...@chromium.org
>>>
>>> Design Doc
>>>
>>>
>>> https://docs.google.com/document/d/1HtkQivbjO6TiP6uZdTt4KmTnWzbs5IZpEdrz59-fyYU/edit
>>>
>>> Specification
>>>
>>> https://github.com/w3c/webappsec-permissions-policy/issues/479
>>>
>>> Summary
>>>
>>> This feature will add support for wildcard in permissions policy 
>>> structured like SCHEME://*.HOST:PORT (e.g., https://*.foo.com/) where a 
>>> valid Origin could be constructed from SCHEME://HOST:PORT (e.g., 
>>> https://foo.com/). This requires that HOST is at least eTLD+1 (a 
>>> registrable domain). This means that https://*.bar.foo.com/ works but 
>>> https://*.com/ won’t (if you want to allow all domains to use the feature, 
>>> you should just delegate to *). Wildcards in the scheme and port section 
>>> will be unsupported and https://*.foo.com/ does not delegate to 
>>> https://foo.com/.
>>>
>>> Before, a permissions policy might need to look like:
>>>
>>> permissions-policy: ch-ua-platform-version=(self "https://foo.com"; "
>>> https://cdn1.foo.com"; "https://cdn2.foo.com";) 
>>>
>>> With this feature, it could look like:
>>>
>>> permissions-policy: ch-ua-platform-version=(self "https://foo.com"; 
>>> "https://*.foo.com";) 
>>>
>>>  
>>>
>>> Blink component
>>>
>>> Blink>PermissionsAPI 
>>> 
>>>
>>>  
>>>
>>> Motivation
>>>
>>> The Permissions Policy specification 
>>>  “defines a 
>>> mechanism that allows developers to selectively enable and disable use of 
>>> various browser features and APIs.” One capability of this mechanism allows 
>>> features to be enabled only on explicitly enumerated origins (e.g., 
>>> https://foo.com/). This mechanism is not flexible enough for the design 
>>> of some CDNs, which deliver content via an origin that might be hosted on 
>>> one of several hundred possible subdomains.
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/765
>>>
>>> Compatibility
>>>
>>> Depending on their user base, sites may want to entertain a transition 
>>> period for older Chromium clients, where they enumerate all subdomains and 
>>> include the wildcard in the permissions policy.
>>>
>>>  
>>> Interoperability
>>>
>>> We would be the first to implement if approved.
>>>
>>>  
>>>
>>> Gecko: Will ask
>>>
>>>  
>>>
>>> WebKit: Will ask
>>>
>>
>> Links to signal requests?
>>  
>>
>>>  
>>>
>>> Web developers: 
>>> https://github.com/w3c/webappsec-permissions-policy/issues/479 
>>> 
>>>
>>> Debuggability
>>>
>>> Future work might flag syntax errors in the Issues tab 
>>> 
>>> .
>>>
>>> Is this feature fully tested by web-platform-tests?
>>>
>>> No, but it will be.
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1345994
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5170361717489664
>>>
>>> ~ Ari Chivukula (Their/There/They're)
>>>
>>> -- 
>>> 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/CAGpy5DLDbhOMWugyzXTKsvjH6koO8g7sV7eg_NQgq0GZeCOQ1A%40mail.gmail.com
>>>  
>

Re: [blink-dev] What are the criteria for passing the blink tests on LUCI

[fang yiwei]

As we can see from the results.html, There are some failure cases. What 
kind of cases will not affect the passing criteria of the CI system。[image: 
20220831190722.jpg]

On Wednesday, August 31, 2022 at 12:17:54 AM UTC+8 Xianzhu Wang wrote:

> You can see these tests in results.html 
> 
>  by 
> clicking "Unexpected Flaky". The link to the results.html is available 
> under the "archive results for blink_web_tests" (or "archive results for 
> blink_wpt_tests") step.
>
> On Tue, Aug 30, 2022 at 9:14 AM Xianzhu Wang  
> wrote:
>
>> The tests are unexpected flakes, i.e. they failed in the first round for 
>> various reasons, and succeeded in retry.
>>
>> For now we don't report them as errors, but collect the flaky data and 
>> try to fix highly flaky tests.
>>
>> On Tue, Aug 30, 2022 at 9:05 AM fang yiwei  wrote:
>>
>>>  Form luci platform 
>>> ,
>>>  
>>> blink_web_tests also run on Ubuntu-18.04, and some test cases also didn't 
>>> run as expected, however the test step is judged to be passed. What are the 
>>> criteria for the CI system to judge whether the test step pass or not.
>>> [image: 20220830210239.jpg]
>>>
>>> -- 
>>> 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/aafa4b0f-fa81-4bf1-aa6b-f3ee7bbbe84cn%40chromium.org
>>>  
>>> 
>>> .
>>>
>>

-- 
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/8d3f9e4a-8e0c-4ab1-b636-7b50c1ad51b7n%40chromium.org.

[blink-dev] Re: Intent to Ship: tech() function support in @font-face src: descriptor

[Yoav Weiss]

On Monday, August 29, 2022 at 3:09:39 PM UTC+2 Dominik Röttsches wrote:

> (re-sent from @chromium.org address)
>
> Contact emailsdr...@chromium.org
>
> ExplainerNone
>

I think that a short explainer outlining exactly what you're planning to 
ship here and how you're expecting developers to use it would be helpful. 
Can you add one? (potentially even inline, if it's rather short)
 

>
>
> Specificationhttps://www.w3.org/TR/css-fonts-4/#font-face-src-parsing
>
> Summary
>
> CSS Fonts Level 4 provides additional means of selecting or filtering font 
> resources. The tech() function was introduced, which allows passing in a 
> list of font technologies that this respective font blob requires to 
> function. Based on that, the UA will select the first suitable resource.
>
>
> I will hold shipping until one remaining clarification is reached on 
> whether the keywords should be phrased in singular or plural form, compare 
> item 3 in https://github.com/w3c/csswg-drafts/issues/7633.
>
>
> *Motivation*
>
> With COLRv1 font supports, it's now more important to give authors an 
> opportunity to check feature support. Doing this in the tech() function in 
> the src: descriptor of @font-face is one useful tool for incremental 
> upgrade of the user experience. If the UA supports COLRv1 or other new font 
> technologies, the richer font is loaded, otherwise fallback occurs.
>
>
> Blink componentBlink>Fonts 
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/666
>
> TAG review statusIssues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Positive 
> https://github.com/mozilla/standards-positions/issues/563
>
> *WebKit*: No signal
>
> *Web developers*: In discussions with partners before launching COLRv1, 
> feature detection for COLRv1 was a requested functionality. The src: line 
> tech() function is one way to achieve that.
>
> *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?
>
>
>
> Debuggability
>
> Limited debuggability but unchanged to before: @font-face declarations are 
> viewable as source in DevTools, but otherwise no particular tooling support 
> is provided. However this is unchanged from before, as this change only 
> affects the syntax inside the @font-face src: line. 
>
>
> 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, initial tests provided by Jonathan Kew from Mozilla, which I then 
> updated, see https://github.com/w3c/csswg-drafts/issues/7633 and 
> https://github.com/web-platform-tests/wpt/pull/35681
>
> Flag nameCSSFontFaceSrcTechParsing (Blink RuntimeEnabledFeatures flag)
>
> Requires code in //chrome?No
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1216460
>
> Estimated milestones
>
> 107
>
>
> Anticipated spec changes
>
> See above, holding shipping until clarification is reached on singular or 
> plural naming of features- keywords.
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5088679224147968
>
>

-- 
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/1207fcc3-0453-4fd0-85f1-5021ca3f4cfcn%40chromium.org.

Re: [blink-dev] Intent to Prototype & Ship: Wildcards in Permissions Policy Origins

[Ari Chivukula]

Sorry about that:
https://github.com/mozilla/standards-positions/issues/679
https://github.com/WebKit/standards-positions/issues/51

~ Ari Chivukula (Their/There/They're)

On Wed, Aug 31, 2022, 10:06 Yoav Weiss  wrote:

>
>
> On Fri, Aug 26, 2022 at 7:27 PM Ari Chivukula 
> wrote:
>
>> Contact emails
>>
>> aric...@chromium.org, miketa...@chromium.org
>>
>> Design Doc
>>
>>
>> https://docs.google.com/document/d/1HtkQivbjO6TiP6uZdTt4KmTnWzbs5IZpEdrz59-fyYU/edit
>>
>> Specification
>>
>> https://github.com/w3c/webappsec-permissions-policy/issues/479
>>
>> Summary
>>
>> This feature will add support for wildcard in permissions policy
>> structured like SCHEME://*.HOST:PORT (e.g., https://*.foo.com/) where a
>> valid Origin could be constructed from SCHEME://HOST:PORT (e.g.,
>> https://foo.com/). This requires that HOST is at least eTLD+1 (a
>> registrable domain). This means that https://*.bar.foo.com/ works but
>> https://*.com/ won’t (if you want to allow all domains to use the
>> feature, you should just delegate to *). Wildcards in the scheme and port
>> section will be unsupported and https://*.foo.com/ does not delegate to
>> https://foo.com/.
>>
>> Before, a permissions policy might need to look like:
>>
>> permissions-policy: ch-ua-platform-version=(self "https://foo.com"; "
>> https://cdn1.foo.com"; "https://cdn2.foo.com";)
>>
>> With this feature, it could look like:
>>
>> permissions-policy: ch-ua-platform-version=(self "https://foo.com";
>> "https://*.foo.com";)
>>
>>
>>
>> Blink component
>>
>> Blink>PermissionsAPI
>> 
>>
>>
>>
>> Motivation
>>
>> The Permissions Policy specification
>>  “defines a
>> mechanism that allows developers to selectively enable and disable use of
>> various browser features and APIs.” One capability of this mechanism allows
>> features to be enabled only on explicitly enumerated origins (e.g.,
>> https://foo.com/). This mechanism is not flexible enough for the design
>> of some CDNs, which deliver content via an origin that might be hosted on
>> one of several hundred possible subdomains.
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/765
>>
>> Compatibility
>>
>> Depending on their user base, sites may want to entertain a transition
>> period for older Chromium clients, where they enumerate all subdomains and
>> include the wildcard in the permissions policy.
>>
>>
>> Interoperability
>>
>> We would be the first to implement if approved.
>>
>>
>>
>> Gecko: Will ask
>>
>>
>>
>> WebKit: Will ask
>>
>
> Links to signal requests?
>
>
>>
>>
>> Web developers:
>> https://github.com/w3c/webappsec-permissions-policy/issues/479
>> 
>>
>> Debuggability
>>
>> Future work might flag syntax errors in the Issues tab
>> 
>> .
>>
>> Is this feature fully tested by web-platform-tests?
>>
>> No, but it will be.
>>
>> Tracking bug
>>
>> https://crbug.com/1345994
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5170361717489664
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>> --
>> 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/CAGpy5DLDbhOMWugyzXTKsvjH6koO8g7sV7eg_NQgq0GZeCOQ1A%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/CAGpy5DLD7jNcuaSS0m8E6Kh3ge-DdX-KdiKHJpajHDUb7hqbzA%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype & Ship: Wildcards in Permissions Policy Origins

[Yoav Weiss]

On Fri, Aug 26, 2022 at 7:27 PM Ari Chivukula  wrote:

> Contact emails
>
> aric...@chromium.org, miketa...@chromium.org
>
> Design Doc
>
>
> https://docs.google.com/document/d/1HtkQivbjO6TiP6uZdTt4KmTnWzbs5IZpEdrz59-fyYU/edit
>
> Specification
>
> https://github.com/w3c/webappsec-permissions-policy/issues/479
>
> Summary
>
> This feature will add support for wildcard in permissions policy
> structured like SCHEME://*.HOST:PORT (e.g., https://*.foo.com/) where a
> valid Origin could be constructed from SCHEME://HOST:PORT (e.g.,
> https://foo.com/). This requires that HOST is at least eTLD+1 (a
> registrable domain). This means that https://*.bar.foo.com/ works but
> https://*.com/ won’t (if you want to allow all domains to use the
> feature, you should just delegate to *). Wildcards in the scheme and port
> section will be unsupported and https://*.foo.com/ does not delegate to
> https://foo.com/.
>
> Before, a permissions policy might need to look like:
>
> permissions-policy: ch-ua-platform-version=(self "https://foo.com"; "
> https://cdn1.foo.com"; "https://cdn2.foo.com";)
>
> With this feature, it could look like:
>
> permissions-policy: ch-ua-platform-version=(self "https://foo.com";
> "https://*.foo.com";)
>
>
>
> Blink component
>
> Blink>PermissionsAPI
> 
>
>
>
> Motivation
>
> The Permissions Policy specification
>  “defines a
> mechanism that allows developers to selectively enable and disable use of
> various browser features and APIs.” One capability of this mechanism allows
> features to be enabled only on explicitly enumerated origins (e.g.,
> https://foo.com/). This mechanism is not flexible enough for the design
> of some CDNs, which deliver content via an origin that might be hosted on
> one of several hundred possible subdomains.
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/765
>
> Compatibility
>
> Depending on their user base, sites may want to entertain a transition
> period for older Chromium clients, where they enumerate all subdomains and
> include the wildcard in the permissions policy.
>
>
> Interoperability
>
> We would be the first to implement if approved.
>
>
>
> Gecko: Will ask
>
>
>
> WebKit: Will ask
>

Links to signal requests?


>
>
> Web developers:
> https://github.com/w3c/webappsec-permissions-policy/issues/479
> 
>
> Debuggability
>
> Future work might flag syntax errors in the Issues tab
> 
> .
>
> Is this feature fully tested by web-platform-tests?
>
> No, but it will be.
>
> Tracking bug
>
> https://crbug.com/1345994
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5170361717489664
>
> ~ Ari Chivukula (Their/There/They're)
>
> --
> 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/CAGpy5DLDbhOMWugyzXTKsvjH6koO8g7sV7eg_NQgq0GZeCOQ1A%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/CAL5BFfVmqsva_4%2BrEMf%2BPoX4Bce%2Bg4yLrW7CiQKY63YUat5oGQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebXR Raw Camera Access

[Yoav Weiss]

LGTM3

On Fri, Aug 26, 2022 at 3:13 PM Mike Taylor  wrote:

> LGTM2 - thanks for improving the explainer in
> https://github.com/immersive-web/raw-camera-access/pull/15/files.
>
> On 8/24/22 6:25 PM, Chris Harrelson wrote:
>
> LGTM1 to ship. In my view, the revised explainer is enough, and the
> feature received a thorough going-over with the TAG.
>
> Side note: I greatly appreciate the team's responsiveness in discussions
> with the TAG and in this thread.
>
> On Wed, Aug 24, 2022 at 8:55 AM Alex Russell 
> wrote:
>
>> Hey Alex,
>>
>> I'd like to approve this ASAP, but the explainer is still lacking
>> critical detail about considered alternatives and some aspects of how the
>> design is going to stay in sync with the options that are available for
>> getUserMedia().
>>
>> Best,
>>
>> Alex
>>
>> On Tuesday, August 23, 2022 at 1:11:35 PM UTC-7 Alexander Cooper wrote:
>>
>>> Thanks Alex,
>>>
>>> I believe I've responded to all of your questions on the github thread,
>>> but I still had a few follow up clarifications. We'd been hoping to get
>>> this out in M106, but since that has already branched I definitely want to
>>> make sure we can get this out in M107.
>>>
>>> Thanks,
>>> Alex Cooper
>>>
>>> On Fri, Aug 12, 2022 at 4:49 PM slightlyoff via Chromestatus <
>>> admin+slightly...@cr-status.appspotmail.com> wrote:
>>>
 I've left some questions about the design in an issue here:
 https://github.com/immersive-web/raw-camera-access/issues/14

>>> --
 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/31066705e613ef2f%40google.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/6810925e-7d33-45f2-bc12-13563340101fn%40chromium.org
>> 
>> .
>>
> --
> 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/CAOMQ%2Bw8dRgwg%3D%3D8mDkapu6AEyxyxTkK5ciDa4-94YvB3HBNaqA%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/7ae81c1d-db41-d3cc-09bf-6bc9bd4b1cdf%40chromium.org
> 
> .
>

-- 
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/CAL5BFfU84wDfm2JzzKhV21r9c6a_x841KKHQ4QoGPJAp%2B4oW_Q%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: ContentVisibilityAutoStateChanged event

[Yoav Weiss]

LGTM2 conditional on driving the discussion on the Mozilla position thread
to completion and making sure the spec text properly reflects it.

On Thu, Aug 11, 2022 at 12:48 AM slightlyoff via Chromestatus <
admin+slightly...@cr-status.appspotmail.com> wrote:

> LGTM1
>
> --
> 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/5788c005e5ead850%40google.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/CAL5BFfU%3DV6M7KXYdwwWm_RFyzH7APA8pymm3_eno3ep7SCNgCg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS 'ic' Length Unit

[Rune Lillesveen]

we support the spec change, but since it won't have any impact on
implementation details we'll continue to ship in parallel with spec
consideration
We support the spec change, but since it won't have any impact on
implementation details we'll continue to ship in parallel with the spec
consideration.

On Tue, Aug 9, 2022 at 6:14 PM Rune Lillesveen  wrote:

> Given this was rejected last time it was discussed in the csswg, it
> doesn't seem likely it will change this time?
>
> On Sat, Aug 6, 2022 at 5:54 PM 紫云飞  wrote:
>
>> Please hold shipping (if necessary) until this spec issue resolved
>> https://github.com/w3c/csswg-drafts/issues/7577
>>
>> 在2022年8月6日星期六 UTC+8 00:45:05 写道：
>>
>>> LGTM🎉
>>>
>>> On Fri, Aug 5, 2022 at 10:27 AM Daniel Bratell 
>>> wrote:
>>>
 LGTM3

 /Daniel
 On 2022-08-05 07:47, Yoav Weiss wrote:

 LGTM2

 On Fri, Aug 5, 2022 at 12:08 AM slightlyoff via Chromestatus <
 admin+sl...@cr-status.appspotmail.com> wrote:

> LGTM1
> --
> 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/80309f05e57195ef%40google.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/CAL5BFfVkmQJafZAbGjKRihj7bbXF_cZvWTmZvS29YVWYW6ELGw%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+...@chromium.org.

>>> To view this discussion on the web visit
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/379f34fb-45df-354d-1ac4-b567043ecdb7%40gmail.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/63142886-4785-4cb9-9629-a4902588c1c9n%40chromium.org
>> 
>> .
>>
>
>
> --
> Rune Lillesveen
>
>

-- 
Rune Lillesveen

-- 
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/CACuPfeRtbzFyNaX_zCWzqN0cT63HLxCuWhsHmZPHaKQ5yS4hoQ%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Declarative Beacon API

[Ming-Ying Chung]

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  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 
> 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  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
 
  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  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
> 
>
> 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