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

['Kenji Baheux' via blink-dev]

Hi Rick,

Some extra details in case it helps:

   - Enterprise/Edu environments: the default behavior will be controllable
   via a dedicated group policy (i.e. admins will have the option to opt-out),
   and we have drafted a heads-up in the next Chrome for Enterprise release
   notes.
   - Killswitch wise, the default behavior will be controlled via finch
   flag(s).



On Mon, May 8, 2023 at 11:31 PM Rick Byers  wrote:

> On Mon, May 8, 2023 at 10:51 AM 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.
>>
>> 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.
>>
>> 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.
>>
>> 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
>> not too concerned
>>
>
> Whoops, looks like I didn't finish this sentence (a freudian slip
> perhaps!). What I intended to convey is that given WebKit's state here, I'm
> not too concerned 

[blink-dev] Intent to Prototype: Scroll Start

[David Awogbemila]

Contact emailsawogbem...@google.com, arg...@google.com

Explainer
https://github.com/argyleink/ScrollSnapExplainers/tree/main/css-scroll-start

SpecificationNone

Summary

Enable setting initial scroll positions via CSS properties. Scroll
experiences don't always start at the beginning. Interactions with
carousels, swipe controls, and listviews often start somewhere in the
middle, and each require Javascript to set this position on page load. By
enabling CSS to specify this scroll start position, both users, page
authors and browsers benefit.


Blink componentBlink>Scroll


Motivation

Please see summary.


Initial public proposal
https://drafts.csswg.org/css-scroll-snap-2/#scroll-start

TAG reviewNone

TAG review statusPending

Risks


Interoperability and Compatibility

None


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

None


Debuggability

None


Is this feature fully tested by web-platform-tests

?No

Flag nameNone

Requires code in //chrome?False

Estimated milestones

No milestones specified


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

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/CAA6pwF7SXKCsUiA0-eNNj%3D3jxMUiJyc3AJDVpo45A1Nf6qksVw%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: "is-cross-site" bit in the HTTP Cache Partitioning Key

[Mike West]

Hey Andrew!

On Tue, May 2, 2023 at 4:41 PM Andrew Williams  wrote:

> Contact emails
>
> awil...@chromium.org
>
> Explainer
>
> This change is not covered by an explainer, but the following are related:
>
> https://github.com/shivanigithub/http-cache-partitioning
>
>
> https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md
>
> Spec
>
> https://fetch.spec.whatwg.org/#http-cache-partitions
>
> https://fetch.spec.whatwg.org/#network-partition-keys
>
> Summary
>
> To protect users from multiple types of cross-site data leak attacks, the
> HTTP cache was partitioned
>  based on the
> top-level site and the frame site. In other words, cache entries for a
> given URL created from third-party contexts (e.g., a ‘b.com’ iframe
> embedded on ‘a.com’) are stored separately from those from first-party
> contexts (‘a.com’, or an ‘a.com’ iframe embedded on ‘a.com’) and other
> third-party contexts (a ‘c.com’ iframe embedded on ‘a.com’).
>
> Other shared network state was recently partitioned
>  as well, but using a
> different partitioning scheme - instead of using the top-level site and the
> frame site, network state in third-party contexts is partitioned by the
> top-level site and whether the frame site is cross-site from the top-level
> site. Using this "is-cross-site" bit instead of the frame site was chosen
> as a balance between security and performance after running experiments and
> measuring the results.
>
> The change proposed here is to replace the frame site in the HTTP cache
> partitioning scheme with an "is-cross-site" bit to perform similar
> experimentation. Using the examples above, this change means that a ‘b.com’
> iframe embedded on ‘a.com’ would now share an HTTP cache partition with a
> ‘c.com’ iframe embedded on ‘a.com’, since the “is-cross-site” bit for
> both would be set to true (and since the top-level site for both is ‘a.com
> ’).
>
> Blink component
>
> Internals>Network>Cache
> 
>
> TAG review
>
> Not requested at this time
>
> TAG review status
>
> N/A
>
> RisksInteroperability and Compatibility
>
> No interoperability / compatibility risks are expected, since the caching
> behavior generally only affects site performance , and in this case the
> change should result in performance improvements
>
> Gecko: N/A, but their implementation doesn’t partition by frame site or
> “is-cross-site”;
>
> WebKit: N/A, but their implementation doesn’t partition by frame site or
> “is-cross-site”;
>
> Web developers: No signals
>
> Other signals: N/A
>
> WebView application risks
>
> None, since HTTP cache partitioning is not enabled for WebView
>
> Security
>
> One side effect of this change is that a malicious cross-site iframe will
> now share an HTTP cache partition with other cross-site iframes under the
> same top-level site. This allows the malicious cross-site iframe to perform
> data leak attacks against the other cross-site iframes via HTTP cache
> probing. It’s unclear how useful this attack primitive would be in
> practice, since the data available to the attacker would still be
> partitioned by the top-level site, and since construction of a page to take
> advantage of this weakness (for instance, a phishing page where a victim
> site is in one cross-site iframe) could be thwarted by X-Frame-Options /
> CSP’s frame-ancestors option.
>

I'm not sure I agree. There are plenty of interesting frames that are happy
with being embedded in a wide variety of sites (YouTube, Maps, Ads, payment
providers like Stripe, single-sign on login forms, etc), and it seems
reasonable to assume that being able to gain insight into their state would
be a risk they'd rather avoid. The current partitioning scheme does that,
changing the model seems like a regression.

I don't object to the experiment, but I'd like to see a little more
analysis of risk here so that we can take that into account when making
decisions about performance deltas.

-mike


>
> Goals for experimentation
>
> This experiment aims to identify what effect the new partitioning scheme
> has on the Chrome guiding metrics/vital metrics, and on other metrics that
> are influenced by the performance of the HTTP cache.
>
> Also, one specific side-effect of this change is that iframes with opaque
> origins (for instance, those created using data: URLs) may now be eligible
> to have their resources added to the HTTP cache. We aim to measure what
> changes in performance result from this.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> This feature will be supported on all six Blink platforms, but note that
> HTTP cache partitioning is only enabled-by-default for Chrome desktop and
> mobile platforms (but not WebView).
>
> Flag name
>
> 

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

['Ben Wiser' via blink-dev]

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

Re: [blink-dev] PSA: Adding WebDriver commands for interacting with FedCM dialogs

[Christian Biesinger]

On Mon, May 8, 2023 at 4:46 AM Philip Jägenstedt 
wrote:

> Hi Christian,
>
> Thanks for sending this PSA, and thank you for careful attention to
> testability of FedCM. It's extra work, but if history is any guide it will
> make FedCM more interoperable, and web developers will rejoice!
>
> WebDriver changes don't need to go through the Blink launch process, but a
> few comments that I'd say if this was an Intent to Ship :)
>
> I see that https://github.com/fedidcg/FedCM/pull/465 isn't merged yet, do
> you expect it to be before this is shipped, or is something blocking it?
>

I am hoping to merge it before shipping. I'd like someone from Firefox to
explicitly comment on the PR before doing that if possible.


>
> And can this be tested in web-platform-tests using pytest similar to how
> other WebDriver classic endpoints are tested?
>

I was not aware that wpt contains tests for WebDriver endpoints, I only
know of
https://source.chromium.org/chromium/chromium/src/+/main:chrome/test/chromedriver/test/run_py_tests.py;l=1?q=run_py_tests.py==chromium
(where I am adding tests for the new endpoints)

Can you point me to tests in wpt?


>
> Finally, a bleeding edge question. There are currently no WebDriver BiDi
> extensions in other specs at all, but I wonder if anything about your API
> would change if this was an extension to
> https://w3c.github.io/webdriver-bidi/ and events sent from the browser to
> the automation client become possible? In particular, would you want an
> event that says a FedCM dialog has been opened?
>

Yes, I would love to do this as an event. The underlying devtools protocol
does expose it as an event and it would be great to expose this as one to
webdriver. But I understand webdriver-bidi is not ready yet.

Thanks,
Christian


>
> Best regards,
> Philip
>
> On Thu, May 4, 2023 at 9:32 PM Christian Biesinger <
> cbiesin...@chromium.org> wrote:
>
>> This would be an Intent to Ship, but since this is not web-exposed, my
>> understanding is that the intent process does not apply. Nonetheless, I
>> wanted to give y’all a heads-up about this.
>>
>> Contact emails
>>
>> cbiesin...@chromium.org
>>
>> Explainer
>>
>> None
>>
>> Specification
>>
>> https://github.com/fedidcg/FedCM/pull/465
>>
>> Design docs
>>
>> https://github.com/fedidcg/FedCM/blob/main/proposals/webdriver.md
>>
>> Summary
>>
>> This exposes several WebDriver commands to allow browser automation, such
>> as automated testing, to interact with FedCM dialogs.
>>
>>
>> Blink component
>>
>> Blink>Identity>FedCM
>> 
>>
>> TAG review
>>
>> None
>>
>> TAG review status
>>
>> Not applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> This is not web-exposed.
>>
>>
>> Gecko: Positive (
>> https://github.com/fedidcg/FedCM/pull/395#issuecomment-1384466751) Since
>> this is not web-exposed, I do not think it makes sense to file a standards
>> position request.
>>
>> WebKit: No signal We have no signal from Safari for FedCM in general; as
>> such, we have no signal for this part either
>>
>> Web developers: Positive At least one user is interested and sees the
>> lack of this as a blocker to rolling out FedCM support
>>
>> Other signals:
>>
>> Ergonomics
>>
>> n/a
>>
>>
>> Activation
>>
>> I am planning to also change Selenium to expose Java APIs for these
>> commands, making them easy to use.
>>
>>
>> Security
>>
>> n/a, this is only exposed through WebDriver.
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>>
>> Debuggability
>>
>> This is a debugging feature.
>>
>>
>> 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
>> 
>> ?
>>
>> No -- it will be tested by chromedriver tests
>>
>> Flag name
>>
>> Requires code in //chrome?
>>
>> True
>>
>> Estimated milestones
>>
>> Shipping on desktop
>>
>> 115
>>
>> Shipping on Android
>>
>> 115
>>
>>
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5103072721764352
>>
>> --
>> 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 

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

[Rick Byers]

On Mon, May 8, 2023 at 10:51 AM 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.
>
> 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.
>
> 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.
>
> 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
> not too concerned
>

Whoops, looks like I didn't finish this sentence (a freudian slip
perhaps!). What I intended to convey is that given WebKit's state here, I'm
not too concerned about getting their support for a permission policy or
any particular deprecation path. Chromium almost certainly needs to apply a
lot more diligence in how we manage a deprecation path for unload events,
especially in enterprise environments where Safari is largely unsupported.

Web developers: Positive (
>> https://groups.google.com/a/chromium.org/g/bfcache-dev/c/zTIMx7u4uxo/m/-M4IS6LDBgAJ)
>> The web communities we reached out had positive reactions to our proposal
>> and we have not heard about any concrete blockers.
>>
>> Other signals:
>>

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

[Nicola Tommasi]

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/cfa25949-7d3d-4dfd-920d-e89eab6933d5n%40chromium.org.

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

[PhistucK]

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+unsubscr...@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_LbV3YPsynAhhdhQRDJzpm31fbuzmKGmGmjbucHgNzL3Q%40mail.gmail.com.

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

[Rick Byers]

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 keys.
>>> This behavior is enabled only if the scroller does not contain any keyboard
>>> focusable children. This logic is necessary so we don't cause regressions
>>> for existing focusable elements that might exist within a scroller like a
>>> .
>>>
>>>
>>> Blink component Blink>HTML>Focus
>>> 
>>>
>>> Search tags tab key , 
>>> keyboard
>>> focus , sequential
>>> navigation
>>> 
>>>
>>> TAG review None
>>>
>>> TAG review status Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> This is a change in behavior, but already matches what Firefox is doing
>>> (have scroller be focusable by default). Low compatibility risk since this
>>> default behavior is only enabled if the scroller doesn't have any focusable
>>> children.
>>>
>>>
>>> *Gecko*: Shipped/Shipping Chrome behavior is slightly different since
>>> we are checking if any scroller child is focusable. This is to avoid
>>> regression on existing focus sequences.
>>>
>>> *WebKit*: No signal (https://bugs.webkit.org/show_bug.cgi?id=190870)
>>>
>>> Could you request a signal at
>>> https://github.com/WebKit/standards-positions? It's hard to know if
>>> Ryosuke's comment is still valid since he made it.
>>>
>>>
>>> *Web developers*: Positive (
>>> https://twitter.com/simevidas/status/1444033718742667270)
>>>
>>> *Other 

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

['Noam Rosenthal' via blink-dev]

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.

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

[Rick Byers]

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.

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.

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.

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
not too concerned

Web developers: Positive (
> https://groups.google.com/a/chromium.org/g/bfcache-dev/c/zTIMx7u4uxo/m/-M4IS6LDBgAJ)
> The web communities we reached out had positive reactions to our proposal
> and we have not heard about any concrete blockers.
>
> 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?
>
> On WebView, we will introduce the Permissions-Policy but not move the
> default to "deny". BFCache does not work on WebView, so the benefit is
> lower. Meanwhile the risk seems higher as we have far less visibility into
> the HTML being run in WebViews. A roll-out to WebView should be done
> independently and in consultation with the WebView team.
>

Sounds like the right strategy to me, thanks!


> Debuggability
>
> None
>
> Is this feature 

Re: [blink-dev] PSA: Adding WebDriver commands for interacting with FedCM dialogs

[Philip Jägenstedt]

Hi Christian,

Thanks for sending this PSA, and thank you for careful attention to
testability of FedCM. It's extra work, but if history is any guide it will
make FedCM more interoperable, and web developers will rejoice!

WebDriver changes don't need to go through the Blink launch process, but a
few comments that I'd say if this was an Intent to Ship :)

I see that https://github.com/fedidcg/FedCM/pull/465 isn't merged yet, do
you expect it to be before this is shipped, or is something blocking it?

And can this be tested in web-platform-tests using pytest similar to how
other WebDriver classic endpoints are tested?

Finally, a bleeding edge question. There are currently no WebDriver BiDi
extensions in other specs at all, but I wonder if anything about your API
would change if this was an extension to
https://w3c.github.io/webdriver-bidi/ and events sent from the browser to
the automation client become possible? In particular, would you want an
event that says a FedCM dialog has been opened?

Best regards,
Philip

On Thu, May 4, 2023 at 9:32 PM Christian Biesinger 
wrote:

> This would be an Intent to Ship, but since this is not web-exposed, my
> understanding is that the intent process does not apply. Nonetheless, I
> wanted to give y’all a heads-up about this.
>
> Contact emails
>
> cbiesin...@chromium.org
>
> Explainer
>
> None
>
> Specification
>
> https://github.com/fedidcg/FedCM/pull/465
>
> Design docs
>
> https://github.com/fedidcg/FedCM/blob/main/proposals/webdriver.md
>
> Summary
>
> This exposes several WebDriver commands to allow browser automation, such
> as automated testing, to interact with FedCM dialogs.
>
>
> Blink component
>
> Blink>Identity>FedCM
> 
>
> TAG review
>
> None
>
> TAG review status
>
> Not applicable
>
> Risks
>
> Interoperability and Compatibility
>
> This is not web-exposed.
>
>
> Gecko: Positive (
> https://github.com/fedidcg/FedCM/pull/395#issuecomment-1384466751) Since
> this is not web-exposed, I do not think it makes sense to file a standards
> position request.
>
> WebKit: No signal We have no signal from Safari for FedCM in general; as
> such, we have no signal for this part either
>
> Web developers: Positive At least one user is interested and sees the
> lack of this as a blocker to rolling out FedCM support
>
> Other signals:
>
> Ergonomics
>
> n/a
>
>
> Activation
>
> I am planning to also change Selenium to expose Java APIs for these
> commands, making them easy to use.
>
>
> Security
>
> n/a, this is only exposed through WebDriver.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
> Debuggability
>
> This is a debugging feature.
>
>
> 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
> 
> ?
>
> No -- it will be tested by chromedriver tests
>
> Flag name
>
> Requires code in //chrome?
>
> True
>
> Estimated milestones
>
> Shipping on desktop
>
> 115
>
> Shipping on Android
>
> 115
>
>
>
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5103072721764352
>
> --
> 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/CAPTJ0XFZdXiLw7c6ama%3DE6zm3aVcm377%2B5XAhYqEHa%3D7z%2Bgecg%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/CAARdPYcLkXTG%2B-uZ4p2HiHZeY0bjPe%2BY4Gt-V9n-bGJD%3DX0a1g%40mail.gmail.com.