[blink-dev] Re: Compositing Reasons

['Pea Wyllie' via blink-dev]

I did do that for testing and how I knew to use the Compositing Reasons; 
but for my use case I need these layers to be specifically identifiable, so 
I was using the attribute.

On Monday, November 14, 2022 at 1:49:15 PM UTC-8 Philip Rogers wrote:

> Would it work to just add "will-change: transform;" (either in the html, 
> or as an implementation detail in blink itself)? This can change paint 
> order because it causes a stacking context, but it's the simplest way to 
> ensure a cc::Layer is created that it set up for moving content.
> On Monday, November 14, 2022 at 11:48:41 AM UTC-8 Pea Wyllie wrote:
>
>> Hello, I've got a use case in which I need to get certain DOM elements 
>> into their own layer. I've added a new HTML attribute for this purpose, and 
>> added a new Compositing Reason to the layers that have this attribute. 
>> However, when I go to a test site on my Chromium build running with 
>> --show-composited-layer-borders, I do not see my elements in their own 
>> compositing layer. Is there an allowlist elsewhere that is necessary to 
>> pick up those changes? Or is compositing reasons just for metrics or 
>> something and the actual logic resides elsewhere? Thanks!
>
>

-- 
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/6b6fac94-1c52-46fb-8be7-638fef0246d4n%40chromium.org.

[blink-dev] Re: Compositing Reasons

['Philip Rogers' via blink-dev]

Would it work to just add "will-change: transform;" (either in the html, or 
as an implementation detail in blink itself)? This can change paint order 
because it causes a stacking context, but it's the simplest way to ensure a 
cc::Layer is created that it set up for moving content.
On Monday, November 14, 2022 at 11:48:41 AM UTC-8 Pea Wyllie wrote:

> Hello, I've got a use case in which I need to get certain DOM elements 
> into their own layer. I've added a new HTML attribute for this purpose, and 
> added a new Compositing Reason to the layers that have this attribute. 
> However, when I go to a test site on my Chromium build running with 
> --show-composited-layer-borders, I do not see my elements in their own 
> compositing layer. Is there an allowlist elsewhere that is necessary to 
> pick up those changes? Or is compositing reasons just for metrics or 
> something and the actual logic resides elsewhere? Thanks!

-- 
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/5a085cff-cf5c-42e1-a0c2-1d4ae9ac6a55n%40chromium.org.

[blink-dev] BlinkOn 17 is tomorrow!

[BlinkOn Planning Committee]

bcc: blink-dev@ and BlinkOn 17 attendees

Hi all,

BlinkOn 17 is tomorrow!  If you’re still needing to register to attend
virtually, do so here
.
Virtual registration will be open until the day of the event.

Schedule

You can view the schedule here
.
To join the event, click the Google Meet link here
 which can also be found in the
calendar invite. The link is the same for all three days.

   -

   Please join the call up to 30 min early to be allowed into the call.
   Once you're let in once, you won't have to be let in again.


Comms

For announcements and event chatter, join the Chromium workspace here

and join the #blinkon channel.

Code of conduct

We’d like to remind folks of the Code of Conduct
 for BlinkOn 17.

Session recording

All talks will be recorded and added to the BlinkOn YouTube channel
 following the event.

If you have any questions, please email us at blin...@chromium.org.

Thanks,

BlinkOn Planning Committee

-- 
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/CABjKNU6kRnB9zrxGYy0se72zj4raV%3Du%3D5Rsozqp3oDWFcqp-jw%40mail.gmail.com.

[blink-dev] Compositing Reasons

['Pea Wyllie' via blink-dev]

Hello, I've got a use case in which I need to get certain DOM elements into 
their own layer. I've added a new HTML attribute for this purpose, and 
added a new Compositing Reason to the layers that have this attribute. 
However, when I go to a test site on my Chromium build running with 
--show-composited-layer-borders, I do not see my elements in their own 
compositing layer. Is there an allowlist elsewhere that is necessary to 
pick up those changes? Or is compositing reasons just for metrics or 
something and the actual logic resides elsewhere? Thanks!

-- 
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/1ab49712-8fab-4ce7-8550-eb3b5689dd6fn%40chromium.org.

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

[Arnab Animesh Das]

I won't reiterate most of the stuff as Jerry Glowacki 

 
has already mentioned most of it. If you think supporting JPEG XL is an 
unnecessary burden at least allow passthrough support similar to HEVC. It 
should require no future maintenance from your end and everybody is happy.

We don't know the exact reason why you are removing it, but if you are 
worried if they may eat into each others adoption (i.e. AVIF vs JPEG XL) I 
say that it should be the least of the concerns. Today webp and jpeg is 
living side by side as they have different use cases. AVIF has different 
use cases as compared to JPEG XL. AVIF excels at low fidelity standard 
images with slower encoding times whereas JPEG XL excels at hi fidelity 
progressive images with faster encoding times while allowing for easy 
transition from JPEG. Let the end users decide what's best for them.

On Friday, 11 November 2022 at 21:28:28 UTC+5:30 jimba...@google.com wrote:

> Helping the web to evolve is challenging, and it requires us to make 
> difficult choices. We've also heard from our browser and device partners 
> that every additional format adds costs (monetary or hardware), and we’re 
> very much aware that these costs are borne by those outside of Google. When 
> we evaluate new media formats, the first question we have to ask is whether 
> the format works best for the web. With respect to new image formats such 
> as JPEG XL, that means we have to look comprehensively at many factors: 
> compression performance across a broad range of images; is the decoder 
> fast, allowing for speedy rendering of smaller images; are there fast 
> encoders, ideally with hardware support, that keep encoding costs 
> reasonable for large users; can we optimize existing formats to meet any 
> new use-cases, rather than adding support for an additional format; do 
> other browsers and OSes support it? 
>
> After weighing the data,  we’ve decided to stop Chrome’s JPEG XL 
> experiment and remove the code associated with the experiment.  We'll work 
> to publish data in the next couple of weeks. 
>
> For those who want to use JPEG XL in Chrome, we believe a WebAssembly 
> (Wasm) implementation is both performant and a great path forward.
>
>
> Jim
>
>
> On Monday, October 31, 2022 at 11:01:44 AM UTC-7 ash...@scirra.com wrote:
>
>> Apologies for bringing back an old thread, but I thought it was important 
>> to bring this up here.
>>
>> I was surprised to read that Google are abandoning their efforts to 
>> implement JPEG-XL: 
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84
>>
>> As I understood it, JPEG-XL brought significant improvements over 
>> existing image formats, and had a lot of interest in the technology world. 
>> However the reasons cited were apparently lack of benefits and lack of 
>> interest.
>>
>> I for one was interested in this format and the improvements it would 
>> bring, and it seems many others are disappointed too.  Can Google explain 
>> how they came to this conclusion? How are they evaluating the benefits and 
>> interest? Even this intent to prototype lists many of the purported 
>> benefits and the extent of the interest, which makes this reversal 
>> particularly hard to understand.
>>
>>
>>
>>
>> On Tue, 30 Mar 2021 at 20:20, 'Moritz Firsching' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>>
>>> *de...@chromium.org, firs...@google.com, lo...@google.com, 
>>> jy...@google.com*Explainer
>>>
>>>
>>> *https://jpeg.org/jpegxl/ 
>>> http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf
>>>  
>>> *Specification
>>>
>>>
>>> *https://arxiv.org/abs/1908.03565 *
>>> Summary
>>>
>>>
>>>
>>>
>>> *JPEG XL is a new royalty-free image codec targeting the image quality 
>>> as found on the web, providing about ~60% size savings when compared to 
>>> original JPEG at the same perceptual quality, while supporting modern 
>>> features like HDR, animation, alpha channel, lossless JPEG recompression, 
>>> lossless and progressive modes. It is based on Google's PIK and 
>>> Cloudinary's FUIF, and is in the final steps of standardization with 
>>> ISO.This feature enables image/jxl decoding support in the blink 
>>> renderer.*Blink 
>>> component
>>>
>>>
>>> *Blink>Image 
>>> *
>>> Motivation
>>>
>>>
>>>
>>>
>>> *The main motivations for supporting JPEG XL in Chrome are: - The 
>>> improvement in image quality vs image size, about 60% file size savings for 
>>> the same visual quality (lossy compression of larger originals) when 
>>> compared to JPEG at the qualities found on the web.- Improved visual 
>>> latency by both smaller download sizes and supporting progressive decoding 
>>> modes. - Support for HDR, animation and progressive 

Re: [blink-dev] Intent to Ship: Anonymous iframes

['Zheng Wei' via blink-dev]

Google Display Ads (GPT specifically) has tried the OT and is satisfied 
with the feature's behavior. Looking forward to it!

On Thursday, November 10, 2022 at 10:06:35 AM UTC-5 Smaug wrote:

> On 11/10/22 10:33, 'Arthur Sonzogni' via blink-dev wrote:
> > Hi blink-dev,
> > 
> > *
> > *
> > 
> > We decided to address issue #5 <
> https://github.com/WICG/anonymous-iframe/issues/5>: “rename anonymous 
> iframe into iframe credentialless”. We will 
> > rename to .
> > 
> > For this adjustment to take place, the new plan is to ship in M110 
> instead of M109. We do not think the origin trial will need to be extended, 
> since 
> > partners have been or will be able to test up to M108. Therefore, there 
> will be a gap between the original trial and launch version.
> > 
> > However, renaming from anonymous to credentialless will not answer 
> Mozilla's core argument. They believe that the feature would be best 
> controlled via 
> > multiple new sandbox flags.
>
> I don't think anyone from Mozilla has said that. What I have said is that 
> the current way to control how iframes work is getting very complicated and 
> the new attribute adds yet another mechanism. And if most of the users 
> will use both sandbox and credentialless, understanding how those work 
> together 
> can be rather confusing. Also, credentialless isn't exposing the 
> primitives itself, but some unique set of features. I'd rather see 
> primitives to be
> exposed and other features built on top of them.
>
>
> -Olli
>
>
> We think it is much less ergonomic and makes the feature harder to explain 
> to developers. The integration with sandbox
> > flags has challenging open questions around edge cases, as listed in 
> this document 
> > <
> https://github.com/WICG/anonymous-iframe/blob/main/mozilla-sandbox-proposal.md
> >.
> > 
> > *
> > *
> > 
> > Considering this, we think the current solution is a better one. We have 
> feedback from partners that it solves their needs. Considering that we have 
> > no clear feedback Mozilla would be interested in implementing anonymous 
> iframes even if they were spelled as sandbox flags, we believe we should 
> ship 
> > with what we have implemented.
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "blink-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to blink-dev+...@chromium.org 
> > .
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAzos5GDYwk7ohTD4Eq2TW43hU%3DrHfXsx2V7%2BVK%3DHdKNd02-TA%40mail.gmail.com
>  
> > <
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAzos5GDYwk7ohTD4Eq2TW43hU%3DrHfXsx2V7%2BVK%3DHdKNd02-TA%40mail.gmail.com?utm_medium=email_source=footer
> >.
>
>

-- 
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/19690d52-500e-4b40-8899-b2dd5811b11bn%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in non-secure contexts

['Thomas Steiner' via blink-dev]

The developer-facing documentation is being updated in
https://github.com/GoogleChrome/developer.chrome.com/pull/4299.

On Sat, Nov 12, 2022 at 12:26 AM Ayu Ishii  wrote:

> We've done some extra communications with enterprise partners and have
> come up with a new target milestone.
> The new target milestone for this removal is M110, with enterprise policy
> available for 2 milestones (M110-111).
>
> Thanks!
> Ayu
>
> On Wednesday, June 1, 2022 at 7:49:00 PM UTC-7 Ayu Ishii wrote:
>
>> Thank you all for the approvals!
>> And thank you miketaylr@ for the HTTPArchive analysis!
>>
>> On Wednesday, June 1, 2022 at 1:12:55 PM UTC-7 Mike Taylor wrote:
>>
>>> On 6/1/22 3:52 PM, Yoav Weiss wrote:
>>>
>>> LGTM3
>>>
>>> On Wed, Jun 1, 2022 at 8:58 PM Mike Taylor 
>>> wrote:
>>>
 On 6/1/22 1:34 PM, Chris Harrelson wrote:


 On Tue, May 31, 2022 at 8:26 PM Ayu Ishii  wrote:

> Hi Mike!
>
> With the current usage measurements we see, we hadn't considered any
> enterprise policy for opt-out.
> But certainly can follow the process to do so if you feel that there
> may be risk of undercounting.
> Deprecation of WebSQL in third-party contexts added a policy that
> lasted 3 milestones after deprecation before full removal as an example.
> Although the usages were quite different from that deprecation, we can
> follow the same process if this sounds reasonable.
>

 I think this plan sounds good. LGTM1 once you have an enterprise
 opt-out in place that will remain for 3 milestones. Also please make sure
 to communicate this change in the enterprise notes and other communication
 channels.

 A couple of notes I took last Friday and forgot to post:

 I dumped the list of sites from HTTPArchive (query below) and after
 de-duping them, ended up with 835 sites.

 I then ran a script which naively looks at response codes, and got the
 following results:

 2XX count: 685/835
 3XX to HTTP endpoint count: 74/835
 4XX count: 3/835
 5XX count: 2/835

 So, from this dataset, roughly 9% of those redirect to an HTTP endpoint.

>>> This should say HTTPS, not HTTP. I am bad at typing.
>>>
>>> That said, I think reducing risk of breakage for enterprise environments
 is a useful and friendly thing to do. LGTM2 w/ that done.

 SELECT
   rank,
   url,
 FROM
   `httparchive.blink_features.features`
 WHERE feature = 'OpenWebDatabaseInsecureContext'
 ORDER BY rank ASC



>
> - Ayu
>
> On Monday, May 30, 2022 at 10:57:01 PM UTC-7 Mike West wrote:
>
>> I'm happy to see this moving forward, thanks for pushing it ahead!
>>
>> That said, this seems like the kind of thing that's likely-enough to
>> impact enterprise that we should include a temporary opt-out to give
>> ourselves some wiggle room if it turns out that we're undercounting 
>> usage.
>> Have y'all already put something like that together?
>>
>> -mike
>>
>>
>> On Fri, May 27, 2022 at 2:18 AM Ayu Ishii  wrote:
>>
>>>
>>> *Contact emails *a...@chromium.org, jsb...@chromium.org,
>>> ajayrahate...@google.com
>>>
>>>
>>> *Specification *https://www.w3.org/TR/webdatabase/
>>>
>>>
>>> *Summary *We intend to deprecate and remove usage of WebSQL in
>>> non-secure contexts. Deprecation is targeted for M105 and removal is
>>> targeted for M107.
>>>
>>>
>>> *Blink component *Blink>Storage>WebSQL
>>> 
>>>
>>>
>>> *Motivation *The Web SQL Database standard was first proposed in
>>> April 2009 and abandoned in November 2010. Gecko never implemented this
>>> feature and WebKit deprecated this feature in 2019
>>> .
>>> The W3C encouraged those needing web databases to adopt Web Storage
>>>  or Indexed Database
>>> .
>>>
>>> WebSQL has been deprecated and removed
>>> 
>>> for third-party contexts in M97.
>>>
>>> We hope to entirely deprecate and remove WebSQL at some future point
>>> when usage is low enough.
>>>
>>>
>>> *TAG review *N/A
>>>
>>> Risks
>>> Based on usage measurements
>>> 
>>> rolled out in M97, 0.005% of page loads use WebSQL in a non-secure
>>> context.  Less than 0.01% of top sites have adopted this feature.
>>>
>>> Out of the 20 top sites listed for the month of April 2022, 11 of
>>> the sites use a feature detection library Modernizr 1.5
>>> , on 

[blink-dev] Re: Intent to Implement and Ship: WebUSB Interface Class Filtering

[Reilly Grant]

On Thu, Nov 10, 2022 at 5:57 PM Regimantas Vegele <
regimantas.veg...@gmail.com> wrote:

> Hi,
>
> I was wondering, what way is there today to create a web-app (non-native
> android application) where I'd be able to plug-in a USB camera into an
> android device and be able to use it as an external camera of
> sorts. MediaDevices.getUserMedia() does not seem to work on a mobile
> android device + chrome. It does work on chrome on a pc. My camera is
> detected and I can select it as camera in a browser, but not on mobile. USB
> is blocked as device is a video device.
>

Please file an issue on crbug.com with information about your USB camera
and Android device. External cameras should be available through
getUserMedia() on Android.


> Thanks.
>
> On Tuesday, 20 March 2018 at 21:01:43 UTC+1 rei...@chromium.org wrote:
>
>> Contact emails
>>
>> rei...@chromium.org
>>
>> Summary
>>
>> The following set of USB interface classes, which should not be claimed
>> using the WebUSB API, will be explicitly blocked by Blink: Audio, Video,
>> HID, Mass Storage, Smart Card, Wireless Controller (Bluetooth and Wireless
>> USB). These interface classes are already mostly blocked by an operating
>> system’s built-in class drivers. This change establishes consistency across
>> platforms.
>>
>> Motivation
>>
>> The WebUSB API is designed to provide a mechanism for device
>> manufacturers and developers to build applications supporting novel
>> hardware on the web instead of through native apps. As explained in the
>> original Intent to Ship
>> 
>> for WebUSB, most USB devices fall into one of a number of standardized
>> device classes  for which
>> there are already high-level APIs provided by the Web Platform. For each of
>> these interface classes the high-level API is the supported path and WebUSB
>> is the unsupported path.
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Developers may have implemented workarounds at an operating system level
>> to allow devices of these classes to be claimed by web content using
>> WebUSB. For example, on Windows, a specially crafted INF file can override
>> the system default driver for a particular device with the WinUSB driver.
>> Or, on Linux, udev rules can be configured so that the Linux kernel does
>> not bind a driver to the device. After this change such workarounds will
>> not be possible.
>>
>> Web developers who have deployed any of the workarounds above will likely
>> be negative on this change however the overall benefit to developers of
>> continuing to provide this API for the scenarios in which it is fully
>> supported outweighs this loss of functionality.
>>
>> Ergonomics
>>
>> Not applicable.
>>
>> Activation
>>
>> Not applicable.
>>
>> Debuggability
>>
>> To avoid developer confusion, a specific SecurityError message will be
>> used when the claimInterface() method fails due to this filtering and a
>> message will be logged to the console.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> All platforms other than Android WebView, which currently does not
>> support WebUSB.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> This feature is currently tested by LayoutTests while it is decided to
>> what extent the list of blocked interface classes should be part of the
>> specification or Chrome-specific policy. Moving these tests into
>> web-platform-tests is a trivial change once this question is resolved.
>>
>> Link to entry on the feature dashboard 
>>
>> This is a small change that fits under the existing entry in the feature
>> dashboard for WebUSB.
>>
>> https://www.chromestatus.com/feature/5651917954875392
>>
>> Requesting approval to ship?
>>
>> Yes.
>>
>>

-- 
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%3DMYtFmj7WJ7SCOOe5KiMC4Ptr6NyS53Fx7jgK%3DPrG8zCqQ%40mail.gmail.com.

Re: [blink-dev] Intent to experiment: Deprecate and remove merchant identity in "canmakepayment"

[Chris Harrelson]

Reusing this thread is fine, but please update the chromestatus entry
 to indicate the
"shipping" stage.


On Mon, Nov 14, 2022 at 8:02 AM Stephen McGruer 
wrote:

> Hi folks,
>
> *TL;DR - we are requesting LGTM x3 to Remove this API in M111. Please let
> us know if we need to send a new Intent thread for that.*
>
> As we look at M111 coming up, we realized we made a communication error
> here which we would like to correct. The original post said:
>
> > *Estimated milestones*
> > Origin trial: 108
> > Reverse origin trial: 111
> > Removal: 114
>
> This was a misunderstanding over what Removal meant. We thought "Reverse
> origin trial" implied that the feature would be disabled by default in
> M111, with a reverse-OT to re-enable it if needed, and then Removal was
> when the feature was completely off with no way to re-enable. However based
> on Yoav's comments above, we think API Owners may have thought that we were
> not intending to disable this feature until M114.
>
> So we are explicitly seeking approval to *Remove this API in M111*,
> alongside starting a reverse Origin Trial to guard against developers being
> caught by surprise. To the best of our knowledge this reverse Origin Trial
> will probably be unnecessary, as all known payment partners using
> PaymentHandler do not utilize these fields, however we are including it as
> a safe-guard.
>
> No developer signed up to the current Origin Trial, unfortunately
> (possibly because there is no impact), so we have no data from that.
>
> Please let us know if we should send a separate Intent to Remove thread
> instead, happy to do so.
>
> Thanks,
> Stephen
>
> On Tuesday, October 11, 2022 at 11:00:31 AM UTC-4 Rouslan Solomakhin wrote:
>
>> Hello,
>>
>> FYI, we are renaming the flag and reversing its meaning to make the
>> Origin Trial framework work.
>>
>>- Dev Trial: *chrome://flags/#identity-in-can-make-payment *- enabled
>>by default. Disabling this flag would remove the fields from the
>>"canmakepayment" event.
>>- Origin Trial: *chrome://flags/#clear-identity-in-can-make-payment* -
>>disabled by default. Enabling this flag will remove fields from the
>>"canmakepayment" event.
>>
>> This change is necessary because Origin Trials can only enable runtime
>> flags, not disable them. So, a flag must be default-disabled to be
>> togglable by an Origin Trial. More information is available in Proposal
>> to Fix the CanMakePayment Identity OT
>> .
>> This has also been discussed on blink-reviews-bindings@
>> 
>> .
>>
>> If you are feature-detecting the presence of the fields in the event, the
>> most reliable way is:
>>   if (event.topOrigin) {}
>>   if (event.paymentRequestOrigin) {}
>>   if (evt.methodData && evt.methodData.length > 0) {}
>>   if (evt.modifiers && evt.modifiers.length > 0) {}
>>
>> Cheers,
>> Rouslan
>>
>> On Tuesday, September 20, 2022 at 11:06:03 AM UTC-4 Rouslan Solomakhin
>> wrote:
>>
>>> > Chrome is reaching out to the known partners that may be depending on
>>> these fields.
>>>
>>> We have reached out to the known partners with dev-trial instructions
>>> and received back feedback that this change does not affect their API usage.
>>>
>>> > Estimated milestones
>>> > Origin trial: 108
>>> > LGTM to run Origin Trial removal 108-110
>>>
>>> M108 is upon us. We intend to start the origin trial shortly.
>>>
>>> On Wednesday, April 20, 2022 at 12:03:22 PM UTC-4 Yoav Weiss wrote:
>>>
 LGTM to run Origin Trial removal 108-110

 On Wednesday, April 20, 2022 at 4:27:10 PM UTC+2 Rouslan Solomakhin
 wrote:

> > So this intent is requesting to run the first OT M108-M110?
>
> Correct.
>
> > Any deprecation period you have in mind?
>
> Good point. We should start by printing a warning message when these
> fields are accessed for a few milestones. M105--M107 would be good. Do I
> need to resend this as an intent to deprecate first?
>

 LGTM to deprecate as well. From my perspective, you could start
 deprecating earlier than 105, assuming we know the timelines we're aiming
 for.


>
> On Wed, Apr 20, 2022 at 9:24 AM Yoav Weiss 
> wrote:
>
>> So this intent is requesting to run the first OT M108-M110?
>> Any deprecation period you have in mind?
>>
>> It might be better to send separate intents for the rest when their
>> milestones get closer.
>>
>> On Mon, Apr 18, 2022 at 5:49 PM 'Rouslan Solomakhin' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailsrous...@chromium.org
>>>
>>> Specificationhttps://w3c.github.io/payment-handler/
>>>
>>> Summary
>>>
>>> This is an early heads up that we intend to remove the 

Re: [blink-dev] Intent to experiment: Deprecate and remove merchant identity in "canmakepayment"

[Stephen McGruer]

Hi folks,

*TL;DR - we are requesting LGTM x3 to Remove this API in M111. Please let 
us know if we need to send a new Intent thread for that.*

As we look at M111 coming up, we realized we made a communication error 
here which we would like to correct. The original post said:

> *Estimated milestones*
> Origin trial: 108
> Reverse origin trial: 111
> Removal: 114

This was a misunderstanding over what Removal meant. We thought "Reverse 
origin trial" implied that the feature would be disabled by default in 
M111, with a reverse-OT to re-enable it if needed, and then Removal was 
when the feature was completely off with no way to re-enable. However based 
on Yoav's comments above, we think API Owners may have thought that we were 
not intending to disable this feature until M114.

So we are explicitly seeking approval to *Remove this API in M111*, 
alongside starting a reverse Origin Trial to guard against developers being 
caught by surprise. To the best of our knowledge this reverse Origin Trial 
will probably be unnecessary, as all known payment partners using 
PaymentHandler do not utilize these fields, however we are including it as 
a safe-guard.

No developer signed up to the current Origin Trial, unfortunately (possibly 
because there is no impact), so we have no data from that.

Please let us know if we should send a separate Intent to Remove thread 
instead, happy to do so.

Thanks,
Stephen

On Tuesday, October 11, 2022 at 11:00:31 AM UTC-4 Rouslan Solomakhin wrote:

> Hello,
>
> FYI, we are renaming the flag and reversing its meaning to make the Origin 
> Trial framework work.
>
>- Dev Trial: *chrome://flags/#identity-in-can-make-payment *- enabled 
>by default. Disabling this flag would remove the fields from the 
>"canmakepayment" event.
>- Origin Trial: *chrome://flags/#clear-identity-in-can-make-payment* - 
>disabled by default. Enabling this flag will remove fields from the 
>"canmakepayment" event.
>
> This change is necessary because Origin Trials can only enable runtime 
> flags, not disable them. So, a flag must be default-disabled to be 
> togglable by an Origin Trial. More information is available in Proposal 
> to Fix the CanMakePayment Identity OT 
> .
>  
> This has also been discussed on blink-reviews-bindings@ 
> 
> .
>
> If you are feature-detecting the presence of the fields in the event, the 
> most reliable way is:
>   if (event.topOrigin) {}
>   if (event.paymentRequestOrigin) {}
>   if (evt.methodData && evt.methodData.length > 0) {}
>   if (evt.modifiers && evt.modifiers.length > 0) {}
>
> Cheers,
> Rouslan
>
> On Tuesday, September 20, 2022 at 11:06:03 AM UTC-4 Rouslan Solomakhin 
> wrote:
>
>> > Chrome is reaching out to the known partners that may be depending on 
>> these fields.
>>
>> We have reached out to the known partners with dev-trial instructions and 
>> received back feedback that this change does not affect their API usage.
>>
>> > Estimated milestones
>> > Origin trial: 108
>> > LGTM to run Origin Trial removal 108-110
>>
>> M108 is upon us. We intend to start the origin trial shortly.
>>
>> On Wednesday, April 20, 2022 at 12:03:22 PM UTC-4 Yoav Weiss wrote:
>>
>>> LGTM to run Origin Trial removal 108-110
>>>
>>> On Wednesday, April 20, 2022 at 4:27:10 PM UTC+2 Rouslan Solomakhin 
>>> wrote:
>>>
 > So this intent is requesting to run the first OT M108-M110?

 Correct.

 > Any deprecation period you have in mind?

 Good point. We should start by printing a warning message when these 
 fields are accessed for a few milestones. M105--M107 would be good. Do I 
 need to resend this as an intent to deprecate first?

>>>
>>> LGTM to deprecate as well. From my perspective, you could start 
>>> deprecating earlier than 105, assuming we know the timelines we're aiming 
>>> for.
>>>  
>>>

 On Wed, Apr 20, 2022 at 9:24 AM Yoav Weiss  
 wrote:

> So this intent is requesting to run the first OT M108-M110?
> Any deprecation period you have in mind?
>
> It might be better to send separate intents for the rest when their 
> milestones get closer. 
>
> On Mon, Apr 18, 2022 at 5:49 PM 'Rouslan Solomakhin' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsrous...@chromium.org
>>
>> Specificationhttps://w3c.github.io/payment-handler/
>>
>> Summary
>>
>> This is an early heads up that we intend to remove the merchant 
>> origin and arbitrary data from the "canmakepayment" service worker 
>> event of the Payment Handler API. These are the event fields to be 
>> removed:
>>
>>
>>- topOrigin
>>- paymentReuqestOrigin
>>- methodData
>>- modifiers
>>
>> The removal will be happening