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

[Michael Wasserman]

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


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: 

- HackerNews (was front page): <
https://news.ycombinator.com/item?id=24489234>

- Citrix: <
https://github.com/webscreens/window-placement/issues/67#issuecomment-945859384
>

- This work is also of interest to Google Slides

Ergonomics

The minor improvements to window.open/move*() API behaviors have no effect
on their poor ergonomics (synchronous, features string shape, etc.). This
API does not preclude future work from improving the ergonomics of those
existing APIs. Extending the requestFullscreen dictionary with an optional
screen should pose no ergonomic risks. The new multi-screen information
APIs incorporated OT feedback to improve naming, object comparison, and
event handling er

Re: [blink-dev] Re: Intent to Ship: HIDDevice forget()

['Matt Reynolds' via blink-dev]

> About web tests, is there no method that behaves differently in an
observable way when the permission isn't given?

If the device is connected then navigator.hid.getDevices() will return an
array containing a HIDDevice representing the device, but the API doesn't
provide a way to learn about disconnected devices. Currently we don't have
a way to simulate a connected device for WPT.

On Wed, Feb 9, 2022 at 9:55 AM Mike West  wrote:

> LGTM3.
>
> -mike
>
>
> On Wed, Feb 9, 2022 at 11:44 AM Daniel Bratell 
> wrote:
>
>> LGTM2
>>
>> About web tests, is there no method that behaves differently in an
>> observable way when the permission isn't given?
>>
>> /Daniel
>> On 2022-02-09 10:27, Yoav Weiss wrote:
>>
>> LGTM1. Seems like a small and useful addition.
>>
>> On Tuesday, February 8, 2022 at 9:42:23 AM UTC+1 François Beaufort wrote:
>>
>>> Contact emails
>>>
>>> fbeauf...@google.com
>>>
>>> mattreyno...@google.com
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/webhid/blob/main/EXPLAINER.md
>>>
>>> Specification
>>>
>>> https://wicg.github.io/webhid/#forget-method
>>>
>>> https://github.com/WICG/webhid/pull/84
>>>
>>> Summary
>>>
>>> The HIDDevice forget() method allows web developers to voluntarily
>>> revoke a permission to a HIDDevice that was granted by a user.
>>>
>>> Blink component
>>>
>>> Blink>HID
>>> 
>>>
>>> Motivation
>>>
>>> Some sites may not be interested in retaining long-term permissions to
>>> access a HID device. For example, for an educational web application used
>>> on a shared computer with many devices, a large number of accumulated
>>> user-generated permissions creates a poor user experience. In addition
>>> to user agent mitigations to avoid this problem, such as defaulting to a
>>> session scoped permission on the first request or expiring infrequently
>>> used permissions, it should be possible for the site itself to clean up
>>> user-generated permissions it is no longer interested in retaining.
>>>
>>> // Request a HID device.
>>>
>>> const [device] = await navigator.hid.requestDevice({ filters: [] });
>>>
>>> // Then later... revoke permission to the HID device.
>>>
>>> await device.forget();
>>>
>>> We expect similar functionality to Web Bluetooth, WebUSB, and the Serial
>>> API to be added.
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/703
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> This small addition to the HIDDevice object does not change the overall
>>> status of WebHID interoperability or compatibility.
>>>
>>> Signals from other implementations (Gecko, WebKit):
>>>
>>> Gecko: No Signal [1]
>>>
>>> WebKit: No Signal [1]
>>>
>>> Web / Framework developers: Positive
>>> https://github.com/WICG/webhid/issues/39
>>>
>>> Other signals: Google Meet folks have tried it and strongly support this
>>> addition.
>>>
>>> [1] Both Gecko and WebKit are unlikely to object to this feature
>>> specifically, but object to the overall WebHID API as a whole, hence it
>>> doesn't make sense to bug them with specific questions on this.
>>>
>>> Activation:
>>>
>>> This feature can't be polyfilled. It should be fairly trivial for
>>> developers to adopt this new feature.
>>>
>>> Debuggability
>>>
>>> No specific DevTools changes are required. This feature is treated like
>>> any other JS method.
>>>
>>> Note that exposing DevTools debugging support for device-access APIs
>>> (WebHID included) is discussed at
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1142566.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> No, because permission storage is implemented outside of Blink and so
>>> isn’t testable by web-platform-tests. Some tests that only verify the
>>> presence of interfaces and attributes will be available at
>>> https://wpt.fyi/results/webhid though.
>>>
>>> Requires code in //chrome?
>>>
>>> Yes, permission storage is implemented in //chrome.
>>>
>>> Tracking bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1279822
>>>
>>> Estimated milestones
>>>
>>> 100
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5723581527883776
>>>
>>> Links to previous Intent discussions
>>>
>>> Intent to prototype:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/c2vCYr-0dqk/m/3nSeViRLCgAJ
>>>
>> --
>> 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/bbd12314-8ade-4a84-a31c-dea7964344dcn%40chromium.org
>> 

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

['Daniel Vogelheim' via blink-dev]

Hi all, just a brief update:

- The warning should go live on M100
.
- Flipping the default is planned for M106 but there'll be a
separate intent (and thus additional discussion), as requested.
- A deprecation warning for cross-domain access (based on previous
document.domain setting) is in the works, and will either make it to M100
also, or will land shortly after.
- Additional info: Blog post
; plus
some technical
notes

.

On Wed, Jan 26, 2022 at 5:35 PM Daniel Bratell  wrote:

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

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMfJoCfVH27xLARbTyBhgO2ypZLHT%2BQ2Pf4EXvBFdjncA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

[Domenic Denicola]

On Mon, Feb 14, 2022 at 11:33 AM Noam Rosenthal 
wrote:

>
>
> On Saturday, February 12, 2022 at 7:11:29 AM UTC+2 yoav...@chromium.org
> wrote:
>
>> I agree with Domenic that it's great to see this kind of feature, that
>> was traditionally unspecified, getting some clearer developer visibility
>> and a spec. While there may still be missing pieces, this seems like a good
>> start. I'm looking forward to further spec discussions that would hopefully
>> lead to convergence and better interop.
>>
>> On Fri, Feb 11, 2022 at 11:39 PM Domenic Denicola 
>> wrote:
>>
>>>
>>>
>>> On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay  wrote:
>>>
 FWIW, the comment in the HTML spec triage was positive feedback to have
 a spec for this.
 The current spec proposal clearly is missing still quite a few cases
 (is the idea really that one can use BroadcastChannel with prerendered
 page? and the webidl annotation behaves rather oddly)
 So it is surprising to see this shipping already now.

>>>
>>> Thanks for chiming in, Olli!
>>>
>>> I have a rather different take. As the team's spec mentor, I'm impressed
>>> with the spec work the team has done, on taking what most other browsers
>>> have treated as a not-to-be-specified user agent UI feature, and turning it
>>> into something much more rigorous and developer-friendly. For example:
>>>
>>>- The careful auditing of all APIs to see how they should behave in
>>>prerendering.
>>>- Introducing a well-specified Sec-Purpose: prefetch header, instead
>>>of the unspecified X-moz: prefetch or X-Purpose: preview headers.
>>>- Considering how to handle edge cases such as redirects, 204s,
>>>Content-Disposition: attachment, or pages that do client-side navigation
>>>while being prerendered.
>>>
>>> I think there's definitely still work to be done, as we try to move from
>>> the current world where every browser does something different into one
>>> that's more fully predictable for web developers. But I think this is
>>> similar to other features, like bfcache, where for many years the
>>> heuristics and rules used were unspecified (e.g. Cache-Control, unload
>>> handlers, BroadcastChannel), and then we've started a slow convergence
>>> process as browsers start to care more about interoperability.
>>>
>>> We can definitely tweak things, like Olli's example of BroadcastChannel,
>>> over time and as other browsers indicate willingness to converge.
>>>
>>
>> One potential problem with that approach is that sites may grow to rely
>> on that existence of e.g. BroadcastChannel and may break when we take that
>> away.
>> I don't think that's a risk for the current I2S, as developers are not
>> aware that the page is being prerendered outside of the page itself, so the
>> chances of them trying to communicate with it are low.
>> But that can be a risk for the speculation rules based API, which would
>> be good to mitigate.
>>
>>>
>>> Re. BroadcastChannel and friends - it's a totally valid point and
> there's an open issue about it (
> https://github.com/WICG/nav-speculation/issues/113). I feel that we
> should examine these especially as we move from omnibox to
> document-initiated prerenering.
>

Yeah, just to be clear, I agree page-initiated prerendering multiplies the
risks significantly and will thus need more work.  I expect there will
still be some implementation-dependent behavior (e.g., some implementations
may discard a prerender if they use a disruptive API, while others might
delay the API results). But things like "does BroadcastChannel work at all
or not" are critical to nail down for interoperable page-initiated
prerendering.

-- 
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/CAM0wra_sYWF2iuoX9UAofpQQxaxNmO2J1Ui8zCsZi4v0mQ9fEg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

[Noam Rosenthal]

On Saturday, February 12, 2022 at 7:11:29 AM UTC+2 yoav...@chromium.org 
wrote:

> I agree with Domenic that it's great to see this kind of feature, that was 
> traditionally unspecified, getting some clearer developer visibility and a 
> spec. While there may still be missing pieces, this seems like a good 
> start. I'm looking forward to further spec discussions that would hopefully 
> lead to convergence and better interop.  
>
> On Fri, Feb 11, 2022 at 11:39 PM Domenic Denicola  
> wrote:
>
>>
>>
>> On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay  wrote:
>>
>>> FWIW, the comment in the HTML spec triage was positive feedback to have 
>>> a spec for this.
>>> The current spec proposal clearly is missing still quite a few cases (is 
>>> the idea really that one can use BroadcastChannel with prerendered page? 
>>> and the webidl annotation behaves rather oddly)
>>> So it is surprising to see this shipping already now. 
>>>
>>
>> Thanks for chiming in, Olli!
>>
>> I have a rather different take. As the team's spec mentor, I'm impressed 
>> with the spec work the team has done, on taking what most other browsers 
>> have treated as a not-to-be-specified user agent UI feature, and turning it 
>> into something much more rigorous and developer-friendly. For example:
>>
>>- The careful auditing of all APIs to see how they should behave in 
>>prerendering.
>>- Introducing a well-specified Sec-Purpose: prefetch header, instead 
>>of the unspecified X-moz: prefetch or X-Purpose: preview headers.
>>- Considering how to handle edge cases such as redirects, 204s, 
>>Content-Disposition: attachment, or pages that do client-side navigation 
>>while being prerendered.
>>
>> I think there's definitely still work to be done, as we try to move from 
>> the current world where every browser does something different into one 
>> that's more fully predictable for web developers. But I think this is 
>> similar to other features, like bfcache, where for many years the 
>> heuristics and rules used were unspecified (e.g. Cache-Control, unload 
>> handlers, BroadcastChannel), and then we've started a slow convergence 
>> process as browsers start to care more about interoperability.
>>
>> We can definitely tweak things, like Olli's example of BroadcastChannel, 
>> over time and as other browsers indicate willingness to converge. 
>>
>
> One potential problem with that approach is that sites may grow to rely on 
> that existence of e.g. BroadcastChannel and may break when we take that 
> away.
> I don't think that's a risk for the current I2S, as developers are not 
> aware that the page is being prerendered outside of the page itself, so the 
> chances of them trying to communicate with it are low.
> But that can be a risk for the speculation rules based API, which would be 
> good to mitigate.
>
>>
>> Re. BroadcastChannel and friends - it's a totally valid point and there's 
an open issue about it 
(https://github.com/WICG/nav-speculation/issues/113). I feel that we should 
examine these especially as we move from omnibox to document-initiated 
prerenering.

-- 
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/726d402c-8154-4118-8a59-28da00e55541n%40chromium.org.

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

[Mike Taylor]

LGTM1

On 2/10/22 3:25 PM, Reilly Grant wrote:



Contact emails

reil...@chromium.org


Specification

https://wicg.github.io/serial/#writable-attribute 



https://github.com/WICG/serial/pull/160


Summary

This integration prevents a situation in which aborting a SerialPort's 
WritableStream can be blocked waiting for a partially-written chunk of 
data to be written to the port. If the port is waiting for the peer 
device to provide a flow control signal it could be blocked 
indefinitely. The intent of aborting a WritableStream is to 
immediately stop trying to write data to the underlying sink. The 
introduction of an AbortSignal to the controller was done to fix bugs 
like this.



Blink component

Blink>Serial 




TAG review

The Web Serial API and WritableStream controller AbortSignal have both 
been reviewed by the TAG.



TAG review status

Not applicable


Risks


Interoperability and Compatibility

This integration introduces a minor change to the behavior of a 
SerialPort's WritableStream because it means that it no longer waits 
for the current write() operation to complete. However, since the 
intention of abort() is to discard queued writes and the exact timing 
for when the current write() operation completes depends on how 
quickly data is being transmitted by the port, the current behavior is 
more appropriately classified as a bug than a feature. It would be 
very hard for developers to rely on the previous buggy behavior, and 
so we believe the compat risk to be minimal.



Gecko: No signal

Firefox is opposed to the Web Serial API in general.


WebKit: No signal

Safari is opposed to the Web Serial API in general.


Web developers: No signals

I don't believe any developers have noticed this particular quirk. I 
noticed because I was debugging a test of the abort() behavior that 
passed even though there was a write() pending and without this 
integration it shouldn't have. Fixing the bug in the test exposed the 
need for this integration.



Other signals:


Debuggability

SerialPort and WritableStream are JavaScript APIs which can be 
debugged using DevTools.



Is this feature fully tested by web-platform-tests

?

Yes


Flag name

None


Requires code in //chrome?

False


Tracking bug

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




Estimated milestones

M-100


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4778232531386368 




This intent message was generated by Chrome Platform Status 
.
Reilly Grant | Software Engineer |reil...@chromium.org |Google Chrome 


--
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/CAEmk%3DMYv0pu_WEXE6EAoZvVkh7W-ck_Gu5Qf52eFUuiwYhcW4A%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/a25f97f6-4213-adc8-8151-9f4e472d4dad%40chromium.org.

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

[Mike Taylor]

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:



On Wed, Dec 1, 2021 at 4:43 PM Stephen
Mcgruer  w

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

[Stephen Mcgruer]

> 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:
>>
>>>
>>>
>>> On Wed, Dec 1, 2021 at 4:43 PM Stephen Mcgruer <
>>> smcgr...@chromium.org> wrote:
>>>
 Contact emails smcgr...@chromium.org

 Specification https://www.w3.org/TR/payment-request/#show-method

 Summary

 Allowing PaymentRequest.show() to be triggered without a user
 activation could be abused by malicious websites. To protect users, the
 spec was changed to require user activation, and we are now following
 through in the Chrome implementation.

 Plan is to deprecate in M98 and remove in M99. We may push the M99
 date to M100 based on compat risk; see below.

 Blink component Blink>Payments
 

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

[Mike Taylor]

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:



On Wed, Dec 1, 2021 at 4:43 PM Stephen
Mcgruer  wrote:


Contact emails

smcgr...@chromium.org


Specification

https://www.w3.org/TR/payment-request/#show-method



Summary

Allowing PaymentRequest.show() to be
triggered without a user activation could
be abused by malicious websites. To
protect users, the spec was changed to
require user activation, and we are now
following through in the Chrome
implementation.

Plan is to deprecate in M98 and remove in
M99. We may push the M99 date to M100
based on compat risk; see below.


Blink component

Blink>Payments




TAG review

N/A - enforcement of feature from an
already-reviewed specification


TAG review status

Pending


Risks


Interoperability and Compatibility

Interoperability: no risk. Firefox has
not shipped PaymentRequest at all, whilst
Safari's implementation already requires
user activation for calling show().
C

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

[Stephen McGruer]

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:
>
>>
>>
>> On Wed, Dec 1, 2021 at 4:43 PM Stephen Mcgruer  
>> wrote:
>>
>>> Contact emails smcgr...@chromium.org
>>>
>>> Specification https://www.w3.org/TR/payment-request/#show-method
>>>
>>> Summary 
>>>
>>> Allowing PaymentRequest.show() to be triggered without a user 
>>> activation could be abused by malicious websites. To protect users, the 
>>> spec was changed to require user activation, and we are now following 
>>> through in the Chrome implementation.
>>>
>>> Plan is to deprecate in M98 and remove in M99. We may push the M99 
>>> date to M100 based on compat risk; see below.
>>>
>>> Blink component Blink>Payments 
>>> 
>>>
>>> TAG review N/A - enforcement of feature from an already-reviewed 
>>> specification
>>>
>>> TAG review status Pending
>>>
>>> Risks 
>>> Interoperability and Compatibility 
>>>
>>> Interoperability: no risk. Firefox has not shipped PaymentRequest at 
>>> all, whilst Safari's implementation already requires user activation 
>>> for 
>>> calling show(). Compatibility: the main risk. If a website is calling 
>>> PaymentRequest.show() without a user activation today, it will stop 
>>> working. If that website doesn't have fallback code to use another 
>>> payments 
>>> flow, it may lead to a broken purchase experience for the user. Due to 
>>> this 
>>> risk, we added a UseCounter, kPaymentRequestShowWithoutGesture, which 
>>> tracks use of the feature. Although hits on the UseCounter have reduced 
>>> significantly since 2019*, there is still non-zero usage which is 
>>> growing 
>>> slowly over time. We believe the growth to be related to the general 
>>> increase of web payments, rather than an expanded number of sites. To 
>>> tackle the remaining usage, we have performed a UKM analysis, and 
>>> identified the primary remaining site. We are in contact with them, and 
>>> expect them to roll out a fix in the coming weeks - after which we will 
>>> revisit the numbers and this thread.
>>>
>>
>> Does the primary remaining site have fallback code, or will it be 
>> broken?
>>  
>>
>>> * https://chromestatus.com/metrics/feature/timeline/popularity/2398
>>>
>>> Gecko: In developm