Re: [blink-dev] Intent to Ship: Resource Timing: Expose interim response times

[Yoav Weiss]

LGTM3

On Tue, May 9, 2023 at 10:20 PM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2023-05-09 19:44, Mike Taylor wrote:
>
> LGTM1
> On 5/8/23 5:45 AM, 'Noam Rosenthal' via blink-dev wrote:
>
>
>
> On Wednesday, April 26, 2023 at 6:54:40 PM UTC+3 Noam Rosenthal wrote:
>
> On Wed, Apr 26, 2023 at 1:32 PM Yoav Weiss  wrote:
>
>
>
> On Tue, Apr 25, 2023 at 10:47 AM Noam Rosenthal 
> wrote:
>
> Contact emailsnrose...@chromium.org
>
> Specificationhttps://github.com/w3c/resource-timing/pull/366
>
>
> What's preventing https://github.com/whatwg/fetch/pull/1483 from landing?
>
>
> Nothing specific. A long queue of requests from Anne and constant pings
> about several topics.
>
>
> Update: the fetch PR has landed, and Apple is officially supportive.
>
> --
> 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/52ade28b-4b38-4a1b-b83e-91165a050712n%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/b9b6f8d0-285c-96da-272e-0fe9039f4002%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/CAL5BFfV03SJuL52W_tCt2S%3D%3D4Sb2H9XqpepSw07KzFtbc%2BwvMg%40mail.gmail.com.

Re: [blink-dev] Scroll to Text Fragment - Gmail doesn't preview the link

[Michael Bradley]

I agree that it would be good for Google to handle this the same way a
copy does.  Previewing/testing the link from GMail draft always opens
another tab/window - at least in my experience - never a popup.

This was just a curiosity due to the inconvenience of NOT relying on the
draft Preview/Test, but opening a window and copying the URL into it.

Hope you guys had fun with this.

On Tue, May 9, 2023 at 2:42 PM David Bokan  wrote:

> Ah, I see it now...it's because GMail doesn't use an  tag...it fakes it
> and adds a click handler. Unfortunately there's not much you can do as a
> user in this case (aside from copy/pasting the URL manually) - ideally
> Gmail would fix their window.open to include noopener.
>
> On Tue, May 9, 2023 at 2:05 PM PhistucK  wrote:
>
>> That also does not work (in draft mode), but this is probably because it
>> does not have an href (and it probably uses the same code path as a
>> normal click), so a broken GMail implementation that breaks it.
>>
>> ☆*PhistucK*
>>
>>
>> On Tue, May 9, 2023 at 3:24 PM David Bokan  wrote:
>>
>>> Text fragments work just fine from `window.open` but have restrictions
>>> about being isolated from other pages. I suspect gmail isn't adding
>>> `noopener` in window.open so that the opened page remains reachable from
>>> gmail.
>>>
>>> If that's the case, your link should work if you ctrl/cmd-click the link
>>> or right-click>"open in new tab".
>>>
>>> On Monday, May 8, 2023 at 7:32:58 AM UTC-4 PhistucK wrote:
>>>
 Looks like the issue is that opening a URL with a scroll-to-fragment
 via window.open(...) does not scroll/highlight. GMail uses
 window.open(...) in draft mode.

 Here is a small test case (copy it and paste it in the address bar and
 click on both of the links) -
 data:text/html,window.open
 normal
 href


 There is also some weird handling of the fragment. If you unescape more
 than one of the commas (%2C), it stops highlighting -
 data:text/html,normal
 href with one unescaped comma normal
 href with two unescaped commas

 Note that the URL you mentioned does not really have an accurate
 scroll-to-fragment, it uses %22 for all quotes, but the page uses special
 types of quotes (not sure why it works, but maybe there is
 some pre-processing for easier URL creation).


 You can report this at crbug.com. Be sure to search for an existing
 issue first, though.



 ☆*PhistucK*


 On Wed, May 3, 2023 at 1:02 AM Michael Bradley 
 wrote:

> When drafting a gmail with a link containing a *ScrollToTextFragment*,
> Duties of Loyalty, Care and Obedience
> ,
> clicking on the link (in Draft) shows the dialog, "Go to link: https
> ... | Change | Remove", but following the link to test my intention
> to scroll merely loads the target webpage.
>
> However, sending the draft to a Yahoo email renders the highlighted
> text on the target webpage.  This is the desired result, but it would be
> more convenient to verify the intended behavior when testing the link in
> the draft.
>
> Windows 10 Home 22H2 1/‎14/‎2021 Build: 19045.2846
> Chrome Version 112.0.5615.138 (Official Build) (64-bit)
> GMail: 05-02-2023, No Add-ons, Advanced: all disabled.
>
> I understand the desire to disable this behavior, but I appreciate
> what this feature can do, as demonstrated in this link.
>
> --
> 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/2650c78e-e0f4-4d5d-9918-62a6ece72c1cn%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/CAAiMrtpwbrgrxaM6RfQs5%3DMLkjfGJMSEwAuVd7O7ANbjJTDBvw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: WGSLLanguageFeatures for WebGPU

['Loko Kung' via blink-dev]

Thanks Yoav for taking a look! Bumping this again since M115 branch point 
is coming soon (May 23) and we still need 2 more LGTMs before I can land 
the changes!

On Tuesday, May 9, 2023 at 7:31:33 AM UTC-7 Yoav Weiss wrote:

> LGTM1
>
> On Wed, May 3, 2023 at 9:52 PM Loko Kung  wrote:
>
>> Thanks Kai for replying! To add on top of that:
>>
>> For the signals: Positive
>> https://github.com/WebKit/standards-positions/issues/107
>> https://mozilla.github.io/standards-positions/#webgpu
>>
>
> \o/
>  
>
>>
>>
>> For the web-platform-tests, on top of the CTS Kai mentioned, the change 
>> in https://chromium-review.googlesource.com/c/chromium/src/+/4471680 
>> already adds the bare-bones testing for the new field.
>>
>> On Wed, May 3, 2023 at 12:22 PM Kai Ninomiya  wrote:
>>
>>> Thank you for the questions, replies inline!
>>>
>>> I actually ran into the same problem when I filed an I2S recently with a 
>>> lot of gaps in the generated email. The chromestatus tool hides most of the 
>>> fields used to generate emails behind various stages of shipment, which 
>>> makes it hard to set them correctly for I2E/I2S (I had to use "edit all 
>>> fields" to find them). It also defaults to rarely-correct values like "no 
>>> signals" and "no tests".
>>>
>>
> +Jason Robbins - FYI
>  
>
>>
>>> On Tue, May 2, 2023 at 10:42 PM Yoav Weiss  wrote:
>>>


 On Wed, May 3, 2023 at 12:04 AM Ken Russell  wrote:

> Could more Blink owners please provide their input? This is a feature 
> the WebGPU CG has standardized, and we would like to get it in our 
> implementation ASAP so the associated tests can start running correctly 
> in 
> Chrome.
>
> Thanks,
>
> -Ken
>
>
>
> On Tue, May 2, 2023 at 9:56 AM Caleb Raitto  
> wrote:
>
>> Thanks, I thought so, but wanted to confirm :)
>>
>> -Caleb
>>
>> On Tue, May 2, 2023 at 12:54 PM Ken Russell  
>> wrote:
>>
>>> These are essentially GPU-independent, syntactic-sugar-like, 
>>> language extensions that it's expected all browsers will eventually 
>>> implement. Since browser updates roll out at different times, it's 
>>> important that the application be able to query their support status so 
>>> they can know which versions of shaders to serve up to clients - or to 
>>> generate at run time.
>>>
>>> -Ken
>>>
>>>
>>>
>>> On Tue, May 2, 2023 at 8:33 AM Caleb Raitto  
>>> wrote:
>>>
 Are these language extensions specific to certain GPUs (could this 
 be used to fingerprint the GPU)? Or are the language extensions 
 something 
 that some browsers will implement, but others won't?

 Thanks, 
 -Caleb

 On Wednesday, April 26, 2023 at 3:36:27 PM UTC-4 Mike Taylor wrote:

> All good - I've flagged it in our chromestatus tool so it doesn't 
> fall off our radar.
>
> (and updating the email title just in case)
> On 4/26/23 2:42 PM, 'Loko Kung' via blink-dev wrote:
>
> Ah, sorry for the misleading title. This is actually an Intent to 
> Ship! Let me know if I should resend with the Intent to Ship template!
>
> On Tue, Apr 25, 2023 at 8:07 PM Loko Kung  
> wrote:
>
>> Contact emails loko...@google.com
>>
>> Explainer None
>>
>
 An explainer (even a short, inline one) would be extremely helpful when 
 reviewing this. As is, it's not immediately clear to me what are we adding 
 here, what are the use cases this addresses and how are developers 
 supposed 
 to use it?

>>>
>>> We're adding a mechanism for feature detection of new language features 
>>> added to WGSL (WebGPU Shading Language). Since that's a language and not a 
>>> JS API, we needed a feature detection mechanism better than "try to compile 
>>> a shader and (asynchronously) find out if it failed".
>>>
>>> At this time no such language features have been added yet (but we know 
>>> they will be). 
>>>
>>
> Thanks! That helps significantly :) 
>
>>
>>
>> Specification 
>> https://www.w3.org/TR/webgpu/#gpuwgsllanguagefeatures
>>
>> Summary 
>>
>> Adds the `wgslLanguageFeatures` getter on the GPU object for 
>> WebGPU, and its corresponding `WGSLLanguageFeatures` type.
>>
>>
>> Blink component Blink>WebGPU 
>> 
>>
>> Motivation 
>>
>> None
>>
>>
>> Initial public proposal None
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks 
>>
>>
>> Interoperability and Compatibility 
>>
>> None
>>
>>
>> 

Re: [blink-dev] Intent to Ship: Keyboard-focusable scroll containers

[Di Zhang]

Yes, this change is flagged behind the feature KeyboardFocusableScrollers 
(disabled by passing `--disable-blink-features=KeyboardFocusableScrollers`).

We have looped in aleventhal@ for similar accessibility concern. Aaron is 
the one who implemented the Keyboard Focusable Scrollers feature on Gecko 
years ago.
This feature (minus the "not contain any keyboard focusable children" rule) 
has existed in Firefox for +18 years now without any issue. Since assistive 
technology (for example screen readers) are using the same code for Firefox 
and Chrome, this should be low risk.

> I have a vague memory that "element is focusable" may be used in the tab 
highlighting algorithm. It may be worth a quick check to ensure that this 
doesn't cause highlights to show up when tapping on a scrollable region 
that has no other tap highlight candidates. I can help point you at the 
right code / people if desired.
Just to clarify, when you mention "tab highlighting algorithm", do you mean 
showing the orange focus ring when on mobile devices? I just tried with the 
feature on and off. In both cases, tapping doesn't show focus (no focus 
ring). As for using tab navigation, I see the same behavior as on the web. 
If feature is on, then an orange focus ring will show on the scroller.
If my understanding is wrong, please point me to the right code / people. 
Thank you




On Monday, May 8, 2023 at 4:00:23 AM UTC-7 Rick Byers wrote:

> Thanks Domenic, that's helpful and makes sense to me. It's perhaps whether 
> this is a "web exposed" change or not.
>
> This sounds pretty safe to experiment with to me. Di please make sure 
> behavior change is done behind a flag 
> 
>  
> so we can 'kill switch' it if needed.
>
> Perhaps the biggest compatibility risk here is the impact on assistive 
> technology use cases? That's not something I feel equipped to have any 
> judgement around. Have you talked with anyone in the accessibility team 
> about this? Do we have any data or anecdotes on sites setting tabindex:0 on 
> scrollers? Perhaps if that's already somewhat common place then that could 
> reduce any fear dramatically?
>
> I have a vague memory that "element is focusable" may be used in the tab 
> highlighting algorithm. It may be worth a quick check to ensure that this 
> doesn't cause highlights to show up when tapping on a scrollable region 
> that has no other tap highlight candidates. I can help point you at the 
> right code / people if desired.
>
> Rick
>
> On Mon, May 8, 2023 at 3:51 AM Domenic Denicola  
> wrote:
>
>> Speaking with my HTML Standard spec editor hat on, I think it's 
>> appropriate for Chromium to ship this without spec changes, as Di explains.
>>
>> Indeed, I'd be skeptical of changing the spec here. It might be worth 
>> opening an issue to discuss whether any changes are appropriate, but in 
>> general the spec is intentional about allowing each browser to make 
>> different choices on what it considers focusable, and in which ways things 
>> are focusable. So I'd anticipate no changes resulting from such an issue.
>>
>>
>> On Tue, May 2, 2023 at 4:50 AM Di Zhang  wrote:
>>
>>> Right - the spec leaves it up to the UA to determine what is a focusable 
>>> area. All browsers treat this a bit differently, and have typically 
>>> considered that behavior to be up to the browser. For example, Safari has a 
>>> user setting that can change what types of elements become keyboard 
>>> focusable. So I'm guessing there will be pushback to standardizing this 
>>> behavior. However, this is also why we don't believe there's a need to 
>>> change the spec for this I2S.
>>>
>>> Similarly, the written tests for this feature's changes are passing for 
>>> Chrome, but not the other UAs. I have removed that check from this feature 
>>> status and will update WPT accordingly.
>>>
>>> On Friday, April 28, 2023 at 7:08:37 AM UTC-7 Mike Taylor wrote:
>>>
 On 4/27/23 5:28 PM, Di Zhang wrote:

 Contact emails h...@chromium.org, xiaoche...@chromium.org, 
 dizha...@chromium.org

 Explainer None

 Specification 
 None

 What's the reason for not having a spec? Is the idea that this is 
 covered by this definition of a "focusable area": "the element is 
 determined by the user agent to be focusable"

 If we have multi-vendor alignment, maybe we can be more explicit than 
 that?

 (https://html.spec.whatwg.org/#focusable-area)


 Design docs None

 Summary 

 Improves accessibility by making scroll containers focusable using 
 sequential focus navigation. Today, the tab key doesn't focus scrollers 
 unless tabIndex is explicitly set to 0 or more. By making scrollers 
 focusable by default, users who can't (or don't want to) use a mouse will 
 be able to focus clipped content using a keyboard's tab and arrow 

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

['Andreas Haas' via blink-dev]

Thank you very much!

On Tue, May 9, 2023 at 11:00 PM Chris Harrelson 
wrote:

> LGTM3 to change the limit to 8MB, for the reasons Andreas outlined
> (maximum function size, reasonable runtime on a low-end phone).
>
> Also, I can totally see increasing the limit in the future, as the
> implementation is optimized further, typical hardware speeds increase, or
> there are compelling examples of developer use cases that come up. For now,
> 8MB seems a reasonable & conservative choice.
>
> Thanks Andreas for your patience on this thread, and for providing such
> useful data points!
>
> Chris
>
> On Thu, May 4, 2023 at 9:13 PM Elliott Sprehn 
> wrote:
>
>>
>>
>> On Thu, May 4, 2023 at 6:40 AM Andreas Haas  wrote:
>>
>>> Hi Yoav, PhistucK,
>>>
>>> [...]
>>>
>>
>>
>>> My problem now is that with the higher limit we still violate the spec,
>>> an with the spec test I introduced during this discussion the spec
>>> violation is even more visible. As someone wrote before, a solution to this
>>> problem could be to change the spec, but the same as there is no reason to
>>> keep or remove the limit in Chrome, there is no reason to introduce such a
>>> limit into the spec.
>>>
>>>
>> Multiple experts in web performance have given reasons to keep the limit
>> in this thread. That would be the reason to introduce it to the spec.
>>
>> - E
>>
>> --
>> 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/CAPKeNH%3DnkK6o8mZUHazY-QU6jH8O4Yw9UNqt8sb%2B8PCLaCfU%2Bg%40mail.gmail.com
>> 
>> .
>>
>

-- 

Andreas Haas

Software Engineer

ah...@google.com


Google Germany GmbH

Erika-Mann-Straße 33

80636 München


Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg


Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.



This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.

-- 
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/CAELSTvdE6CkWgTw6UARn%2BmiErA%2Bd0prXQmvXn8S0WTT7-1PMrg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Chris Harrelson]

LGTM3 to change the limit to 8MB, for the reasons Andreas outlined (maximum
function size, reasonable runtime on a low-end phone).

Also, I can totally see increasing the limit in the future, as the
implementation is optimized further, typical hardware speeds increase, or
there are compelling examples of developer use cases that come up. For now,
8MB seems a reasonable & conservative choice.

Thanks Andreas for your patience on this thread, and for providing such
useful data points!

Chris

On Thu, May 4, 2023 at 9:13 PM Elliott Sprehn  wrote:

>
>
> On Thu, May 4, 2023 at 6:40 AM Andreas Haas  wrote:
>
>> Hi Yoav, PhistucK,
>>
>> [...]
>>
>
>
>> My problem now is that with the higher limit we still violate the spec,
>> an with the spec test I introduced during this discussion the spec
>> violation is even more visible. As someone wrote before, a solution to this
>> problem could be to change the spec, but the same as there is no reason to
>> keep or remove the limit in Chrome, there is no reason to introduce such a
>> limit into the spec.
>>
>>
> Multiple experts in web performance have given reasons to keep the limit
> in this thread. That would be the reason to introduce it to the spec.
>
> - E
>
> --
> 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/CAPKeNH%3DnkK6o8mZUHazY-QU6jH8O4Yw9UNqt8sb%2B8PCLaCfU%2Bg%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/CAOMQ%2Bw-VQ9j62wGcKmJ1bc4j5dkLzHshz5KZGrP7G7OD_4_CGA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Resource Timing: Expose interim response times

[Daniel Bratell]

LGTM2

/Daniel

On 2023-05-09 19:44, Mike Taylor wrote:


LGTM1

On 5/8/23 5:45 AM, 'Noam Rosenthal' via blink-dev wrote:



On Wednesday, April 26, 2023 at 6:54:40 PM UTC+3 Noam Rosenthal wrote:

On Wed, Apr 26, 2023 at 1:32 PM Yoav Weiss 
wrote:



On Tue, Apr 25, 2023 at 10:47 AM Noam Rosenthal
 wrote:

Contact emailsnrose...@chromium.org

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


What's preventing https://github.com/whatwg/fetch/pull/1483
from landing?

Nothing specific. A long queue of requests from Anne and constant
pings about several topics.


Update: the fetch PR has landed, and Apple is officially supportive.

--
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/52ade28b-4b38-4a1b-b83e-91165a050712n%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/b9b6f8d0-285c-96da-272e-0fe9039f4002%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/6fce30bd-888f-59b0-3549-9e7c8c83a6f6%40gmail.com.

Re: [blink-dev] Scroll to Text Fragment - Gmail doesn't preview the link

[David Bokan]

Ah, I see it now...it's because GMail doesn't use an  tag...it fakes it
and adds a click handler. Unfortunately there's not much you can do as a
user in this case (aside from copy/pasting the URL manually) - ideally
Gmail would fix their window.open to include noopener.

On Tue, May 9, 2023 at 2:05 PM PhistucK  wrote:

> That also does not work (in draft mode), but this is probably because it
> does not have an href (and it probably uses the same code path as a
> normal click), so a broken GMail implementation that breaks it.
>
> ☆*PhistucK*
>
>
> On Tue, May 9, 2023 at 3:24 PM David Bokan  wrote:
>
>> Text fragments work just fine from `window.open` but have restrictions
>> about being isolated from other pages. I suspect gmail isn't adding
>> `noopener` in window.open so that the opened page remains reachable from
>> gmail.
>>
>> If that's the case, your link should work if you ctrl/cmd-click the link
>> or right-click>"open in new tab".
>>
>> On Monday, May 8, 2023 at 7:32:58 AM UTC-4 PhistucK wrote:
>>
>>> Looks like the issue is that opening a URL with a scroll-to-fragment via
>>> window.open(...) does not scroll/highlight. GMail uses window.open(...)
>>> in draft mode.
>>>
>>> Here is a small test case (copy it and paste it in the address bar and
>>> click on both of the links) -
>>> data:text/html,window.open
>>> normal
>>> href
>>>
>>>
>>> There is also some weird handling of the fragment. If you unescape more
>>> than one of the commas (%2C), it stops highlighting -
>>> data:text/html,normal
>>> href with one unescaped comma normal
>>> href with two unescaped commas
>>>
>>> Note that the URL you mentioned does not really have an accurate
>>> scroll-to-fragment, it uses %22 for all quotes, but the page uses special
>>> types of quotes (not sure why it works, but maybe there is
>>> some pre-processing for easier URL creation).
>>>
>>>
>>> You can report this at crbug.com. Be sure to search for an existing
>>> issue first, though.
>>>
>>>
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Wed, May 3, 2023 at 1:02 AM Michael Bradley 
>>> wrote:
>>>
 When drafting a gmail with a link containing a *ScrollToTextFragment*,
 Duties of Loyalty, Care and Obedience
 ,
 clicking on the link (in Draft) shows the dialog, "Go to link: https
 ... | Change | Remove", but following the link to test my intention to
 scroll merely loads the target webpage.

 However, sending the draft to a Yahoo email renders the highlighted
 text on the target webpage.  This is the desired result, but it would be
 more convenient to verify the intended behavior when testing the link in
 the draft.

 Windows 10 Home 22H2 1/‎14/‎2021 Build: 19045.2846
 Chrome Version 112.0.5615.138 (Official Build) (64-bit)
 GMail: 05-02-2023, No Add-ons, Advanced: all disabled.

 I understand the desire to disable this behavior, but I appreciate what
 this feature can do, as demonstrated in this link.

 --
 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/2650c78e-e0f4-4d5d-9918-62a6ece72c1cn%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/CANMmsAsCKmOV%2BQAE43ObpX_KpfbmjFroS92jLDjkFYBXxpG5yw%40mail.gmail.com.

Re: [blink-dev] Scroll to Text Fragment - Gmail doesn't preview the link

[PhistucK]

That also does not work (in draft mode), but this is probably because it
does not have an href (and it probably uses the same code path as a normal
click), so a broken GMail implementation that breaks it.

☆*PhistucK*


On Tue, May 9, 2023 at 3:24 PM David Bokan  wrote:

> Text fragments work just fine from `window.open` but have restrictions
> about being isolated from other pages. I suspect gmail isn't adding
> `noopener` in window.open so that the opened page remains reachable from
> gmail.
>
> If that's the case, your link should work if you ctrl/cmd-click the link
> or right-click>"open in new tab".
>
> On Monday, May 8, 2023 at 7:32:58 AM UTC-4 PhistucK wrote:
>
>> Looks like the issue is that opening a URL with a scroll-to-fragment via
>> window.open(...) does not scroll/highlight. GMail uses window.open(...)
>> in draft mode.
>>
>> Here is a small test case (copy it and paste it in the address bar and
>> click on both of the links) -
>> data:text/html,window.open
>> normal
>> href
>>
>>
>> There is also some weird handling of the fragment. If you unescape more
>> than one of the commas (%2C), it stops highlighting -
>> data:text/html,normal
>> href with one unescaped comma normal
>> href with two unescaped commas
>>
>> Note that the URL you mentioned does not really have an accurate
>> scroll-to-fragment, it uses %22 for all quotes, but the page uses special
>> types of quotes (not sure why it works, but maybe there is
>> some pre-processing for easier URL creation).
>>
>>
>> You can report this at crbug.com. Be sure to search for an existing
>> issue first, though.
>>
>>
>>
>> ☆*PhistucK*
>>
>>
>> On Wed, May 3, 2023 at 1:02 AM Michael Bradley 
>> wrote:
>>
>>> When drafting a gmail with a link containing a *ScrollToTextFragment*,  
>>> Duties
>>> of Loyalty, Care and Obedience
>>> ,
>>> clicking on the link (in Draft) shows the dialog, "Go to link: https
>>> ... | Change | Remove", but following the link to test my intention to
>>> scroll merely loads the target webpage.
>>>
>>> However, sending the draft to a Yahoo email renders the highlighted text
>>> on the target webpage.  This is the desired result, but it would be more
>>> convenient to verify the intended behavior when testing the link in the
>>> draft.
>>>
>>> Windows 10 Home 22H2 1/‎14/‎2021 Build: 19045.2846
>>> Chrome Version 112.0.5615.138 (Official Build) (64-bit)
>>> GMail: 05-02-2023, No Add-ons, Advanced: all disabled.
>>>
>>> I understand the desire to disable this behavior, but I appreciate what
>>> this feature can do, as demonstrated in this link.
>>>
>>> --
>>> 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/2650c78e-e0f4-4d5d-9918-62a6ece72c1cn%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/CABc02_JoLxApR4i%3Dtc5K7zv0EWZ5grfeBx29KvsLaZQ3z_CdZg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Boolean Context Style Container Queries

[Mike Taylor]

LGTM3

On 5/9/23 4:38 AM, Philip Jägenstedt wrote:

LGTM2

On Wed, May 3, 2023 at 11:35 PM Manuel Rego Casasnovas 
 wrote:


LGTM1

On 03/05/2023 14:22, Rune Lillesveen wrote:
>
>         Contact emails
>
> futh...@chromium.org 
>
>
>         Explainer
>
> None
>
>
>         Specification
>
> https://drafts.csswg.org/css-contain-3/#style-container
> 
>
>
>         Summary
>
> Support style() container queries without a declaration value,
only a
> property name, as a way of matching non-initial values.
Previously you
> would have to do: not style(--my-property: initial) Now you can do:
> style(--my-property) to match any non-initial value.
>
>
>
>         Blink component
>
> Blink>CSS
>

>
>
>         TAG review
>
> None
>
>
>         TAG review status
>
> Not applicable
>
>
>         Risks
>
>
> This is a minor change in the existing style() queries API. No new
> standards positions. Chrome shipped style() queries for custom
> properties in M111, but none of the other browsers have.
>
> The effect on existing content is that boolean context style queries
> that currently parse as  and evaluate to 'unknown'
> will start evaluating to true/false depending on computed value.
It is
> so unlikely that existing content will be affected by this that
it does
> not seem to be worth the effort to measure.
>
>
>         Interoperability and Compatibility
>
>
>
> /Gecko/: No signal
> (https://github.com/mozilla/standards-positions/issues/686
> )
>
> /WebKit/: No signal
> (https://github.com/WebKit/standards-positions/issues/57
> )
>
> /Web developers/: No signals
>
> /Other signals/:
>
>
>
>
>         Debuggability
>
> Works
>
>
>         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
>
> Tests added for custom property queries under:
>
>

http://wpt.fyi/css/css-contain/container-queries/at-container-style-parsing.html


>

http://wpt.fyi/css/css-contain/container-queries/at-container-style-serialization.html


>

http://wpt.fyi/css/css-contain/container-queries/custom-property-style-queries.html


>
>
>
>         Flag name
>
> #enable-experimental-web-platform-features
>
>
>         Requires code in //chrome?
>
> False
>
>
>         Tracking bug
>
> https://crbug.com/1442183 
>
>
>         Estimated milestones
>
> Shipping on desktop   115
> DevTrial on desktop   114
>
> Shipping on Android   115
> DevTrial on Android   114
>
> Shipping on WebView   115
>
>
>
>         Anticipated spec changes
>
> Resolved in [1], first PR merged [2], and a second
spec-text-tweak PR to
> be merged [3].
>
>
> [1]
https://github.com/w3c/csswg-drafts/issues/8127#issuecomment-1479871971

>
> [2] https://github.com/w3c/csswg-drafts/pull/8729
> 
>
> [3] https://github.com/w3c/csswg-drafts/pull/8756
> 
>
>
>         Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/6332337266098176
> 
>
>
>         Links to previous Intent discussions
>
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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 

Re: [blink-dev] Intent to Ship: Resource Timing: Expose interim response times

[Mike Taylor]

LGTM1

On 5/8/23 5:45 AM, 'Noam Rosenthal' via blink-dev wrote:



On Wednesday, April 26, 2023 at 6:54:40 PM UTC+3 Noam Rosenthal wrote:

On Wed, Apr 26, 2023 at 1:32 PM Yoav Weiss 
wrote:



On Tue, Apr 25, 2023 at 10:47 AM Noam Rosenthal
 wrote:

Contact emailsnrose...@chromium.org

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


What's preventing https://github.com/whatwg/fetch/pull/1483
from landing?

Nothing specific. A long queue of requests from Anne and constant
pings about several topics.


Update: the fetch PR has landed, and Apple is officially supportive.

--
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/52ade28b-4b38-4a1b-b83e-91165a050712n%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/b9b6f8d0-285c-96da-272e-0fe9039f4002%40chromium.org.

[blink-dev] Re: Intent to Prototype: Web environment integrity API

['Ben Wiser' via blink-dev]

The contact email b...@chromium.org was added in error. That should be 
bew...@chromium.org.
On Monday, May 8, 2023 at 4:30:30 PM UTC+1 Ben Wiser wrote:

> Contact emails
>
> serge...@chromium.org, pb...@chromium.org, ryanka...@google.com, 
> b...@chromium.org, erictrou...@chromium.org
> Explainer
>
>
> https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md
> Specification
>
> We do not have a specification yet, however we expect to publish in the 
> near future both the considered implementation options for the web layer in 
> an initial spec, which we suspect are not very controversial, and an 
> explanation of our approach for issuing tokens, which we expect will spark 
> more public discussion, but is not directly a web platform component. We 
> are gathering community feedback through the explainer before we actively 
> develop the specification.
> TAG Review
>
> Not filed yet.
> Blink component
>
> Blink>Identity 
> 
> Summary
>
> This is a new JavaScript API that lets web developers retrieve a token to 
> attest to the integrity of the web environment. This can be sent to 
> websites’ web servers to verify that the environment the web page is 
> running on is trusted by the attester. The web server can use asymmetric 
> cryptography to verify that the token has not been tampered with. This 
> feature relies on platform level attesters (in most cases from the 
> operating system).
>
> This project was discussed in the W3C Anti-Fraud Community Group on April 
> 28th, and we look forward to more conversations in W3C forums in the 
> future. In the meantime, we welcome feedback on the explainer 
> 
> .
> Motivation
>
> This is beneficial for anti-fraud measures. Websites commonly use 
> fingerprinting techniques to try to verify that a real human is using a 
> real device. We intend to introduce this feature to offer an adversarially 
> robust and long-term sustainable anti-abuse solution while still protecting 
> users’ privacy.
> Initial public proposal
>
> https://github.com/antifraudcg/proposals/issues/8
> Risks
>
> Interoperability and Compatibility
>
> We are currently working on the explainer and specification and are 
> working with the Anti-Fraud Community Group to work towards consensus 
> across the web community. The “attester” is platform specific so this 
> feature needs to be included on a per platform basis. We are initially 
> targeting mobile Chrome and WebView.
>
> Ergonomics
>
> See “How can I use web environment integrity? 
> ”
>  
> in the explainer. Note that we are actively looking for input from the 
> anti-fraud community and may update the API shape based on this. We also 
> expect developers to use this API through aggregated analysis of the 
> attestation signals.
>
> Security
>
> See the “Challenges and threats to address 
> ”
>  
> section of the explainer to see our current considerations.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)?
>
> We initially support this only for Android platforms (Android, and Android 
> WebView). This feature requires an attester backed by the target platform 
> so it will require active integration per platform.
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> Web platform tests will be added as part of this work as part of the 
> prototyping. We will then feed those tests back into the specification.
>
> Requires code in //chrome?
>
> True
>
> Feature flag (until launch)
>
> --enable-features=WebEnvironmentIntegrity
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5796524191121408
>

-- 
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/230899ff-5c7a-40bd-a9cb-b73f449d2e24n%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: WGSLLanguageFeatures for WebGPU

[Yoav Weiss]

LGTM1

On Wed, May 3, 2023 at 9:52 PM Loko Kung  wrote:

> Thanks Kai for replying! To add on top of that:
>
> For the signals: Positive
> https://github.com/WebKit/standards-positions/issues/107
> https://mozilla.github.io/standards-positions/#webgpu
>

\o/


>
>
> For the web-platform-tests, on top of the CTS Kai mentioned, the change in
> https://chromium-review.googlesource.com/c/chromium/src/+/4471680 already
> adds the bare-bones testing for the new field.
>
> On Wed, May 3, 2023 at 12:22 PM Kai Ninomiya  wrote:
>
>> Thank you for the questions, replies inline!
>>
>> I actually ran into the same problem when I filed an I2S recently with a
>> lot of gaps in the generated email. The chromestatus tool hides most of the
>> fields used to generate emails behind various stages of shipment, which
>> makes it hard to set them correctly for I2E/I2S (I had to use "edit all
>> fields" to find them). It also defaults to rarely-correct values like "no
>> signals" and "no tests".
>>
>
+Jason Robbins  - FYI


>
>> On Tue, May 2, 2023 at 10:42 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Wed, May 3, 2023 at 12:04 AM Ken Russell  wrote:
>>>
 Could more Blink owners please provide their input? This is a feature
 the WebGPU CG has standardized, and we would like to get it in our
 implementation ASAP so the associated tests can start running correctly in
 Chrome.

 Thanks,

 -Ken



 On Tue, May 2, 2023 at 9:56 AM Caleb Raitto 
 wrote:

> Thanks, I thought so, but wanted to confirm :)
>
> -Caleb
>
> On Tue, May 2, 2023 at 12:54 PM Ken Russell  wrote:
>
>> These are essentially GPU-independent, syntactic-sugar-like, language
>> extensions that it's expected all browsers will eventually implement. 
>> Since
>> browser updates roll out at different times, it's important that the
>> application be able to query their support status so they can know which
>> versions of shaders to serve up to clients - or to generate at run time.
>>
>> -Ken
>>
>>
>>
>> On Tue, May 2, 2023 at 8:33 AM Caleb Raitto 
>> wrote:
>>
>>> Are these language extensions specific to certain GPUs (could this
>>> be used to fingerprint the GPU)? Or are the language extensions 
>>> something
>>> that some browsers will implement, but others won't?
>>>
>>> Thanks,
>>> -Caleb
>>>
>>> On Wednesday, April 26, 2023 at 3:36:27 PM UTC-4 Mike Taylor wrote:
>>>
 All good - I've flagged it in our chromestatus tool so it doesn't
 fall off our radar.

 (and updating the email title just in case)
 On 4/26/23 2:42 PM, 'Loko Kung' via blink-dev wrote:

 Ah, sorry for the misleading title. This is actually an Intent to
 Ship! Let me know if I should resend with the Intent to Ship template!

 On Tue, Apr 25, 2023 at 8:07 PM Loko Kung 
 wrote:

> Contact emails lokok...@google.com
>
> Explainer None
>

>>> An explainer (even a short, inline one) would be extremely helpful when
>>> reviewing this. As is, it's not immediately clear to me what are we adding
>>> here, what are the use cases this addresses and how are developers supposed
>>> to use it?
>>>
>>
>> We're adding a mechanism for feature detection of new language features
>> added to WGSL (WebGPU Shading Language). Since that's a language and not a
>> JS API, we needed a feature detection mechanism better than "try to compile
>> a shader and (asynchronously) find out if it failed".
>>
>> At this time no such language features have been added yet (but we know
>> they will be).
>>
>
Thanks! That helps significantly :)

>
>
> Specification
> https://www.w3.org/TR/webgpu/#gpuwgsllanguagefeatures
>
> Summary
>
> Adds the `wgslLanguageFeatures` getter on the GPU object for
> WebGPU, and its corresponding `WGSLLanguageFeatures` type.
>
>
> Blink component Blink>WebGPU
> 
>
> Motivation
>
> None
>
>
> Initial public proposal None
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>

>>> Can y'all ask for a signal? https://bit.ly/blink-signals
>>>
>>
>> The API was collaboratively designed and approved by the W3C community
>> group with approval from Mozilla/Apple. Is that sufficient?
>>
>> https://github.com/gpuweb/gpuweb/wiki/Minutes-2023-03-08#add-query-for-list-of-wgsl-software-extensions-3875
>>
>> 

Re: [blink-dev] Scroll to Text Fragment - Gmail doesn't preview the link

['David Bokan' via blink-dev]

Text fragments work just fine from `window.open` but have restrictions 
about being isolated from other pages. I suspect gmail isn't adding 
`noopener` in window.open so that the opened page remains reachable from 
gmail.

If that's the case, your link should work if you ctrl/cmd-click the link or 
right-click>"open in new tab".

On Monday, May 8, 2023 at 7:32:58 AM UTC-4 PhistucK wrote:

> Looks like the issue is that opening a URL with a scroll-to-fragment via 
> window.open(...) does not scroll/highlight. GMail uses window.open(...) 
> in draft mode.
>
> Here is a small test case (copy it and paste it in the address bar and 
> click on both of the links) -
> data:text/html,window.open
>  
> normal
>  
> href
>
>
> There is also some weird handling of the fragment. If you unescape more 
> than one of the commas (%2C), it stops highlighting -
> data:text/html,normal
>  
> href with one unescaped comma normal
>  
> href with two unescaped commas
>
> Note that the URL you mentioned does not really have an accurate 
> scroll-to-fragment, it uses %22 for all quotes, but the page uses special 
> types of quotes (not sure why it works, but maybe there is 
> some pre-processing for easier URL creation).
>
>
> You can report this at crbug.com. Be sure to search for an existing issue 
> first, though.
>
>
>
> ☆*PhistucK*
>
>
> On Wed, May 3, 2023 at 1:02 AM Michael Bradley  wrote:
>
>> When drafting a gmail with a link containing a *ScrollToTextFragment*,  
>> Duties 
>> of Loyalty, Care and Obedience 
>> ,
>>  
>> clicking on the link (in Draft) shows the dialog, "Go to link: https ... 
>> | Change | Remove", but following the link to test my intention to 
>> scroll merely loads the target webpage.
>>
>> However, sending the draft to a Yahoo email renders the highlighted text 
>> on the target webpage.  This is the desired result, but it would be more 
>> convenient to verify the intended behavior when testing the link in the 
>> draft.
>>
>> Windows 10 Home 22H2 1/‎14/‎2021 Build: 19045.2846 
>> Chrome Version 112.0.5615.138 (Official Build) (64-bit)
>> GMail: 05-02-2023, No Add-ons, Advanced: all disabled.
>>
>> I understand the desire to disable this behavior, but I appreciate what 
>> this feature can do, as demonstrated in this link.
>>
>> -- 
>> 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/2650c78e-e0f4-4d5d-9918-62a6ece72c1cn%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/45594dcf-62d0-4165-a0f4-cce65821b6e2n%40chromium.org.

Re: [blink-dev] Intent to Ship: Private State Tokens API

['Steven Valdez' via blink-dev]

We've merged the permissions policy integration into the spec document.

On Fri, May 5, 2023 at 1:14 PM Steven Valdez  wrote:

> Rick: For the spec work, we've merged the type parameter removal into the
> spec and have a PR  to
> add the permission policy integration. We've already updated Chrome for
> both of those changes.
>
> Mike: We would be checking enrollment/attestation when the issuer
> update/re-register their key commitments rather than on the browser at
> run-time, so it wouldn't need defined user-agent behavior. Some mechanism
> for verifying attestations on an ongoing basis seems like it would add
> additional value, but that would be future work.
>
>
> On Wed, May 3, 2023 at 11:45 AM Mike West  wrote:
>
>> I agree with Rick on the merits, but would point out one aspect of the
>> enrollment mechanism that I think does have interop considerations that
>> Chromium needs to consider. If embedders have a gate on issuance, we need
>> to ensure that both sides of that gate have defined developer-facing
>> behavior. It's not clear to me how enrollment status is represented in the
>> spec, whether relevant errors are surfaced to developers through devtools,
>> etc. Have y'all thought through that distinction from the platform
>> perspective?
>>
>> -mike
>>
>>
>> On Wed, May 3, 2023 at 4:15 AM Rick Byers  wrote:
>>
>>> Looking through the open issues and Martin's great feedback, it seems
>>> pretty clear that there are some significant interoperability risks here
>>> still. That said, Chrome's inability to remove 3PCs until we can
>>> demonstrate adequate replacements is also an ongoing interop (and privacy)
>>> cost for the web. As with most things privacy sandbox related, I'm
>>> personally leaning more towards a ship-and-iterate model being less bad
>>> than risking delaying the 3PCD timeline
>>> .
>>>
>>> That said, it looks like there's at least a little low hanging fruit
>>> remaining in spec work. Eg. this issue
>>>  suggests we've
>>> implemented an API (permissions policy integration) in chromium that isn't
>>> spec'd out, is that right? Permissions policy is usually pretty straight
>>> forward to integrate these days, right? Any reason we can't just get that
>>> landed in the spec now before shipping? Also there's a few discussions of 
>>> removing
>>> the type parameter ,
>>> can we just do that now to reduce the need for a breaking change analysis
>>> in the future? If we can get these spec fixes landed quickly, then I'm
>>> personally willing to approve this I2S with the expectation of continued
>>> spec investment and cross-browser alignment.
>>>
>>> There's clearly also a lot to discuss about the enrollment mechanism
>>> 
>>>  shared
>>> by a number of privacy sandbox APIs, but I see that as a Chrome
>>> implementation detail, not something necessarily subject to the web
>>> standards process (though certainly still open to public scrutiny and
>>> debate).
>>>
>>> Rick
>>>
>>>
>>>
>>> On Fri, Apr 28, 2023 at 1:23 PM Steven Valdez 
>>> wrote:
>>>
 Thanks for the feedback, I've replied on Github with the reasoning and
 to continue the conversation. There's definitely some spec work to make
 the  registration behavior clearer.

 -Steven

 On Wed, Apr 26, 2023 at 9:59 PM Martin Thomson  wrote:

> I just raised https://github.com/WICG/trust-token-api/issues/240
> based on this.  I had missed that you were planning to register issuers.
> See the issue for more.
>
> On Thu, Apr 27, 2023 at 6:31 AM Steven Valdez 
> wrote:
>
>> We've added this as a WIP document in the repository:
>> https://github.com/WICG/trust-token-api/blob/main/REGISTRATION.md.
>>
>> While the WICG repo won't be the final resting place for the
>> policy/registration hopefully that works as an interim until we've got 
>> the
>> final repo/policy published.
>>
>> On Wed, Apr 26, 2023 at 3:51 PM Rick Byers 
>> wrote:
>>
>>> Thanks Steven, sorry I missed that. +1 to getting it on GitHub and
>>> links updated.
>>>
>>> Rick
>>>
>>> On Wed, Apr 26, 2023 at 3:09 PM Mike Taylor 
>>> wrote:
>>>
 On 4/26/23 12:07 PM, Steven Valdez wrote:

 From higher in the thread:

 The WIP registration document is at
 https://docs.google.com/document/d/1oB_YdRMvQWWAsqXsvxMr4FJCngcSBj2rLJzW15l8a_A/edit?usp=sharing
 .

 We're planning on hosting it on a Github repo and using that as the
 source of truth for issuer registrations.

 We have a slightly chicken and egg problem where setting up the
 Github repo is 

[blink-dev] Re: Intent to Ship: timestamp field on RTCEncodedVideoFrameMetadata

['Tony Herre' via blink-dev]

Thanks for the reply - hard to judge how much context to include for small
launches like this.

The motivation is in helping WebRTC web applications which are using
both Mediacapture
Transforms  to modify raw
audio/video (adding video effects, background replace etc) and WebRTC
Encoded Transforms  for
modifying the WebRTC encoded data which gets sent on over the network (to
do client-side encryption, appending additional application metadata within
the media, observing per-frame WebRTC metadata like ContributingSources
etc).
Adding this `timestamp` field to RTCEncodedVideoFrameMetadata means that,
when getting an encoded video frame in the encoded transform, the app can
now tell which raw video frame in the mediacapture transform was encoded to
produce this (or when receiving video, which raw frame is later
produced after decoding this encoded frame), by matching
RTCEncodedVideoFrameMetadata.timestamp with VideoFrame.timestamp
.

With this, the application can coordinate the two transforms a lot better -
eg changing how raw frames are processed or rendered on the exact frame in
which webrtc metadata changed, or change details of the encoded data on the
exact frame when something in the raw video transform was changed.

As for developer interest, I'm working closely with at least one quick
adopter, and the quick agreement in the WebRTC Working Group shows this is
generally useful and a part of the roadmap.

Thanks!

On Mon, 8 May 2023 at 16:21, Nicola Tommasi  wrote:

> Hi Tony,
>
> Thanks for this intent, could you please clarify why this new field is
> needed and important?Without an explainer is hard to follow this change.
>
> Cheers,
> Nicola
>
> On Tuesday, May 2, 2023 at 2:29:22 PM UTC Tony Herre wrote:
>
>> Contact emails
>>
>> he...@google.com, gui...@chromium.com
>>
>> Spec
>> https://w3c.github.io/webrtc-encoded-transform/#RTCEncodedVideoFrameMetadata
>> particularly
>> PR#173 .
>>
>>
>> Summary
>>
>> Add a 'timestamp' field to RTCEncodedVideoFrameMetadata containing the
>> presentation timestamp of the associated encoded video frame.
>>
>> Is this feature supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Positive response from all members at W3C WebRTC WG April 2023 Interim,
>> PR landed with no open issues.
>>
>> Ergonomics
>>
>> Added specifically to align with the timestamp field on the WebCodecs
>> 
>> EncodedVideoChunk
>> , and
>> allow matching video frames with the timestamp in the WebCodecs
>> VideoFrame 
>> object.
>>
>> Will also provide the same timestamp already exposed in
>> requestVideoFrameCallback's 'mediaTime'.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Tested internally by RTCEncodedVideoFrame-capture-timestamp-id.html
>> ,
>> upstreaming to WPT tracked in crbug.com/1441888.
>>
>>
>>
>> Entry on the feature dashboard
>>
>> None, small delta to launched API.
>>
>

-- 
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/CAArnMxFuMAb_rsoynj2XDDZtSQ8-zZmVtxg3Crd-HimnK-5Exw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Boolean Context Style Container Queries

[Philip Jägenstedt]

LGTM2

On Wed, May 3, 2023 at 11:35 PM Manuel Rego Casasnovas 
wrote:

> LGTM1
>
> On 03/05/2023 14:22, Rune Lillesveen wrote:
> >
> > Contact emails
> >
> > futh...@chromium.org 
> >
> >
> > Explainer
> >
> > None
> >
> >
> > Specification
> >
> > https://drafts.csswg.org/css-contain-3/#style-container
> > 
> >
> >
> > Summary
> >
> > Support style() container queries without a declaration value, only a
> > property name, as a way of matching non-initial values. Previously you
> > would have to do: not style(--my-property: initial) Now you can do:
> > style(--my-property) to match any non-initial value.
> >
> >
> >
> > Blink component
> >
> > Blink>CSS
> > <
> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
> >
> >
> > TAG review
> >
> > None
> >
> >
> > TAG review status
> >
> > Not applicable
> >
> >
> > Risks
> >
> >
> > This is a minor change in the existing style() queries API. No new
> > standards positions. Chrome shipped style() queries for custom
> > properties in M111, but none of the other browsers have.
> >
> > The effect on existing content is that boolean context style queries
> > that currently parse as  and evaluate to 'unknown'
> > will start evaluating to true/false depending on computed value. It is
> > so unlikely that existing content will be affected by this that it does
> > not seem to be worth the effort to measure.
> >
> >
> > Interoperability and Compatibility
> >
> >
> >
> > /Gecko/: No signal
> > (https://github.com/mozilla/standards-positions/issues/686
> > )
> >
> > /WebKit/: No signal
> > (https://github.com/WebKit/standards-positions/issues/57
> > )
> >
> > /Web developers/: No signals
> >
> > /Other signals/:
> >
> >
> >
> >
> > Debuggability
> >
> > Works
> >
> >
> > 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
> > <
> https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md
> >?
> >
> > Yes
> >
> > Tests added for custom property queries under:
> >
> >
> http://wpt.fyi/css/css-contain/container-queries/at-container-style-parsing.html
> <
> http://wpt.fyi/css/css-contain/container-queries/at-container-style-parsing.html
> >
> >
> http://wpt.fyi/css/css-contain/container-queries/at-container-style-serialization.html
> <
> http://wpt.fyi/css/css-contain/container-queries/at-container-style-serialization.html
> >
> >
> http://wpt.fyi/css/css-contain/container-queries/custom-property-style-queries.html
> <
> http://wpt.fyi/css/css-contain/container-queries/custom-property-style-queries.html
> >
> >
> >
> >
> > Flag name
> >
> > #enable-experimental-web-platform-features
> >
> >
> > Requires code in //chrome?
> >
> > False
> >
> >
> > Tracking bug
> >
> > https://crbug.com/1442183 
> >
> >
> > Estimated milestones
> >
> > Shipping on desktop   115
> > DevTrial on desktop   114
> >
> > Shipping on Android   115
> > DevTrial on Android   114
> >
> > Shipping on WebView   115
> >
> >
> >
> > Anticipated spec changes
> >
> > Resolved in [1], first PR merged [2], and a second spec-text-tweak PR to
> > be merged [3].
> >
> >
> > [1]
> https://github.com/w3c/csswg-drafts/issues/8127#issuecomment-1479871971 <
> https://github.com/w3c/csswg-drafts/issues/8127#issuecomment-1479871971>
> >
> > [2] https://github.com/w3c/csswg-drafts/pull/8729
> > 
> >
> > [3] https://github.com/w3c/csswg-drafts/pull/8756
> > 
> >
> >
> > Link to entry on the Chrome Platform Status
> >
> > https://chromestatus.com/feature/6332337266098176
> > 
> >
> >
> > Links to previous Intent discussions
> >
> >
> >
> > This intent message was generated by Chrome Platform Status
> > .
> >
> > --
> > 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/CACuPfeQszxjQghv1Gu7huZxNrWOCT0GS_9YEDmqejdont8%3D6_Q%40mail.gmail.com
> <
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeQszxjQghv1Gu7huZxNrWOCT0GS_9YEDmqejdont8%3D6_Q%40mail.gmail.com?utm_medium=email_source=footer
> >.
>
> --

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

['Fergal Daly' via blink-dev]

On Mon, 8 May 2023 at 17:51, Rick Byers  wrote:

> Hi Fergal,
> It's exciting to see this moving forward! Just to clarify, this is
> effectively an I2S for the unload permissions-policy, is that right? Or are
> you also requesting permission to stop firing unload events now too?  The
> latter is going to require some significant compat analysis, but could be
> greatly informed by the experience of having some top-level sites opt-out
> of unload for their frame tree.
>

Thanks.

We're not requesting permission to stop firing at this point. It is the
far-away end-point.


>
> Any plan to trigger a deprecation warning / report for the installation of
> unload handlers? It might be tricky to find a good balance of useful
> warnings without being too spammy.
>

Permission policy will do this as is with a console warning and
Reporting-API if you attempt to install a handler that is disallowed by
policy.


>
> A couple more questions / comments inline:
>
> On Mon, May 8, 2023 at 7:43 AM Fergal Daly  wrote:
>
>> Contact emails
>>
>> fer...@chromium.org, kenjibah...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md
>>
>> Specification
>>
>> https://github.com/whatwg/html/pull/7915
>>
>
> This is still marked as draft. Can you get this ready for review? If it's
> blocked only on having a 2nd implementor show support, then I'd be fine
> shipping based on a PR. But we should at least do what we can to solicit
> feedback on the spec change prior to shipping.
>

Yes. There's nothing in the spec change that isn't in the requests for
positions but since neither of those are supportive yet, I have not asked
for review of the PR. I'm hopeful that once we have data on use on unload
in subframe navigations as discussed here

that
Mozilla will be supportive. Those metrics are in 113 but based on the data
from beta, we need to change how we record them.


> Summary
>>
>> A Permission-Policy for creating unload event listeners will be added.
>>
>> Initially, the default policy will be set to allow. From there, Chrome
>> will gradually migrate the default policy to deny (i.e. increasingly
>> disallow the creation of unload event listeners, eventually reaching a
>> state where deny fully becomes the default policy). The ultimate goal is
>> to remove support for unload event.
>>
>> Blink component
>>
>> Blink>PermissionsAPI
>> 
>>
>> Motivation
>>
>> The unload event is extremely unreliable. It is ignored in most cases by
>> all mobile browsers except Firefox on Android. Furthermore, in Safari, the
>> unload event is ignored on both desktop & mobile platforms.
>>
>> In the current state, unload is a major BFCache blocker (~18 percentage
>> points reduction of hit rate for Chrome).
>>
>> The change  will unlock a large fraction of that hit-rate while providing
>> an opt-out for those who need more time to migrate. It also sends a clear
>> signal that unload should not be used in new development.
>>
>> Sidenote: the spec was changed to say that unload should only run if the
>> page cannot enter BFCache, which reflects Safari’s behavior, However
>> neither Chrome nor Mozilla have implemented this behavior. In Chrome's
>> case, we believe that this would suddenly break various sites and would
>> make it hard for developers to know if/when unload may run.
>>
>>
>> Initial public proposal
>>
>> None
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/738
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> If no other browsers implement this, there is a risk that devs continue
>> to use unload widely and pages malfunction on chrome. However given that
>> alternatives to unload exist it seems entirely possible for sites that are
>> actively maintained to move off unload.
>>
>> Gecko: (
>> https://github.com/mozilla/standards-positions/issues/691#issuecomment-1484997320)
>> It's possible that pages are depending on `unload` handlers in subframes
>> for functionality even without any main frame navigation. We should try to
>> understand how common this is before breaking it. It should be possible to
>> measure how often subframe unloads fire when the mainframe is not
>> navigating. This will give us an upper bound on the size of the problem, -
>> Chrome: we have landed code to measure the occurrence of unload in
>> different scenarios. We will report back the findings.
>>
>> WebKit: https://github.com/WebKit/standards-positions/issues/127
>>
>
> From a quick skim, it sounds like WebKit is already happy with their
> tradeoff of not firing unload and doesn't see a need for an API that
> reduces unload further, is that about right? WebKit has mostly shipped
> heuristics here without trying to spec them first, right? In general I'm
> 

[blink-dev] Re: Intent to extend origin trial: Pending Beacon API

[Yoav Weiss]

LGTM to extend experimentation M113-115

I appreciate your engagement with WebKit & Fetch folks and your willingness
to modify the API shape based on feedback. I think that can easily count as
progress towards shipping, which is required for extending the OT. The fact
that the current shape is unlikely to ship as is is also reassuring (as it
reduces the risk of burn-in following a long trial).

On Tue, May 9, 2023 at 8:03 AM Ming-Ying Chung  wrote:

> API owners,
>
> We would like to extend the origin trial for 3 additional milestones, with
> the extension starting in 113 continuing through 115. The OT
>  was previously
> approved
> 
> to run from 107 to 112 (OT token expires on 2023-06-02).
>
> Contact emails
>
> m...@chromium.org, fer...@chromium.org, denom...@chromium.org,
> pending-beacon-experim...@google.com
>
> Explainer
>
> https://github.com/WICG/pending-beacon/blob/main/README.md
>
> Specification
>
> https://wicg.github.io/pending-beacon/
>
> Design docs
>
>
> https://docs.google.com/document/d/1QIFUu6Ne8x0W62RKJSoTtZjSd_bIM2yXZSELxdeuTFo/edit?pli=1
>
> Summary
>
> A stateful PendingBeacon API allows website authors to specify one or
> more beacons (HTTP requests) that should be sent reliably when the page is
> being unloaded.
>
>
>
> Existing beacon APIs are all based around a developer constructing and
> sending a beacon, and there's no good time for that "send" call to be made.
> (Handlers such as 'unload' are often ignored, for example.) This API
> delegates the sending to the browser itself, so it can support beacons on
> page unload or on page hide, without the developer having to implement send
> calls at exactly the right times.
>
> Blink component
>
> UI>Browser>Navigation>BFCache
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/776
>
> TAG review status
>
> Pending
>
> Risks
>
> N/A
>
>
> Interoperability and Compatibility
>
>
>
>
>
> Gecko: pending further feedback:
> https://github.com/mozilla/standards-positions/issues/703
>
>
>
> WebKit: Positive signal (closed):
> https://github.com/WebKit/standards-positions/issues/85 /
>
>
>
> Web developers: No signals
>
>
>
> Other signals: ongoing API discussion in
> https://github.com/WICG/pending-beacon/issues/70
>
>
> Ergonomics
>
> N/A
>
>
>
>
> Activation
>
>
> Security
>
>
> Goals for experimentation
>
>-
>
>Collect usability feedback about the current API shape to decide how
>to improve the API design
>-
>
>Collect stability metrics of the current API implementation
>
> Reason this experiment is being extended
>
> The new API shape is currently being discussed with WebKit Fetch folks. It
> is unlikely that we will ship the current OT version of the API.
>
>
> At the same time, we have received additional feedback after the previous
> OT extension. There are users currently trying to evaluate the API with
> their usage and need more time to collect the metrics, but our OT token
> will expire in early June. We would like to request an extension to help
> both of us.
>
>
>
> Ongoing technical constraints
>
> See “What’s not supported
> 
> ”
>  Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
>
> Flag name
>
> --enable-features=PendingBeaconAPI
>
> or via Origin Trial Token
> 
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1293679
>
>
> Launch bug
>
> https://launch.corp.google.com/launch/4200808
>
>
> Estimated milestones
>
> OriginTrial desktop last (new request)
>
> 115
>
> OriginTrial desktop last
>
> 112
>
> OriginTrial desktop first
>
> 107
>
> OriginTrial desktop last (new request)
>
> 115
>
> OriginTrial Android last
>
> 112
>
> OriginTrial Android first
>
> 107
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5690553554436096
>
>
> Links to previous Intent discussions
>
> Intent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/tPTRZkSmlbg/m/6oYq7FtHBAAJ
>
> Intent to Experiment:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/Vd6RTIfxkiY/m/HECcgiDOAAAJ
> Read for Trial:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/CE3ngAKFil4/m/wG-ziOFGAQAJ
>

-- 
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] Intent to extend origin trial: Pending Beacon API

[Ming-Ying Chung]

API owners,

We would like to extend the origin trial for 3 additional milestones, with
the extension starting in 113 continuing through 115. The OT
 was previously approved

to run from 107 to 112 (OT token expires on 2023-06-02).

Contact emails

m...@chromium.org, fer...@chromium.org, denom...@chromium.org,
pending-beacon-experim...@google.com

Explainer

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

Specification

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

Design docs

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

Summary

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



Existing beacon APIs are all based around a developer constructing and
sending a beacon, and there's no good time for that "send" call to be made.
(Handlers such as 'unload' are often ignored, for example.) This API
delegates the sending to the browser itself, so it can support beacons on
page unload or on page hide, without the developer having to implement send
calls at exactly the right times.

Blink component

UI>Browser>Navigation>BFCache


TAG review

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

TAG review status

Pending

Risks

N/A


Interoperability and Compatibility





Gecko: pending further feedback:
https://github.com/mozilla/standards-positions/issues/703



WebKit: Positive signal (closed):
https://github.com/WebKit/standards-positions/issues/85 /



Web developers: No signals



Other signals: ongoing API discussion in
https://github.com/WICG/pending-beacon/issues/70


Ergonomics

N/A




Activation


Security


Goals for experimentation

   -

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

   Collect stability metrics of the current API implementation

Reason this experiment is being extended

The new API shape is currently being discussed with WebKit Fetch folks. It
is unlikely that we will ship the current OT version of the API.


At the same time, we have received additional feedback after the previous
OT extension. There are users currently trying to evaluate the API with
their usage and need more time to collect the metrics, but our OT token
will expire in early June. We would like to request an extension to help
both of us.



Ongoing technical constraints

See “What’s not supported

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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


Flag name

--enable-features=PendingBeaconAPI

or via Origin Trial Token



Tracking bug

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


Launch bug

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


Estimated milestones

OriginTrial desktop last (new request)

115

OriginTrial desktop last

112

OriginTrial desktop first

107

OriginTrial desktop last (new request)

115

OriginTrial Android last

112

OriginTrial Android first

107


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5690553554436096


Links to previous Intent discussions

Intent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/tPTRZkSmlbg/m/6oYq7FtHBAAJ

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

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