[blink-dev] Re: Intent to Ship: SerialPort integration with WritableStream controller AbortSignal

2022-02-15 Thread chrishtr via Chromestatus 
LGTM2

-- 
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/d7ea6a05d8134786%40google.com.

Re: [blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

2022-02-15 Thread Domenic Denicola 
On Tue, Feb 15, 2022 at 11:38 AM 'Mustaq Ahmed' via blink-dev <
blink-dev@chromium.org> wrote:

>
>
> On Tue, Feb 15, 2022 at 11:16 AM Chris Harrelson 
> wrote:
>
>> LGTM2 for the extension to 102, but comments below. It would be very good
>> to make progress on landing additional spec pieces.
>>
>> On Tue, Feb 15, 2022 at 8:09 AM 'Mustaq Ahmed' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> I think [1] would be useful for developers but I see two blockers here:
>>> first we need to land the Capability Delegation patch
>>> 
>>> in HTML  spec as a "reference point" for this idea, then the PR for
>>> navigator.userActivation 
>>> needs to land too.
>>>
>>
>> Hi Mustaq,
>>
>> Is there anything blocking integrating the delegation patch into the HTML
>> spec, and landing the PR for userActivation? There seems to be implementer
>> interest from at least Gecko.
>>
>
> - For the Capability Delegation patch
> ,
> yes we are already working with Gecko and will start working on an HTML PR
> soon (see its intent
> 
>  thread).
> - The PR for navigator.userActivation
>  still "needs implementer
> interest" I think, cc-ing dtapuska@ if I missed something.  (Note that
> this is separate from the "user activation v2" model which is already
> spec-ed
> 
> .)
>

At the last HTML triage meeting
 we got
multi-implementer interest and agreement on navigator.userActivation. We
still weren't clear on the use cases for the postMessage() parts of that
PR. So, if you or someone else are willing to split out the PR into two
pieces, we can land the navigator.userActivation piece quickly.


>
>
>> Chris
>>
>>
>>> On Mon, Feb 14, 2022 at 9:51 AM Mike Taylor 
>>> wrote:
>>>
 Thanks for the thoughtful answers!

 LGTM1. I'll trust you to file bugs / feature requests for those 3 items
 (and yeah, 3 sounds like a useful, but hard problem to solve).

 On 2/14/22 9:44 AM, Stephen Mcgruer wrote:

 > Is there anything we can learn about their challenges that might
 apply to the broader ecosystem?

 A little, though largely it appears to be a bug in either
 their application or in Chrome (we're still trying to figure out which!).
 Simplifying, the problem is that they seem to be losing the Capability
 Delegation between click and (in a different iframe) the call to PR.show(),
 and it's quite tricky to debug this in a large async application. I can
 think of a few things that might help:

 1. Adding capability delegation support to navigator.userActivation
  would likely be useful,
 e.g. exposing an array of capabilities currently active. This would make it
 much easier to quickly debug 'do I have a CD right here'. I hope the
 Capability Delegation folks might consider adding this! :)
 2. Pausing user activation timeout when code execution in devtools is
 paused would be useful.
 3. More generally (and more hand-wavingly), being able to more easily
 trace flows through async iframes 'somehow'. Devtools has some support for
 this, and it might just be user error that we and the partner are
 struggling, but when we're trying to answer questions like "Is it possible
 that this event flowed through an intermediary iframe that was created and
 destroyed again before this line of code executed", it can be tricky.

 On Mon, 14 Feb 2022 at 09:27, Mike Taylor 
 wrote:

> Hi Stephen,
>
> Is there anything we can learn about their challenges that might apply
> to the broader ecosystem?
>
> On 2/14/22 9:22 AM, Stephen McGruer wrote:
>
> Hey all,
>
> Unfortunately we've hit a snag in our deprecation; a partner has been
> having trouble integrating this change into their system, and though we 
> are
> engaged in helping them we haven't made much progress yet.
>
> As such, I'm currently requesting that we delay this deprecation *until
> M102*, to give us more time to help solve their problem before we
> require user activation. (I'm not sure how many LGTMs delaying a
> deprecation requires?)
>
> Thanks,
> Stephen
>
> On Tuesday, January 4, 2022 at 10:29:01 AM UTC-5 Stephen McGruer wrote:
>
>> Hey folks,
>>
>> Following up here - we have determined that the remaining uses *do* 
>> necessitate
>> making Capability Delegation available for web developers (see our

Re: [blink-dev] Ready for Trial: Federated Credentials Management API (was WebID)

2022-02-15 Thread Ian Kilpatrick 
Great - thanks! Panos may be the right person to reach out to about this.

Ian

On Tue, Feb 15, 2022 at 10:10 AM Sam Goto  wrote:

>
>
> On Tue, Feb 15, 2022 at 10:06 AM Ian Kilpatrick 
> wrote:
>
>>
>>
>> On Tue, Feb 15, 2022 at 8:59 AM Sam Goto  wrote:
>>
>>> Contact emails
>>>
>>> g...@google.com
>>>
>>> Explainer
>>>
>>> https://github.com/fedidcg/FedCM
>>>
>>> Specification
>>>
>>> https://fedidcg.github.io/FedCM/
>>>
>>> Design docs
>>>
>>> https://github.com/fedidcg/FedCM
>>>
>>> Summary
>>>
>>> A Web Platform API that allows users to login to websites with their
>>> federated accounts in a privacy preserving manner.
>>>
>>> Blink component
>>>
>>> Blink
>>> 
>>>
>>>
>> Should this component be Blink>SecurityFeature>CredentialManagement ?
>>
>
> Ah, yes, thanks! Better yet, we have a Blink > Identity > FedCM
> 
> component!
>
> FWIW, unrelated, but Chris, I think I wasn't able to find that component
> in the chromestatus tool. Will follow up separately.
>
>
>>
>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/622 (early TAG review,
>>> deeper dive next)
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Zero compatibility risk (new API)
>>>
>>> Interoperability risk not yet known, currently working on getting formal
>>> signals
>>>
>>> Gecko: No signal
>>>
>>> WebKit: No signal
>>>
>>> Web developers: No signals
>>>
>>> Other signals: This proposal has been presented in TPAC 2022/2021 and
>>> the last two BlinkOn sessions. This API was initially incubated at the WICG
>>> and is now being developed within the FedID CG
>>>  with attendance of identity providers,
>>> browser vendors and standards experts.
>>>
>>> Goals for experimentation
>>>
>>> Learn about demand, requirements, ergonomics and deployment viability.
>>>
>>> Ongoing technical constraints
>>>
>>>-
>>>
>>>Currently, limited Android only implementation
>>>-
>>>
>>>Currently, only ID tokens provided, no access or refresh tokens
>>>-
>>>
>>>Currently, limited session management functionality (only
>>>front-channel logout)
>>>
>>>
>>> Debuggability
>>>
>>> Basic devtools integration supported (tracking bug
>>> , HOWTO
>>> ). More
>>> to come as we learn.
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> At I2S, we expect the feature to be available on all platforms (Windows,
>>> Mac, Linux, ChromeOS and Android) but WebView. The current
>>> implementation is currently only supported on Android, with Desktop
>>> (Windows/Mac/Linux/ChromeOS) coming next.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes
>>>
>>> DevTrial instructions
>>>
>>> https://github.com/fedidcg/FedCM/blob/main/explainer/HOWTO.md
>>>
>>> Flag name
>>>
>>> fedcm
>>>
>>> Requires code in //chrome?
>>>
>>> True
>>>
>>> Tracking bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1216142
>>>
>>> Launch bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1216142
>>>
>>> Estimated milestones
>>>
>>> Devtrial on Desktop 104
>>>
>>> OriginTrial on Android 101
>>>
>>> DevTrial on Android 100
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/6438627087220736
>>>
>>> Links to previous Intent discussions
>>>
>>> Intent to prototype:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/2B4TJ7j2U4M/m/1X5T3OszCAAJ
>>>
>>>
>>> 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/CALdEk-xvmkkTbnhxO-8oX3G5E1%2BjvvNQ2xAf4TozWZbmi47eEA%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/CAJL3UpRnsuEAPJtvHNhj49yGvUFbgi9mZ3JOBC8GbzmHwsd7Qg%40mail.gmail.com.

Re: [blink-dev] Ready for Trial: Federated Credentials Management API (was WebID)

2022-02-15 Thread Sam Goto 
On Tue, Feb 15, 2022 at 10:06 AM Ian Kilpatrick 
wrote:

>
>
> On Tue, Feb 15, 2022 at 8:59 AM Sam Goto  wrote:
>
>> Contact emails
>>
>> g...@google.com
>>
>> Explainer
>>
>> https://github.com/fedidcg/FedCM
>>
>> Specification
>>
>> https://fedidcg.github.io/FedCM/
>>
>> Design docs
>>
>> https://github.com/fedidcg/FedCM
>>
>> Summary
>>
>> A Web Platform API that allows users to login to websites with their
>> federated accounts in a privacy preserving manner.
>>
>> Blink component
>>
>> Blink
>> 
>>
>>
> Should this component be Blink>SecurityFeature>CredentialManagement ?
>

Ah, yes, thanks! Better yet, we have a Blink > Identity > FedCM

component!

FWIW, unrelated, but Chris, I think I wasn't able to find that component in
the chromestatus tool. Will follow up separately.


>
>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/622 (early TAG review,
>> deeper dive next)
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Zero compatibility risk (new API)
>>
>> Interoperability risk not yet known, currently working on getting formal
>> signals
>>
>> Gecko: No signal
>>
>> WebKit: No signal
>>
>> Web developers: No signals
>>
>> Other signals: This proposal has been presented in TPAC 2022/2021 and the
>> last two BlinkOn sessions. This API was initially incubated at the WICG and
>> is now being developed within the FedID CG 
>> with attendance of identity providers, browser vendors and standards
>> experts.
>>
>> Goals for experimentation
>>
>> Learn about demand, requirements, ergonomics and deployment viability.
>>
>> Ongoing technical constraints
>>
>>-
>>
>>Currently, limited Android only implementation
>>-
>>
>>Currently, only ID tokens provided, no access or refresh tokens
>>-
>>
>>Currently, limited session management functionality (only
>>front-channel logout)
>>
>>
>> Debuggability
>>
>> Basic devtools integration supported (tracking bug
>> , HOWTO
>> ). More
>> to come as we learn.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> At I2S, we expect the feature to be available on all platforms (Windows,
>> Mac, Linux, ChromeOS and Android) but WebView. The current
>> implementation is currently only supported on Android, with Desktop
>> (Windows/Mac/Linux/ChromeOS) coming next.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>> DevTrial instructions
>>
>> https://github.com/fedidcg/FedCM/blob/main/explainer/HOWTO.md
>>
>> Flag name
>>
>> fedcm
>>
>> Requires code in //chrome?
>>
>> True
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1216142
>>
>> Launch bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1216142
>>
>> Estimated milestones
>>
>> Devtrial on Desktop 104
>>
>> OriginTrial on Android 101
>>
>> DevTrial on Android 100
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/6438627087220736
>>
>> Links to previous Intent discussions
>>
>> Intent to prototype:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/2B4TJ7j2U4M/m/1X5T3OszCAAJ
>>
>>
>> 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/CALdEk-xvmkkTbnhxO-8oX3G5E1%2BjvvNQ2xAf4TozWZbmi47eEA%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/CALdEk-zm5nLg6C3-Oi1Ti9%2BTxTk0JKSRgm0Y%3DyxOZoHCrq5ynA%40mail.gmail.com.

Re: [blink-dev] Ready for Trial: Federated Credentials Management API (was WebID)

2022-02-15 Thread Ian Kilpatrick 
On Tue, Feb 15, 2022 at 8:59 AM Sam Goto  wrote:

> Contact emails
>
> g...@google.com
>
> Explainer
>
> https://github.com/fedidcg/FedCM
>
> Specification
>
> https://fedidcg.github.io/FedCM/
>
> Design docs
>
> https://github.com/fedidcg/FedCM
>
> Summary
>
> A Web Platform API that allows users to login to websites with their
> federated accounts in a privacy preserving manner.
>
> Blink component
>
> Blink 
>
>
Should this component be Blink>SecurityFeature>CredentialManagement ?


> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/622 (early TAG review,
> deeper dive next)
>
> TAG review status
>
> Pending
>
> Risks
> Interoperability and Compatibility
>
> Zero compatibility risk (new API)
>
> Interoperability risk not yet known, currently working on getting formal
> signals
>
> Gecko: No signal
>
> WebKit: No signal
>
> Web developers: No signals
>
> Other signals: This proposal has been presented in TPAC 2022/2021 and the
> last two BlinkOn sessions. This API was initially incubated at the WICG and
> is now being developed within the FedID CG 
> with attendance of identity providers, browser vendors and standards
> experts.
>
> Goals for experimentation
>
> Learn about demand, requirements, ergonomics and deployment viability.
>
> Ongoing technical constraints
>
>-
>
>Currently, limited Android only implementation
>-
>
>Currently, only ID tokens provided, no access or refresh tokens
>-
>
>Currently, limited session management functionality (only
>front-channel logout)
>
>
> Debuggability
>
> Basic devtools integration supported (tracking bug
> , HOWTO
> ). More to
> come as we learn.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> At I2S, we expect the feature to be available on all platforms (Windows,
> Mac, Linux, ChromeOS and Android) but WebView. The current implementation
> is currently only supported on Android, with Desktop
> (Windows/Mac/Linux/ChromeOS) coming next.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
> DevTrial instructions
>
> https://github.com/fedidcg/FedCM/blob/main/explainer/HOWTO.md
>
> Flag name
>
> fedcm
>
> Requires code in //chrome?
>
> True
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1216142
>
> Launch bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1216142
>
> Estimated milestones
>
> Devtrial on Desktop 104
>
> OriginTrial on Android 101
>
> DevTrial on Android 100
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/6438627087220736
>
> Links to previous Intent discussions
>
> Intent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/2B4TJ7j2U4M/m/1X5T3OszCAAJ
>
>
> 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/CALdEk-xvmkkTbnhxO-8oX3G5E1%2BjvvNQ2xAf4TozWZbmi47eEA%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/CAJL3UpTX70YDY1BYq4eqpgLoNZPeqfe3PdhWU5r%3DMLRva9wGHg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: AbortSignal.prototype.throwIfAborted

2022-02-15 Thread 'Scott Haseley' via blink-dev 
Sorry for the confusion! This is enabled by default in 100, which should be
reflected in chromestatus now.

On Tue, Feb 15, 2022 at 9:35 AM Joe Medley  wrote:

> Apologies. I keep using 'shipping' in a sloppy way. I should have asked,
> will this be available by default in 100? If so, that number needs to be
> the shipping milestone fields, not the dev trial milestone fields.
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Tue, Feb 15, 2022 at 8:59 AM Scott Haseley 
> wrote:
>
>> Hi Joe -- This is shipping in 100.
>>
>> On Tue, Feb 15, 2022 at 8:45 AM Joe Medley  wrote:
>>
>>> I'm confused about the timeline for this. Is this shipping in 100 or is
>>> it starting a dev trial in 100?
>>>
>>> Joe
>>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Thu, Feb 10, 2022 at 2:54 PM Scott Haseley 
>>> wrote:
>>>
 Contact emailsshase...@chromium.org

 ExplainerDiscussion: https://github.com/whatwg/dom/issues/927
 Examples:
 https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted

 Specification
 https://dom.spec.whatwg.org/#dom-abortsignal-throwifaborted

 Summary

 Throws an AbortSignal's reason if the signal is aborted. This
 convenience method can be used by signal-handling functions to check a
 signal's abort status and propagate the abort reason, e.g. after async
 operations that might change a signal's state.

 Blink componentBlink>DOM
 

 TAG reviewN/A: the feature has been merged into the DOM standard and
 has been shipped in at least one other browser, in line with the criteria
 in
 https://groups.google.com/a/chromium.org/g/blink-dev/c/naqmDmy1iM8/m/lQAJ17CRAQAJ
 .

 TAG review statusNot applicable

 Risks

 Interoperability and Compatibility

 Low risk. This feature is already part of the DOM standard, has web
 platform tests, and is implemented by Safari and Firefox. We'll improve
 eventual interop by shipping this feature.

 Gecko: Shipped/Shipping (
 https://bugzilla.mozilla.org/show_bug.cgi?id=1745372)

 WebKit: Shipped/Shipping (
 https://bugs.webkit.org/show_bug.cgi?id=234127)

 Web developers: Positive. Minor positive feedback (likes) from
 announcement tweets:
 - Safari: https://twitter.com/chris_dumez/status/1469566206516424704
 - Node: https://twitter.com/simonplend/status/1487053107720859648 and
 https://twitter.com/jasnell/status/1466093594129756166

 Other signals:

 Ergonomics

 None; this feature is an ergonomic improvement for AbortSignal users.

 Activation

 The feature has already been implemented in both Safari and Firefox,
 but it would benefit from a polyfill for use in older browser versions.

 Security

 None.

 Debuggability

 Basic tooling only, i.e. autocomplete support for the new AbortSignal
 method will be provided.

 Is this feature fully tested by web-platform-tests
 
 ?Yes (
 https://wpt.fyi/results/dom/abort/event.any.html?label=master&label=experimental&aligned&q=dom%2Fabort
 )

 Flag name--enable-blink-features=AbortSignalThrowIfAborted

 Requires code in //chrome?False

 Tracking bug
 https://bugs.chromium.org/p/chromium/issues/detail?id=1273458

 Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1290443

 MeasurementUseCounter: AbortSignalThrowIfAborted

 Sample links
 https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted#examples

 Estimated milestones
 DevTrial on desktop 100
 DevTrial on android 100
 Link to entry on the Chrome Platform Status
 https://chromestatus.com/feature/5029737100476416

 Links to previous Intent discussionsIntent to prototype:
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3tUkTGZ1VBQm4139zL0n%3De-DO5emVpZE3ukya4Akyu2w%40mail.gmail.com
 


 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

Re: [blink-dev] Intent to Ship: AbortSignal.prototype.throwIfAborted

2022-02-15 Thread 'Joe Medley' via blink-dev 
Apologies. I keep using 'shipping' in a sloppy way. I should have asked,
will this be available by default in 100? If so, that number needs to be
the shipping milestone fields, not the dev trial milestone fields.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Feb 15, 2022 at 8:59 AM Scott Haseley  wrote:

> Hi Joe -- This is shipping in 100.
>
> On Tue, Feb 15, 2022 at 8:45 AM Joe Medley  wrote:
>
>> I'm confused about the timeline for this. Is this shipping in 100 or is
>> it starting a dev trial in 100?
>>
>> Joe
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Thu, Feb 10, 2022 at 2:54 PM Scott Haseley 
>> wrote:
>>
>>> Contact emailsshase...@chromium.org
>>>
>>> ExplainerDiscussion: https://github.com/whatwg/dom/issues/927
>>> Examples:
>>> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted
>>>
>>> Specificationhttps://dom.spec.whatwg.org/#dom-abortsignal-throwifaborted
>>>
>>> Summary
>>>
>>> Throws an AbortSignal's reason if the signal is aborted. This
>>> convenience method can be used by signal-handling functions to check a
>>> signal's abort status and propagate the abort reason, e.g. after async
>>> operations that might change a signal's state.
>>>
>>> Blink componentBlink>DOM
>>> 
>>>
>>> TAG reviewN/A: the feature has been merged into the DOM standard and
>>> has been shipped in at least one other browser, in line with the criteria
>>> in
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/naqmDmy1iM8/m/lQAJ17CRAQAJ
>>> .
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Low risk. This feature is already part of the DOM standard, has web
>>> platform tests, and is implemented by Safari and Firefox. We'll improve
>>> eventual interop by shipping this feature.
>>>
>>> Gecko: Shipped/Shipping (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1745372)
>>>
>>> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=234127
>>> )
>>>
>>> Web developers: Positive. Minor positive feedback (likes) from
>>> announcement tweets:
>>> - Safari: https://twitter.com/chris_dumez/status/1469566206516424704
>>> - Node: https://twitter.com/simonplend/status/1487053107720859648 and
>>> https://twitter.com/jasnell/status/1466093594129756166
>>>
>>> Other signals:
>>>
>>> Ergonomics
>>>
>>> None; this feature is an ergonomic improvement for AbortSignal users.
>>>
>>> Activation
>>>
>>> The feature has already been implemented in both Safari and Firefox, but
>>> it would benefit from a polyfill for use in older browser versions.
>>>
>>> Security
>>>
>>> None.
>>>
>>> Debuggability
>>>
>>> Basic tooling only, i.e. autocomplete support for the new AbortSignal
>>> method will be provided.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes (
>>> https://wpt.fyi/results/dom/abort/event.any.html?label=master&label=experimental&aligned&q=dom%2Fabort
>>> )
>>>
>>> Flag name--enable-blink-features=AbortSignalThrowIfAborted
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1273458
>>>
>>> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1290443
>>>
>>> MeasurementUseCounter: AbortSignalThrowIfAborted
>>>
>>> Sample links
>>> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted#examples
>>>
>>> Estimated milestones
>>> DevTrial on desktop 100
>>> DevTrial on android 100
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5029737100476416
>>>
>>> Links to previous Intent discussionsIntent to prototype:
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3tUkTGZ1VBQm4139zL0n%3De-DO5emVpZE3ukya4Akyu2w%40mail.gmail.com
>>> 
>>>
>>>
>>> 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/CAKXGoJ1w2WYK4X6fA7V4C0xNJBetNb%3D%2BCMywobhzzc9q9xSRxg%40mail.gmail.com
>>> 
>>> .
>>>
>>

-- 
You received this message because you a

Re: [blink-dev] Intent to Ship: AbortSignal.prototype.throwIfAborted

2022-02-15 Thread Scott Haseley 
Hi Joe -- This is shipping in 100.

On Tue, Feb 15, 2022 at 8:45 AM Joe Medley  wrote:

> I'm confused about the timeline for this. Is this shipping in 100 or is it
> starting a dev trial in 100?
>
> Joe
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Thu, Feb 10, 2022 at 2:54 PM Scott Haseley 
> wrote:
>
>> Contact emailsshase...@chromium.org
>>
>> ExplainerDiscussion: https://github.com/whatwg/dom/issues/927
>> Examples:
>> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted
>>
>> Specificationhttps://dom.spec.whatwg.org/#dom-abortsignal-throwifaborted
>>
>> Summary
>>
>> Throws an AbortSignal's reason if the signal is aborted. This convenience
>> method can be used by signal-handling functions to check a signal's abort
>> status and propagate the abort reason, e.g. after async operations that
>> might change a signal's state.
>>
>> Blink componentBlink>DOM
>> 
>>
>> TAG reviewN/A: the feature has been merged into the DOM standard and has
>> been shipped in at least one other browser, in line with the criteria in
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/naqmDmy1iM8/m/lQAJ17CRAQAJ
>> .
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Low risk. This feature is already part of the DOM standard, has web
>> platform tests, and is implemented by Safari and Firefox. We'll improve
>> eventual interop by shipping this feature.
>>
>> Gecko: Shipped/Shipping (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1745372)
>>
>> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=234127)
>>
>> Web developers: Positive. Minor positive feedback (likes) from
>> announcement tweets:
>> - Safari: https://twitter.com/chris_dumez/status/1469566206516424704
>> - Node: https://twitter.com/simonplend/status/1487053107720859648 and
>> https://twitter.com/jasnell/status/1466093594129756166
>>
>> Other signals:
>>
>> Ergonomics
>>
>> None; this feature is an ergonomic improvement for AbortSignal users.
>>
>> Activation
>>
>> The feature has already been implemented in both Safari and Firefox, but
>> it would benefit from a polyfill for use in older browser versions.
>>
>> Security
>>
>> None.
>>
>> Debuggability
>>
>> Basic tooling only, i.e. autocomplete support for the new AbortSignal
>> method will be provided.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes (
>> https://wpt.fyi/results/dom/abort/event.any.html?label=master&label=experimental&aligned&q=dom%2Fabort
>> )
>>
>> Flag name--enable-blink-features=AbortSignalThrowIfAborted
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1273458
>>
>> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1290443
>>
>> MeasurementUseCounter: AbortSignalThrowIfAborted
>>
>> Sample links
>> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted#examples
>>
>> Estimated milestones
>> DevTrial on desktop 100
>> DevTrial on android 100
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5029737100476416
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3tUkTGZ1VBQm4139zL0n%3De-DO5emVpZE3ukya4Akyu2w%40mail.gmail.com
>> 
>>
>>
>> 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/CAKXGoJ1w2WYK4X6fA7V4C0xNJBetNb%3D%2BCMywobhzzc9q9xSRxg%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/CAKXGoJ3z4j7%2Bi7RGRPqoPNWAj-LUoK0v2UK2souiWejws29AEA%40mail.gmail.com.

[blink-dev] Ready for Trial: Federated Credentials Management API (was WebID)

2022-02-15 Thread Sam Goto 
Contact emails

g...@google.com

Explainer

https://github.com/fedidcg/FedCM

Specification

https://fedidcg.github.io/FedCM/

Design docs

https://github.com/fedidcg/FedCM

Summary

A Web Platform API that allows users to login to websites with their
federated accounts in a privacy preserving manner.

Blink component

Blink 

TAG review

https://github.com/w3ctag/design-reviews/issues/622 (early TAG review,
deeper dive next)

TAG review status

Pending

Risks
Interoperability and Compatibility

Zero compatibility risk (new API)

Interoperability risk not yet known, currently working on getting formal
signals

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals: This proposal has been presented in TPAC 2022/2021 and the
last two BlinkOn sessions. This API was initially incubated at the WICG and
is now being developed within the FedID CG 
with attendance of identity providers, browser vendors and standards
experts.

Goals for experimentation

Learn about demand, requirements, ergonomics and deployment viability.

Ongoing technical constraints

   -

   Currently, limited Android only implementation
   -

   Currently, only ID tokens provided, no access or refresh tokens
   -

   Currently, limited session management functionality (only front-channel
   logout)


Debuggability

Basic devtools integration supported (tracking bug
, HOWTO
). More to
come as we learn.

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

At I2S, we expect the feature to be available on all platforms (Windows,
Mac, Linux, ChromeOS and Android) but WebView. The current implementation
is currently only supported on Android, with Desktop
(Windows/Mac/Linux/ChromeOS) coming next.

Is this feature fully tested by web-platform-tests

?

Yes

DevTrial instructions

https://github.com/fedidcg/FedCM/blob/main/explainer/HOWTO.md

Flag name

fedcm

Requires code in //chrome?

True

Tracking bug

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

Launch bug

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

Estimated milestones

Devtrial on Desktop 104

OriginTrial on Android 101

DevTrial on Android 100

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6438627087220736

Links to previous Intent discussions

Intent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/2B4TJ7j2U4M/m/1X5T3OszCAAJ


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/CALdEk-xvmkkTbnhxO-8oX3G5E1%2BjvvNQ2xAf4TozWZbmi47eEA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: AbortSignal.prototype.throwIfAborted

2022-02-15 Thread 'Joe Medley' via blink-dev 
I'm confused about the timeline for this. Is this shipping in 100 or is it
starting a dev trial in 100?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Feb 10, 2022 at 2:54 PM Scott Haseley  wrote:

> Contact emailsshase...@chromium.org
>
> ExplainerDiscussion: https://github.com/whatwg/dom/issues/927
> Examples:
> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted
>
> Specificationhttps://dom.spec.whatwg.org/#dom-abortsignal-throwifaborted
>
> Summary
>
> Throws an AbortSignal's reason if the signal is aborted. This convenience
> method can be used by signal-handling functions to check a signal's abort
> status and propagate the abort reason, e.g. after async operations that
> might change a signal's state.
>
> Blink componentBlink>DOM
> 
>
> TAG reviewN/A: the feature has been merged into the DOM standard and has
> been shipped in at least one other browser, in line with the criteria in
> https://groups.google.com/a/chromium.org/g/blink-dev/c/naqmDmy1iM8/m/lQAJ17CRAQAJ
> .
>
> TAG review statusNot applicable
>
> Risks
>
> Interoperability and Compatibility
>
> Low risk. This feature is already part of the DOM standard, has web
> platform tests, and is implemented by Safari and Firefox. We'll improve
> eventual interop by shipping this feature.
>
> Gecko: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1745372)
>
> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=234127)
>
> Web developers: Positive. Minor positive feedback (likes) from
> announcement tweets:
> - Safari: https://twitter.com/chris_dumez/status/1469566206516424704
> - Node: https://twitter.com/simonplend/status/1487053107720859648 and
> https://twitter.com/jasnell/status/1466093594129756166
>
> Other signals:
>
> Ergonomics
>
> None; this feature is an ergonomic improvement for AbortSignal users.
>
> Activation
>
> The feature has already been implemented in both Safari and Firefox, but
> it would benefit from a polyfill for use in older browser versions.
>
> Security
>
> None.
>
> Debuggability
>
> Basic tooling only, i.e. autocomplete support for the new AbortSignal
> method will be provided.
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes (
> https://wpt.fyi/results/dom/abort/event.any.html?label=master&label=experimental&aligned&q=dom%2Fabort
> )
>
> Flag name--enable-blink-features=AbortSignalThrowIfAborted
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1273458
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1290443
>
> MeasurementUseCounter: AbortSignalThrowIfAborted
>
> Sample links
> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted#examples
>
> Estimated milestones
> DevTrial on desktop 100
> DevTrial on android 100
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5029737100476416
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3tUkTGZ1VBQm4139zL0n%3De-DO5emVpZE3ukya4Akyu2w%40mail.gmail.com
> 
>
>
> 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/CAKXGoJ1w2WYK4X6fA7V4C0xNJBetNb%3D%2BCMywobhzzc9q9xSRxg%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/CAJUhtG_1ugj%3Dt7%3DWSNSt%3DqnFrpR22NSUPdsXLEqdNT_4zGtEUQ%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

2022-02-15 Thread 'Mustaq Ahmed' via blink-dev 
On Tue, Feb 15, 2022 at 11:16 AM Chris Harrelson 
wrote:

> LGTM2 for the extension to 102, but comments below. It would be very good
> to make progress on landing additional spec pieces.
>
> On Tue, Feb 15, 2022 at 8:09 AM 'Mustaq Ahmed' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> I think [1] would be useful for developers but I see two blockers here:
>> first we need to land the Capability Delegation patch
>> 
>> in HTML  spec as a "reference point" for this idea, then the PR for
>> navigator.userActivation 
>> needs to land too.
>>
>
> Hi Mustaq,
>
> Is there anything blocking integrating the delegation patch into the HTML
> spec, and landing the PR for userActivation? There seems to be implementer
> interest from at least Gecko.
>

- For the Capability Delegation patch
,
yes we are already working with Gecko and will start working on an HTML PR
soon (see its intent

 thread).
- The PR for navigator.userActivation
 still "needs implementer
interest" I think, cc-ing dtapuska@ if I missed something.  (Note that this
is separate from the "user activation v2" model which is already spec-ed

.)


> Chris
>
>
>> On Mon, Feb 14, 2022 at 9:51 AM Mike Taylor 
>> wrote:
>>
>>> Thanks for the thoughtful answers!
>>>
>>> LGTM1. I'll trust you to file bugs / feature requests for those 3 items
>>> (and yeah, 3 sounds like a useful, but hard problem to solve).
>>>
>>> On 2/14/22 9:44 AM, Stephen Mcgruer wrote:
>>>
>>> > Is there anything we can learn about their challenges that might apply
>>> to the broader ecosystem?
>>>
>>> A little, though largely it appears to be a bug in either
>>> their application or in Chrome (we're still trying to figure out which!).
>>> Simplifying, the problem is that they seem to be losing the Capability
>>> Delegation between click and (in a different iframe) the call to PR.show(),
>>> and it's quite tricky to debug this in a large async application. I can
>>> think of a few things that might help:
>>>
>>> 1. Adding capability delegation support to navigator.userActivation
>>>  would likely be useful,
>>> e.g. exposing an array of capabilities currently active. This would make it
>>> much easier to quickly debug 'do I have a CD right here'. I hope the
>>> Capability Delegation folks might consider adding this! :)
>>> 2. Pausing user activation timeout when code execution in devtools is
>>> paused would be useful.
>>> 3. More generally (and more hand-wavingly), being able to more easily
>>> trace flows through async iframes 'somehow'. Devtools has some support for
>>> this, and it might just be user error that we and the partner are
>>> struggling, but when we're trying to answer questions like "Is it possible
>>> that this event flowed through an intermediary iframe that was created and
>>> destroyed again before this line of code executed", it can be tricky.
>>>
>>> On Mon, 14 Feb 2022 at 09:27, Mike Taylor 
>>> wrote:
>>>
 Hi Stephen,

 Is there anything we can learn about their challenges that might apply
 to the broader ecosystem?

 On 2/14/22 9:22 AM, Stephen McGruer wrote:

 Hey all,

 Unfortunately we've hit a snag in our deprecation; a partner has been
 having trouble integrating this change into their system, and though we are
 engaged in helping them we haven't made much progress yet.

 As such, I'm currently requesting that we delay this deprecation *until
 M102*, to give us more time to help solve their problem before we
 require user activation. (I'm not sure how many LGTMs delaying a
 deprecation requires?)

 Thanks,
 Stephen

 On Tuesday, January 4, 2022 at 10:29:01 AM UTC-5 Stephen McGruer wrote:

> Hey folks,
>
> Following up here - we have determined that the remaining uses *do* 
> necessitate
> making Capability Delegation available for web developers (see our Intent
> to Experiment
> 
>  -
> unfortunately our partner didn't engage at that time or we would have
> caught this earlier :(. )
>
> We expect an Intent to Ship to be sent for Capability Delegation
> 'soon', targeting M100, and so are planning to push this deprecation out 
> to
> M100 as well to align with that.
>
> Thanks,
> Stephen
> On Wednesday, December 1, 2021 at 3:25:01 PM UTC-5 Mike Taylor wrote:
>
>> LGTM3
>>
>> On 12/1/21 12:34 PM, Chris Harrelson

Re: [blink-dev] Intent to Ship: Multi-Screen Window Placement

2022-02-15 Thread Ian Kilpatrick 
On Mon, Feb 14, 2022 at 5:28 PM Michael Wasserman  wrote:

> Contact emails
>
> m...@chromium.org
>
>
> Explainer
>
> https://github.com/webscreens/window-placement
>
> Specification
>
> https://webscreens.github.io/window-placement/
>
> Design docs https://web.dev/multi-screen-window-placement/
> Summary
>
> Adds new screen information APIs and makes incremental improvements to
> existing window placement APIs, allowing web applications to offer
> compelling multi-screen experiences.
>
> The existing singular window.screen offers a limited view of available
> screen space, and window placement functions generally clamp bounds to the
> current screen. This feature unlocks modern multi-screen workspaces for web
> applications.
>
> Blink component
>
> UI>Browser>WebAppInstalls>Desktop
> 
>
>
This isn't a great component for code that lives within Blink. Can we
create a new component for anything screen API related with the team
working on this responsible for triaging these bugs?

E.g. something like Blink>Screen or Blink>ScreenAPIs

Specifically any code that lives within Blink should have a Blink component
due to how top level triage works.

Search tags
>
> window placement
> , screen
> enumeration ,
> window , open
> , moveTo
> , moveBy
> , requestFullscreen
> , screen
> , display
> , monitor
> , multi-screen
> , multi-display
> , multi-monitor
> , cross-screen
> , cross-display
> , cross-monitor
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/413
> https://github.com/w3ctag/design-reviews/issues/522
> https://github.com/w3ctag/design-reviews/issues/602
>
> TAG review status
>
> Issues addressed
>
> Risks
> Interoperability and Compatibility
>
> Feature detection of new screen information APIs and Permission API
> integration allows sites to handle different levels of feature support. The
> Screen IDL interface duplicates EventTarget members for RuntimeEnabled
> experimentation without changing the stable JS API; this will be rectified
> after launch approval.
>
> Existing window placement APIs generally use compatible multi-screen
> coordinates, but implementations often restrict bounds to the current
> screen. We expect low levels of risk in supporting permitted cross-screen
> placement requests, and falling back on legacy same-screen behavior
> otherwise.
>
> A detailed assessment of API design risks, including Wayland
> compatibility, multiple virtual workspaces/desktops, and more, can be found
> at: <
> https://docs.google.com/document/d/19u5fRKs8iWlpecKBSlfQ6JKrcP4emwK0M_6TNhfz0gs
> >
>
> API surface changes made during the second origin trial are limited to
> some minor renames, the removal of two unimplemented screen properties, and
> support for permission policy. An exploratory permission-gated capability
> to swap the screen of fullscreen windows without a user gesture was
> reverted to enhance usable security. See <
> https://github.com/webscreens/window-placement/blob/main/CHANGES.md>
>
> The spec is being incubated in the W3C Second Screen CG <
> https://webscreens.github.io/cg-charter> and is pending adoption by the
> W3C Second Screen WG 
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/542) We requested a
> position and are waiting for feedback. Firefox supports cross-screen
> window.open/move*() requests. This work partly pursues compatibility with
> that behavior.
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2021-June/031903.html) We
> requested a position and are waiting for feedback.
>
> Web developers: Positive (
> https://github.com/webscreens/window-placement/issues/67)
>
> - Discourse: <
> https://discourse.wicg.io/t/proposal-supporting-window-placement-on-multi-screen-devices
> >
>
> - Twitter: <
> https://twitter.com/search?q=url%3Amulti-screen-window-placement&src=typed_query&f=live
> >
>
> - Announcement: <
> https://twitter.com/ChromiumDev/status/1305406689466814464>
>
> - HackerNews (was front page): <
> https://news.ycombinator.com/item?id=

Re: [blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

2022-02-15 Thread Chris Harrelson 
LGTM2 for the extension to 102, but comments below. It would be very good
to make progress on landing additional spec pieces.

On Tue, Feb 15, 2022 at 8:09 AM 'Mustaq Ahmed' via blink-dev <
blink-dev@chromium.org> wrote:

> I think [1] would be useful for developers but I see two blockers here:
> first we need to land the Capability Delegation patch
> 
> in HTML  spec as a "reference point" for this idea, then the PR for
> navigator.userActivation  needs
> to land too.
>

Hi Mustaq,

Is there anything blocking integrating the delegation patch into the HTML
spec, and landing the PR for userActivation? There seems to be implementer
interest from at least Gecko.

Chris


> On Mon, Feb 14, 2022 at 9:51 AM Mike Taylor 
> wrote:
>
>> Thanks for the thoughtful answers!
>>
>> LGTM1. I'll trust you to file bugs / feature requests for those 3 items
>> (and yeah, 3 sounds like a useful, but hard problem to solve).
>>
>> On 2/14/22 9:44 AM, Stephen Mcgruer wrote:
>>
>> > Is there anything we can learn about their challenges that might apply
>> to the broader ecosystem?
>>
>> A little, though largely it appears to be a bug in either
>> their application or in Chrome (we're still trying to figure out which!).
>> Simplifying, the problem is that they seem to be losing the Capability
>> Delegation between click and (in a different iframe) the call to PR.show(),
>> and it's quite tricky to debug this in a large async application. I can
>> think of a few things that might help:
>>
>> 1. Adding capability delegation support to navigator.userActivation
>>  would likely be useful,
>> e.g. exposing an array of capabilities currently active. This would make it
>> much easier to quickly debug 'do I have a CD right here'. I hope the
>> Capability Delegation folks might consider adding this! :)
>> 2. Pausing user activation timeout when code execution in devtools is
>> paused would be useful.
>> 3. More generally (and more hand-wavingly), being able to more easily
>> trace flows through async iframes 'somehow'. Devtools has some support for
>> this, and it might just be user error that we and the partner are
>> struggling, but when we're trying to answer questions like "Is it possible
>> that this event flowed through an intermediary iframe that was created and
>> destroyed again before this line of code executed", it can be tricky.
>>
>> On Mon, 14 Feb 2022 at 09:27, Mike Taylor  wrote:
>>
>>> Hi Stephen,
>>>
>>> Is there anything we can learn about their challenges that might apply
>>> to the broader ecosystem?
>>>
>>> On 2/14/22 9:22 AM, Stephen McGruer wrote:
>>>
>>> Hey all,
>>>
>>> Unfortunately we've hit a snag in our deprecation; a partner has been
>>> having trouble integrating this change into their system, and though we are
>>> engaged in helping them we haven't made much progress yet.
>>>
>>> As such, I'm currently requesting that we delay this deprecation *until
>>> M102*, to give us more time to help solve their problem before we
>>> require user activation. (I'm not sure how many LGTMs delaying a
>>> deprecation requires?)
>>>
>>> Thanks,
>>> Stephen
>>>
>>> On Tuesday, January 4, 2022 at 10:29:01 AM UTC-5 Stephen McGruer wrote:
>>>
 Hey folks,

 Following up here - we have determined that the remaining uses *do* 
 necessitate
 making Capability Delegation available for web developers (see our Intent
 to Experiment
 
  -
 unfortunately our partner didn't engage at that time or we would have
 caught this earlier :(. )

 We expect an Intent to Ship to be sent for Capability Delegation
 'soon', targeting M100, and so are planning to push this deprecation out to
 M100 as well to align with that.

 Thanks,
 Stephen
 On Wednesday, December 1, 2021 at 3:25:01 PM UTC-5 Mike Taylor wrote:

> LGTM3
>
> On 12/1/21 12:34 PM, Chris Harrelson wrote:
>
> LGTM2
>
> On Wed, Dec 1, 2021 at 9:33 AM Yoav Weiss 
> wrote:
>
>> LGTM1 to deprecate in M98 and remove in M99, assuming no surprises
>> come up on the usage front.
>>
>> On Wed, Dec 1, 2021 at 6:31 PM Stephen Mcgruer 
>> wrote:
>>
>>> To be clear; I think we have a good enough shot of that remaining
>>> site fixing their code 'soon' (I expect O(weeks)) that we both:
>>>
>>> 1. Shouldn't do the removal till they have, and
>>> 2. Don't need to provide an alternative in the form of capability
>>> delegation.
>>>
>>> But the code change to at least start this deprecation would have to
>>> land by December 9th (or we punt for 1.5 months), hence why we're filing
>>> this ahead of them fixing their site :).
>>>
>>> On Wed, 1 Dec 2021 at 12:22

Re: [blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

2022-02-15 Thread 'Mustaq Ahmed' via blink-dev 
I think [1] would be useful for developers but I see two blockers here:
first we need to land the Capability Delegation patch

in HTML  spec as a "reference point" for this idea, then the PR for
navigator.userActivation  needs
to land too.

On Mon, Feb 14, 2022 at 9:51 AM Mike Taylor  wrote:

> Thanks for the thoughtful answers!
>
> LGTM1. I'll trust you to file bugs / feature requests for those 3 items
> (and yeah, 3 sounds like a useful, but hard problem to solve).
>
> On 2/14/22 9:44 AM, Stephen Mcgruer wrote:
>
> > Is there anything we can learn about their challenges that might apply
> to the broader ecosystem?
>
> A little, though largely it appears to be a bug in either
> their application or in Chrome (we're still trying to figure out which!).
> Simplifying, the problem is that they seem to be losing the Capability
> Delegation between click and (in a different iframe) the call to PR.show(),
> and it's quite tricky to debug this in a large async application. I can
> think of a few things that might help:
>
> 1. Adding capability delegation support to navigator.userActivation
>  would likely be useful, e.g.
> exposing an array of capabilities currently active. This would make it much
> easier to quickly debug 'do I have a CD right here'. I hope the Capability
> Delegation folks might consider adding this! :)
> 2. Pausing user activation timeout when code execution in devtools is
> paused would be useful.
> 3. More generally (and more hand-wavingly), being able to more easily
> trace flows through async iframes 'somehow'. Devtools has some support for
> this, and it might just be user error that we and the partner are
> struggling, but when we're trying to answer questions like "Is it possible
> that this event flowed through an intermediary iframe that was created and
> destroyed again before this line of code executed", it can be tricky.
>
> On Mon, 14 Feb 2022 at 09:27, Mike Taylor  wrote:
>
>> Hi Stephen,
>>
>> Is there anything we can learn about their challenges that might apply to
>> the broader ecosystem?
>>
>> On 2/14/22 9:22 AM, Stephen McGruer wrote:
>>
>> Hey all,
>>
>> Unfortunately we've hit a snag in our deprecation; a partner has been
>> having trouble integrating this change into their system, and though we are
>> engaged in helping them we haven't made much progress yet.
>>
>> As such, I'm currently requesting that we delay this deprecation *until
>> M102*, to give us more time to help solve their problem before we
>> require user activation. (I'm not sure how many LGTMs delaying a
>> deprecation requires?)
>>
>> Thanks,
>> Stephen
>>
>> On Tuesday, January 4, 2022 at 10:29:01 AM UTC-5 Stephen McGruer wrote:
>>
>>> Hey folks,
>>>
>>> Following up here - we have determined that the remaining uses *do* 
>>> necessitate
>>> making Capability Delegation available for web developers (see our Intent
>>> to Experiment
>>> 
>>>  -
>>> unfortunately our partner didn't engage at that time or we would have
>>> caught this earlier :(. )
>>>
>>> We expect an Intent to Ship to be sent for Capability Delegation 'soon',
>>> targeting M100, and so are planning to push this deprecation out to M100 as
>>> well to align with that.
>>>
>>> Thanks,
>>> Stephen
>>> On Wednesday, December 1, 2021 at 3:25:01 PM UTC-5 Mike Taylor wrote:
>>>
 LGTM3

 On 12/1/21 12:34 PM, Chris Harrelson wrote:

 LGTM2

 On Wed, Dec 1, 2021 at 9:33 AM Yoav Weiss 
 wrote:

> LGTM1 to deprecate in M98 and remove in M99, assuming no surprises
> come up on the usage front.
>
> On Wed, Dec 1, 2021 at 6:31 PM Stephen Mcgruer 
> wrote:
>
>> To be clear; I think we have a good enough shot of that remaining
>> site fixing their code 'soon' (I expect O(weeks)) that we both:
>>
>> 1. Shouldn't do the removal till they have, and
>> 2. Don't need to provide an alternative in the form of capability
>> delegation.
>>
>> But the code change to at least start this deprecation would have to
>> land by December 9th (or we punt for 1.5 months), hence why we're filing
>> this ahead of them fixing their site :).
>>
>> On Wed, 1 Dec 2021 at 12:22, Stephen Mcgruer 
>> wrote:
>>
>>> > Does the primary remaining site have fallback code, or will it be
>>> broken?
>>>
>>> Yes and no :). It doesn't have automatic fallback for the specific
>>> payment method the user has selected (Google Pay), but the user could 
>>> then
>>> select one of the other payment methods that the site supports (either a
>>> credit card flow or I think PayPal IIRC).
>>>
>>> On Wed, 1 Dec 2021 at 11:05, Yoav Weiss 
>>> wrote:
>>>


>>>