Re: [blink-dev] Developer pain as a result of "introducing blink_wpt_tests"

[Xianzhu Wang]

Hi Blink devs,

The move has landed (https://crrev.com/1039971).

If you have any pending CLs that add/remove/modify files under
web_tests/platform/generic, please sync, and add/remove/modify the
corresponding file under web_tests/ instead.

Thanks,
Xianzhu

On Fri, Aug 26, 2022 at 10:57 AM Weizhong Xia  wrote:

> Hi Blink devs
>
> FYI we are finally ready to move generic baselines back to their original
> places: the test folders. I plan to land the CL today. To avoid any merge
> conflict during this process, we will add an OWNERS file to
> //third_party/blink/web_tests/platform/generic. Any change to that folder
> will require an additional +1, and will not be approved. Once the move is
> done, the "platform/generic" folder will be removed.
>
> thanks, Weizhong
>
> On Thu, Jun 23, 2022 at 11:00 AM Weizhong Xia  wrote:
>
>> Hi blink devs
>>
>> Thanks to those who joined the survey at
>> https://forms.gle/ju45qciS5VTR4ywN7. Most of you expressed the desire to
>> put baselines at the same place of the tests. Your voice is heard, and here
>> is the plan for the next step.
>>
>> In Q3 we will work on to completely separate legacy layout tests and wpt
>> tests, to put them under `third_party/blink/web_tests` and
>> `third_party/blink/wpt_tests` respectively. Generic baselines (including
>> generic virtual baselines) will be moved back to their previous place.
>> Rebaseline tool will be updated to work with this structure, and update
>> baselines for legacy layout tests and wpt tests in a single run. We will
>> have different copies of *TestExpectations*, *FlagSpecificConfig*,
>> *VirtualTestSuites* etc for legacy tests and wpt tests. When working on
>> those files, we will need to make sure we are updating the correct copy of
>> the file. (We will investigate if we need some presubmit check for such a
>> scenario).
>>
>> The reason for this is two fold: as requested we want to put baselines
>> side to side to the tests, and we want to make the directory structure
>> right to speed up the switch to wptrunner.
>>
>> Thoughts? Feel free to leave a comment in crbug/1299834
>> .
>>
>> Thanks, Weizhong
>>
>>
>>
>> On Mon, Jun 6, 2022 at 5:00 PM Xianzhu Wang 
>> wrote:
>>
>>> On Mon, Jun 6, 2022 at 3:52 PM Weizhong Xia  wrote:
>>>
 Xianzhu, yes 'baselines' is the name we agreed on previously. The
 reason I later changed back to use 'platform' is because that will make the
 CL smaller, and make it easier for gerrit to handle it. We can make one
 round rename when everything is stabilized. (I left you a message when you
 are OOO. I am not sure if that message lived long enough for you to catch
 it.)

>>>
>>> I caught the message. I guessed that the name 'platform' might be one of
>>> the reasons for the surprise to blink developers after the change, and the
>>> name 'baselines' might make the change easier to explain :)
>>>
>>> On Mon, Jun 6, 2022 at 3:52 PM Domenic Denicola 
>>> wrote:
>>>
 I'm not sure I understand this logic. -expected.txt files are just
 more-convenient, more in-your-face versions of TestExpectations files.
 Surely you're not suggesting we get rid of TestExpectations files?

>>>
>>> Sorry, "-expected.txt ... should be ... eventually be removed" in my
>>> previous email was not clear. I meant for each individual -expected.txt we
>>> should eventually remove it because we should fix the failure. The same
>>> logic applies to TestExpectations. At any time we may allow a certain
>>> number of failures but we should keep the number as small as possible.
>>>
>>> I think we should prefer TestExpectations to -expected.txt for WPT tests
>>> because the entries in TestExpectations have associated bugs which track
>>> the fixing process, unless we find a better way to track the fixing of the
>>> failures in -expected.txt. -expected.txt files do have their values, e.g.
>>> for partially-passing tests we can discover regressions and progressions of
>>> individual sub tests, but they should be rare.
>>>
>>> I think separating -expected.txt from the tests has the following
>>> benefits:
>>> - It makes it clear to blink developers that the files are not a part of
>>> WPT.
>>> - It simplifies the WPT export/import process and others by reducing
>>> blink-specific files under external/wpt.
>>>
>>> It does make it more difficult to find -expected.txt, but we already
>>> have the similar well-known logic for platform-specific baselines. Though
>>> platform-specific baselines are rare, ignoring a platform baseline can
>>> still cause surprises.
>>>
>>> I think we can improve the test result viewer
>>> 
>>> - to better show -expected.txt for passing tests
>>> - to show information about tests without actually running the tests
>>> WDYT?
>>>
>>>

 On Mon, Jun 6, 2022 at 6:30 PM Xianzhu Wang 
 wrote:

> I think

[blink-dev] Re: Intent to Prototype: Scoped Custom Element Registry

[Xiaocheng Hu]

Hi Lea,

No TAG review has been requested yet. "Pending" is just the default value
(which might also be confusing though...)

On Fri, Aug 26, 2022 at 3:19 AM Lea Verou  wrote:

> Hi there,
> I see it says "Pending" for the TAG review, but I cannot find any TAG
> review request in
> https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
> Could you please point me to it?
> Thanks!
>
> On Thursday, August 25, 2022 at 1:06:33 AM UTC+3 xiaoc...@chromium.org
> wrote:
>
>> Contact emailsxiaoc...@chromium.org
>>
>> Explainer
>> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md#overview
>>
>> Specification
>> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md
>>
>> Summary
>>
>> This feature allows for multiple custom element definitions for a single
>> tag name to exist within a page to prevent custom element name conflicts
>> when a web app uses libraries from multiple sources. This is achieved by
>> allowing user code to create multiple custom element registries and
>> associate them with shadow roots that function as scopes for element
>> creation and custom element definitions.
>>
>>
>> Blink componentBlink>HTML>CustomElements
>> 
>>
>> Motivation
>>
>> It's quite common for web applications to contain libraries from multiple
>> sources, whether from different teams, vendors, package managers, etc.
>> These libraries must currently contend for the global shared resource that
>> is the CustomElementRegistry. If more than one library (or more than one
>> instance of a library) tries to define the same tag name, the application
>> will fail. This feature solves the problem by using ShadowRoots, which
>> already function as encapsulation boundaries, to also function as scopes
>> for custom element definitions.
>>
>>
>> Initial public proposal
>> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md
>>
>> TAG review
>>
>> 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
>>
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1304439
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5090435261792256
>>
>> 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/CAFqEGhbLNaN9zvp5msuHm-BhG0Gs1LOTJUPMCG1ELyvJr_cc8w%40mail.gmail.com.

Re: [blink-dev] Developer pain as a result of "introducing blink_wpt_tests"

['Weizhong Xia' via blink-dev]

Hi Blink devs

FYI we are finally ready to move generic baselines back to their original
places: the test folders. I plan to land the CL today. To avoid any merge
conflict during this process, we will add an OWNERS file to
//third_party/blink/web_tests/platform/generic. Any change to that folder
will require an additional +1, and will not be approved. Once the move is
done, the "platform/generic" folder will be removed.

thanks, Weizhong

On Thu, Jun 23, 2022 at 11:00 AM Weizhong Xia  wrote:

> Hi blink devs
>
> Thanks to those who joined the survey at
> https://forms.gle/ju45qciS5VTR4ywN7. Most of you expressed the desire to
> put baselines at the same place of the tests. Your voice is heard, and here
> is the plan for the next step.
>
> In Q3 we will work on to completely separate legacy layout tests and wpt
> tests, to put them under `third_party/blink/web_tests` and
> `third_party/blink/wpt_tests` respectively. Generic baselines (including
> generic virtual baselines) will be moved back to their previous place.
> Rebaseline tool will be updated to work with this structure, and update
> baselines for legacy layout tests and wpt tests in a single run. We will
> have different copies of *TestExpectations*, *FlagSpecificConfig*,
> *VirtualTestSuites* etc for legacy tests and wpt tests. When working on
> those files, we will need to make sure we are updating the correct copy of
> the file. (We will investigate if we need some presubmit check for such a
> scenario).
>
> The reason for this is two fold: as requested we want to put baselines
> side to side to the tests, and we want to make the directory structure
> right to speed up the switch to wptrunner.
>
> Thoughts? Feel free to leave a comment in crbug/1299834
> .
>
> Thanks, Weizhong
>
>
>
> On Mon, Jun 6, 2022 at 5:00 PM Xianzhu Wang 
> wrote:
>
>> On Mon, Jun 6, 2022 at 3:52 PM Weizhong Xia  wrote:
>>
>>> Xianzhu, yes 'baselines' is the name we agreed on previously. The reason
>>> I later changed back to use 'platform' is because that will make the CL
>>> smaller, and make it easier for gerrit to handle it. We can make one round
>>> rename when everything is stabilized. (I left you a message when you are
>>> OOO. I am not sure if that message lived long enough for you to catch it.)
>>>
>>
>> I caught the message. I guessed that the name 'platform' might be one of
>> the reasons for the surprise to blink developers after the change, and the
>> name 'baselines' might make the change easier to explain :)
>>
>> On Mon, Jun 6, 2022 at 3:52 PM Domenic Denicola 
>> wrote:
>>
>>> I'm not sure I understand this logic. -expected.txt files are just
>>> more-convenient, more in-your-face versions of TestExpectations files.
>>> Surely you're not suggesting we get rid of TestExpectations files?
>>>
>>
>> Sorry, "-expected.txt ... should be ... eventually be removed" in my
>> previous email was not clear. I meant for each individual -expected.txt we
>> should eventually remove it because we should fix the failure. The same
>> logic applies to TestExpectations. At any time we may allow a certain
>> number of failures but we should keep the number as small as possible.
>>
>> I think we should prefer TestExpectations to -expected.txt for WPT tests
>> because the entries in TestExpectations have associated bugs which track
>> the fixing process, unless we find a better way to track the fixing of the
>> failures in -expected.txt. -expected.txt files do have their values, e.g.
>> for partially-passing tests we can discover regressions and progressions of
>> individual sub tests, but they should be rare.
>>
>> I think separating -expected.txt from the tests has the following
>> benefits:
>> - It makes it clear to blink developers that the files are not a part of
>> WPT.
>> - It simplifies the WPT export/import process and others by reducing
>> blink-specific files under external/wpt.
>>
>> It does make it more difficult to find -expected.txt, but we already have
>> the similar well-known logic for platform-specific baselines. Though
>> platform-specific baselines are rare, ignoring a platform baseline can
>> still cause surprises.
>>
>> I think we can improve the test result viewer
>> 
>> - to better show -expected.txt for passing tests
>> - to show information about tests without actually running the tests
>> WDYT?
>>
>>
>>>
>>> On Mon, Jun 6, 2022 at 6:30 PM Xianzhu Wang 
>>> wrote:
>>>
 I think we first need to answer a question: Why do we need
 *-expected.txt for WPT tests?

 Upstream WPT doesn't have *-expected.txt. *-expected.txt is a
 blink-specific thing to allow some failing WPT tests to pass on blink with
 temporarily allowed failures. If a test has -expected.txt, it means Chrome
 behaves differently than the standard web platform behavior (or the test
 itself is wrong). The files ar

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

[Ari Chivukula]

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



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.

Re: [blink-dev] Question about running Trust Token in Chrome

['Steven Valdez' via blink-dev]

I'm not sure about 8 months ago, but as of May (M101), the origin trial for
Trust Token concluded: https://chromestatus.com/feature/5078049450098688

We are still in the process of updating the API and figuring out next
steps, but in the meantime you can still enable the feature for local
experimentation via command-line flags as described in
https://www.chromium.org/updates/trust-token/.


On Fri, Aug 26, 2022 at 1:23 PM 'Yan Han' via blink-dev <
blink-dev@chromium.org> wrote:

> Hello,
>
> Our organization is trying to use Trust Tokens and we were able to test it
> locally up to 8 months ago with V2 PMB. But after that, it was not working
> anymore. We thought it was due to V3 update, but even after updating the
> configs to V3 PMB, it is still broken.
>
> The only error msg that we're seeing is shown below:
> [image: Screen Shot 2022-08-22 at 3.56.25 PM.png]
>
> Can we get more information about this error msg and how to fix this issue?
>
> Thanks,
> Yan
>
> --
> 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/CACvv7Wd7vEX%3Dhkz524tT47VYABEwjrrkrvG-QM2LfK7iUXfGtw%40mail.gmail.com
> 
> .
>


-- 

 Steven Valdez |  Chrome Privacy Sandbox |  sval...@google.com |  Cambridge,
MA

-- 
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/CANduzxBi1ti%3DojJdDEj0JvFQqWAO%2Bbqfx7t%3DREi3YQ6GShidSw%40mail.gmail.com.

[blink-dev] Question about running Trust Token in Chrome

['Yan Han' via blink-dev]

Hello,

Our organization is trying to use Trust Tokens and we were able to test it
locally up to 8 months ago with V2 PMB. But after that, it was not working
anymore. We thought it was due to V3 update, but even after updating the
configs to V3 PMB, it is still broken.

The only error msg that we're seeing is shown below:
[image: Screen Shot 2022-08-22 at 3.56.25 PM.png]

Can we get more information about this error msg and how to fix this issue?

Thanks,
Yan

-- 
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/CACvv7Wd7vEX%3Dhkz524tT47VYABEwjrrkrvG-QM2LfK7iUXfGtw%40mail.gmail.com.

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

[Mike Taylor]

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
mailto:admin%2bslightly...@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.

[blink-dev] Re: Intent to Prototype: Scoped Custom Element Registry

[Lea Verou]

Hi there,
I see it says "Pending" for the TAG review, but I cannot find any TAG 
review request 
in 
https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
Could you please point me to it? 
Thanks!

On Thursday, August 25, 2022 at 1:06:33 AM UTC+3 xiaoc...@chromium.org 
wrote:

> Contact emailsxiaoc...@chromium.org
>
> Explainer
> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md#overview
>
> Specification
> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md
>
> Summary
>
> This feature allows for multiple custom element definitions for a single 
> tag name to exist within a page to prevent custom element name conflicts 
> when a web app uses libraries from multiple sources. This is achieved by 
> allowing user code to create multiple custom element registries and 
> associate them with shadow roots that function as scopes for element 
> creation and custom element definitions.
>
>
> Blink componentBlink>HTML>CustomElements 
> 
>
> Motivation
>
> It's quite common for web applications to contain libraries from multiple 
> sources, whether from different teams, vendors, package managers, etc. 
> These libraries must currently contend for the global shared resource that 
> is the CustomElementRegistry. If more than one library (or more than one 
> instance of a library) tries to define the same tag name, the application 
> will fail. This feature solves the problem by using ShadowRoots, which 
> already function as encapsulation boundaries, to also function as scopes 
> for custom element definitions.
>
>
> Initial public proposal
> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md
>
> TAG review
>
> 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
>
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ?No
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1304439
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5090435261792256
>
> 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/3335790a-5053-41ad-8fff-e61006f4fa53n%40chromium.org.