[blink-dev] Intent to Prototype and Ship: WebUSB SameObject

['Jack Hsieh' via blink-dev]

Contact emails

chengw...@chromium.com

Explainer

None

Specification

https://wicg.github.io/webusb/#device-usage

https://github.com/WICG/webusb/pull/212

Summary

Make USBConfiguration, USBInterface, USBAlternateInterface, and USBEndpoint
instances returned by the accessors on USBDevice === comparable.

Blink component

Blink>USB


Motivation

It is helpful for WebUSB to have USBConfiguration, USBInterface,
USBAlternateInterface, and USBEndpoint instances returned by the accessors
on USBDevice === comparable. We have seen this requirement reported by
developers from https://crbug.com/1274922 and a positive signal from a
Node.js polyfill (https://github.com/thegecko/webusb).

TAG review

The change is trivial enough to waive a TAG review requirement.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This change only adds the `===` compatibility to related objects and data
structures while behaviors of the existing WebUSB APIs remain the same.
Developers who don't rely on this `===` compatibility wouldn’t notice a
thing with this feature rolling out behind the scenes, and so we believe
the compatibility risk to be minimal.

Signals from other implementations (Gecko, WebKit):

Gecko: No signal

WebKit: No signal

Web developers: https://crbug.com/1274922.

Other signals: The Node.js polyfill for WebUSB (
https://github.com/thegecko/webusb) already implements these accessors this
way.


Debuggability

No specific DevTools changes are required. This feature only changes the
internal behavior of existing WebUSB JS methods.

Note that exposing DevTools debugging support for device-access APIs
(WebUSB included) is discussed at
https://bugs.chromium.org/p/chromium/issues/detail?id=1142566.

Is this feature fully tested by web-platform-tests

?

Yes. This feature will be fully tested at https://wpt.fyi/results/webusb

Flag name

None

Requires code in //chrome?

False

Tracking Bug

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

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5769668454252544

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

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Mitar]

Hi!

So I finally got to experiment a bit with HTTP2 push, preload link
header, and 103 early hints and to compare them, especially in the
context of API endpoints (similar to Vulcain [1]). My observations
are:

Go does not yet support 103 Early hints (but PRs exist [2][3]). 103
Early hints seem to be very verbose if the main use case is to send
preload link headers: "rel=preload;" could be maybe just implied? And
if I want to specify "crossorigin=use-credentials" across multiple
links, it becomes repetitive. Maybe it would be simpler to have 103
Preload with slightly modified syntax which would allow one to group
preload links together based on attributes.

Using a regular preload link header seems to be acted upon only after
both HTTP headers and response body has been consumed by the browser.
So it seems to me that the whole 103 Early hints is just because
browsers do not process HTTP headers immediately when they receive
them (if I force flush them before even sending the response body).
Make me wonder if it would not be easier to standardize early
processing of HTTP headers and early acting upon link headers in there
instead of the whole 103 Early hints approach which requires new
support across the full HTTP stack. Am I missing something here? Why
do we even need 103 Early hints?

HTTP2 push is even in 2022 sadly lacking high quality support across
the stack and this makes it hard to use. Go does not support it in
HTTP client library [4] and doing HTTP pushes seems to be slow [5].
Nor Chrome nor Firefox provide any insights into HTTP pushes in
developer tools, so it is really hard to observe them and debug them
(timings, headers, have they been canceled by the browser, informing a
developer if HTTP push has not been used). With such bad support
across the stack I do not wonder anymore why people have a hard time
using HTTP pushes and using them effectively.

So my conclusion is: given how hard it is to get HTTP pushes to be
implemented across the stack, I worry that the same thing will happen
with 103 Early hints. E.g.: will they be and how will they be exposed
in developer tools? How will one be able to observe when they are in
effect and when they are not? I wonder if in 5 years we will not be at
the same point thinking about removing 103 Early hints. Maybe simply
do early processing of HTTP headers and acting upon any link headers
in there might be much simpler to both implement and expose in
developer tools in browsers (almost no work needed there, only
resources will be fetched earlier in timelines). And no need for any
changes to the rest of the HTTP stack.

[1] https://github.com/dunglas/vulcain
[2] https://github.com/golang/go/pull/42597
[3] https://github.com/golang/net/pull/96
[4] https://github.com/golang/go/issues/18594
[5] https://github.com/golang/go/issues/51361


Mitar



Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

-- 
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/CAKLmikPu72BG56Jng13iu-JLQ5iw4v97D%3DvhmaP5-pF4JT_ydw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain

['Daniel Vogelheim' via blink-dev]

Hi Noah,

Support for the cross-origin access warning landed this week, but
unfortunately only after the M100 branch cut. So this will first appear in
M101.
If you're willing to build Chromium from tip-of-tree, you should be able to
try it out now.

Daniel

On Fri, Feb 25, 2022 at 5:31 PM Noah Lemen  wrote:

> Any updates on the deprecation warning for cross-domain access? We're now
> looking into setting up the Reporting API to capture this once
> available. Which milestone do you estimate it will ship?
>
> On Monday, February 14, 2022 at 12:28:18 PM UTC-5 Daniel Vogelheim wrote:
>
>> Hi all, just a brief update:
>>
>> - The warning should go live on M100
>> .
>> - Flipping the default is planned for M106 but there'll be a
>> separate intent (and thus additional discussion), as requested.
>> - A deprecation warning for cross-domain access (based on previous
>> document.domain setting) is in the works, and will either make it to M100
>> also, or will land shortly after.
>> - Additional info: Blog post
>> ; plus
>> some technical notes
>> 
>> .
>>
>> On Wed, Jan 26, 2022 at 5:35 PM Daniel Bratell  wrote:
>>
>>> LGTM3
>>>
>>> /Daniel
>>> On 2022-01-14 13:58, Daniel Vogelheim wrote:
>>>
>>> Hi all,
>>> Hi Yoav,
>>>
>>> Thanks for the feedback. I'd like to modify the intent timeline as
>>> follows:
>>>
>>> M99: Start showing a deprecation warning.
>>> M99-105: Watch use counters + outreach to top-N users.
>>> M105: Deprecate the feature by default.
>>>
>>> Enabling/disabling will be via Finch, so we have an emergency shut-off.
>>>
>>> An enterprise policy is already in place.
>>>
>>> On Wed, Jan 12, 2022 at 6:45 PM Yoav Weiss  wrote:
>>>
 Hey Daniel!

 While searching for this intent review, I stumbled upon
 https://developer.chrome.com/blog/immutable-document-domain/
 That's a useful piece of documentation! Thanks +Eiji Kitamura!!

 This intent was just discussed at the API owner meeting (where Chris,
 Rego, Daniel, Philip, Alex, MikeT and myself were present).
 This change seems risky in terms of potential breakage when looking at
 our stats, and that's even before talking about enterprises, where a lot of
 the API owners feel the risk is even higher.

 Given that, here's a few potential next steps to try and reduce that
 risk:

- UKM and outreach to specific large users of the API can maybe
help drive the usage down.


>>> Will do. With Lutz' help I just checked the UKM we have on this, and it
>>> seems the usage is quite heavily concentrated on large sites. The
>>> top-quartile of remaining public usage is just 9 sites; top-half is ~35.
>>> We'll try to reach out to them.
>>>
>>>

- A deprecation period of 3 milestones feels a bit short here. Is
the expectation that turning on the opt-out header can be done under 
 that
period?

 As above, we'll happily go up on this.
>>>
>>> My reasoning why 3 milestones would be reasonable was that there is a
>>> "safe" opt-out. That is, if one wishes to preserve old behaviour, or isn't
>>> sure, or just wants to postpone the issue, one can just add
>>> 'Origin-Agent-Cluster: ?0" and deal with it later. This is quite different
>>> from e.g. CSP, where adding new CSP headers might require a lot of work and
>>> testing.
>>>
>>>

- A report-only mode could have allowed sites to try and enable
this, without risking actual breakage for their documents/properties 
 that
use document.domain. This is doubly true for platforms that want to warn
their customers about this upcoming deprecation, but without taking 
 risks
on their behalf. At the same time, it is true that they could collect
deprecation reports (thanks for adding those!) instead during the
deprecation period, which can be considered an on-by-default report-only
mode. Can y'all add specific guidance on deprecation reports to the
documentation?


>>> We see the deprecation warning - without any behavioural changes - as
>>> effectively being the report-only mode. We'll be more clear in the
>>> documentation.
>>>
>>>

-  It'd be helpful to reach out to enterprise folks and see what
their responses may be for this. +Greg Whitworth.
- This probably requires an Enterprise Policy, to reduce the risk
for managed installs. +bheenan@ for opinions on that front.

 I agree, and an enterprise policy is already in place.
>>>
>>>

- Is there a plan to eventually remove the opt-out option? Or is it
the plan to have it in place permanently?


>>> There is no plan. The current logic is relatively easy to maintain, so
>>> we have not made any 

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain

[Noah Lemen]

Any updates on the deprecation warning for cross-domain access? We're now 
looking into setting up the Reporting API to capture this once 
available. Which milestone do you estimate it will ship?

On Monday, February 14, 2022 at 12:28:18 PM UTC-5 Daniel Vogelheim wrote:

> Hi all, just a brief update:
>
> - The warning should go live on M100 
> .
> - Flipping the default is planned for M106 but there'll be a 
> separate intent (and thus additional discussion), as requested.
> - A deprecation warning for cross-domain access (based on previous 
> document.domain setting) is in the works, and will either make it to M100 
> also, or will land shortly after.
> - Additional info: Blog post 
> ; plus some 
> technical 
> notes 
> 
> .
>
> On Wed, Jan 26, 2022 at 5:35 PM Daniel Bratell  wrote:
>
>> LGTM3
>>
>> /Daniel
>> On 2022-01-14 13:58, Daniel Vogelheim wrote:
>>
>> Hi all,
>> Hi Yoav,
>>
>> Thanks for the feedback. I'd like to modify the intent timeline as 
>> follows:
>>
>> M99: Start showing a deprecation warning.
>> M99-105: Watch use counters + outreach to top-N users.
>> M105: Deprecate the feature by default.
>>
>> Enabling/disabling will be via Finch, so we have an emergency shut-off.
>>
>> An enterprise policy is already in place.
>>
>> On Wed, Jan 12, 2022 at 6:45 PM Yoav Weiss  wrote:
>>
>>> Hey Daniel! 
>>>
>>> While searching for this intent review, I stumbled upon 
>>> https://developer.chrome.com/blog/immutable-document-domain/ 
>>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>>
>>> This intent was just discussed at the API owner meeting (where Chris, 
>>> Rego, Daniel, Philip, Alex, MikeT and myself were present).
>>> This change seems risky in terms of potential breakage when looking at 
>>> our stats, and that's even before talking about enterprises, where a lot of 
>>> the API owners feel the risk is even higher.
>>>
>>> Given that, here's a few potential next steps to try and reduce that 
>>> risk:
>>>
>>>- UKM and outreach to specific large users of the API can maybe help 
>>>drive the usage down. 
>>>
>>>
>> Will do. With Lutz' help I just checked the UKM we have on this, and it 
>> seems the usage is quite heavily concentrated on large sites. The 
>> top-quartile of remaining public usage is just 9 sites; top-half is ~35. 
>> We'll try to reach out to them.
>>  
>>
>>>
>>>- A deprecation period of 3 milestones feels a bit short here. Is 
>>>the expectation that turning on the opt-out header can be done under 
>>> that 
>>>period? 
>>>
>>> As above, we'll happily go up on this.
>>
>> My reasoning why 3 milestones would be reasonable was that there is a 
>> "safe" opt-out. That is, if one wishes to preserve old behaviour, or isn't 
>> sure, or just wants to postpone the issue, one can just add 
>> 'Origin-Agent-Cluster: ?0" and deal with it later. This is quite different 
>> from e.g. CSP, where adding new CSP headers might require a lot of work and 
>> testing.
>>  
>>
>>>
>>>- A report-only mode could have allowed sites to try and enable 
>>>this, without risking actual breakage for their documents/properties 
>>> that 
>>>use document.domain. This is doubly true for platforms that want to warn 
>>>their customers about this upcoming deprecation, but without taking 
>>> risks 
>>>on their behalf. At the same time, it is true that they could collect 
>>>deprecation reports (thanks for adding those!) instead during the 
>>>deprecation period, which can be considered an on-by-default report-only 
>>>mode. Can y'all add specific guidance on deprecation reports to the 
>>>documentation? 
>>>
>>>
>> We see the deprecation warning - without any behavioural changes - as 
>> effectively being the report-only mode. We'll be more clear in the 
>> documentation.
>>  
>>
>>>
>>>-  It'd be helpful to reach out to enterprise folks and see what 
>>>their responses may be for this. +Greg Whitworth.
>>>- This probably requires an Enterprise Policy, to reduce the risk 
>>>for managed installs. +bheenan@ for opinions on that front. 
>>>
>>> I agree, and an enterprise policy is already in place.
>>  
>>
>>>
>>>- Is there a plan to eventually remove the opt-out option? Or is it 
>>>the plan to have it in place permanently?
>>>
>>>
>> There is no plan. The current logic is relatively easy to maintain, so we 
>> have not made any plan to remove the opt-out.
>>
>>

-- 
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] How to check if a document is fully active in Blink?

[Rakina Zata Amni]

One particular part that might differ a bit than the currently specified
definition of "fully active" is the check for whether the page's lifecycle
state is "active" or not, as we should also categorize BFCached documents
(and maybe prerendered documents as well?) as not "fully active" (see this
section
 of
TAG's design principles guideline). This is important because in Chrome's
implementation we just keep a BFCached document as is without resetting the
frame/window, so checking only those won't be enough.

(+Domenic Denicola  and others are currently working
on updating the spec
 to
include the "lifecycle state" check too, probably by checking the browsing
context status?)

On Wed, Feb 23, 2022 at 4:51 AM Daniel Cheng  wrote:

> I would be supportive of adding Document::IsFullyActive(), even if the
> underlying implementation simply checks if Document::GetFrame() or
> Document::domWindow() is null. That makes the intent more explicit rather
> than a null test of a random pointer getter/field.
>
> Daniel
>
> On Tue, 22 Feb 2022 at 11:35, Stefan Zager  wrote:
>
>> I *think* (document->domWindow() != nullptr) is the right check for that.
>> It's more typical to see (document->GetFrame() != nullptr) in the code, and
>> that should also work; they should be interchangeable.
>>
>> On Tue, Feb 22, 2022 at 4:29 AM Raphael Kubo da Costa <
>> raphael.kubo.da.co...@intel.com> wrote:
>>
>>> Hi Blinkers,
>>>
>>> https://html.spec.whatwg.org/multipage/browsers.html#fully-active
>>> specifies what a fully active document is, and several specs check whether
>>> a document is fully active in their algorithms.
>>>
>>> WebKit has Document::isFullyActive(), which essentially implements
>>> HTML's definition:
>>> https://github.com/WebKit/WebKit/blob/ee5042294047abd231e9f86f623d48924cbc2309/Source/WebCore/dom/Document.cpp#L2976
>>>
>>> We don't seem to have anything similar in Blink though, and as far as I
>>> can see different parts of the code implement that check differently. Some
>>> examples I've encountered so far:
>>> - Check ExecutionContext::IsContextDestroyed()
>>> - Check Document::IsActive()
>>> - Check Document::IsActive() and Document::GetFrame()
>>> - Check ExecutionContextLifecycleObserver::DomWindow() or
>>> ExecutionContextClient::DomWindow() (and optionally check
>>> DomWindow()->GetFrame too)
>>>
>>> Is there a recommendation here?
>>>
>>> --
>>> 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/c8141c56-158e-fe2d-e5b3-a72201e63327%40intel.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/CAHOQ7J_xkTqPmHt2zFW3e69nYG_rJvSB90-FYJb3G9wK%2BxnDqw%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/CAF3XrKo0AhjnMzACg9NyJeeE9Y1vTY6trtan%2Bwe36qgwS8gTpg%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/CACPC1r4rGcD8pRu1LPnB31io4wRb7T4vcQsV%2BLck-KCoBx1tFQ%40mail.gmail.com.

[blink-dev] Intent to Prototype: Mediacapture-transform VideoTrackGenerator

['Harald Alvestrand' via blink-dev]

Contact emails...@chromium.org

Explainer
https://github.com/w3c/mediacapture-transform/blob/main/explainer.md

Specification
https://w3c.github.io/mediacapture-transform/#video-track-generator

Summary

API to generate a video MediaStreamTrack from a WHATWG Stream of VideoFrame
objects. This is the WG-agreed form of the interface that was previously
known as MediaStreamTrackGenerator, specialized for video.


Blink componentBlink>MediaStream


Motivation

The WEBRTC WG agreed to adopt the mediacapture-transform proposal; as part
of the debate, the form of the function to generate a video
MediaStreamTrack was changed. This intent tracks the API change.


Initial public proposal

TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility



Gecko: Positive

WebKit: No signal

Web developers: No signals

Other signals:


Debuggability



Is this feature fully tested by web-platform-tests

?No

Flag nameVideoTrackGenerator

Requires code in //chrome?False

Tracking bughttps://crbug.com/1300528

Estimated milestones

No milestones specified


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

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/CAOqqYVH5ZynV-S11kjz-OWsnOtbt3P%3DoTo1EqB0D6mUi3itH%2Bg%40mail.gmail.com.