Re: [blink-dev] Intent to Implement and Ship: Remove Payment Request User Activation Requirement

LGTM3 On 6/28/23 2:06 AM, Stephen Mcgruer wrote: Thanks Mustaq for your input (and API OWNERS for the ongoing LGTMs, here's hoping for #3 :)). I agree with your points on the difficulty of making either user activation or capability delegation work across navigation (though I still personally

Re: [blink-dev] Re: Intent to Ship: Barcode Detection API

There is currently no plan to ship this on Windows because the underlying platform does not provide a barcode detection capability. Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome On Tue, Jun 27, 2023 at 6:36 AM Matt Dean wrote: > > Hi,

RE: [blink-dev] Intent to Experiment: EditContext API

Hi Nicola, The textformatupdate event does not get fired in response to browser spell checking. It's only used for decorations applied by IMEs to give hints to users during composition, e.g. thin/thick underlines for "phrase mode" in Japanese IME. Spell checking for an EditContext depends on

[blink-dev] Intent to Deprecate: Remove non-standard appearance keywords

Contact emailsdizha...@chromium.org ExplainerNone Specificationhttps://drafts.csswg.org/css-ui-4/#appearance-switching Summary Since only standard appearance keywords should be supported, we are removing the appearance (and -webkit-appearance) keywords that are only meant to be used

[blink-dev] Intent to Prototype: Partitioning :visited links history

Contact emails kyraseev...@chromium.org Explainer https://github.com/kyraseevers/Partitioning-visited-links-history Specification TBD Summary To eliminate user browsing history leaks, anchor elements will be styled as :visited if and only if they have been visited from the same top-level

Re: [blink-dev] Intent to Ship (I2S): Protected Audience

Yoav, Protected Audiences has been fortunate to have a ton of design contributions and feedback, but consequently has a lot of issues filed. We try to respond to all issues, as you can see by the discussion comments on nearly all issues. I went through and triaged all the issues recently. I

Re: [blink-dev] Intent to Ship: Attribution Reporting API

Thanks, Yoav and Rick for the questions/discussion. See responses below. Can you expand (or point to existing docs) about the differences between > this and PCM? What's the likelihood of future convergence? What are > developers expected to do in the meantime? > Unfortunately, while we were able

Re: [blink-dev] Intent to Ship: Make CaptureController derive from the EventTarget interface

Hello, To elaborate a bit more on this, it's a small IDL change to make the CaptureController interface derive from the EventTarget interface: https://github.com/w3c/mediacapture-screen-share/issues/268

[blink-dev] Intent to Ship: Make CaptureController derive from the EventTarget interface

Contact emails fw...@chromium.org Explainer None Specification https://w3c.github.io/mediacapture-screen-share/#dom-capturecontroller Summary The CaptureController interface enables further manipulation of a screen capture session. In the future, it is

Re: [blink-dev] Re: Intent to Ship: Barcode Detection API

Hi, is there any progress on shipping this to windows? Thanks Matt On Thursday, 9 December 2021 at 19:00:42 UTC Reilly Grant wrote: > Apologies, I spoke too soon. We'll be holding off shipping this on Windows > and Linux for the time being. Android, macOS and Chrome OS continue to > support

Re: [blink-dev] Intent to Implement and Ship: Remove Payment Request User Activation Requirement

Thanks Mustaq for your input (and API OWNERS for the ongoing LGTMs, here's hoping for #3 :)). I agree with your points on the difficulty of making either user activation or capability delegation work across navigation (though I still personally think there are reasonable use-cases! :D). We're

Re: [blink-dev] Intent to Prototype: Zstd Content-Encoding

On Tue, 27 Jun 2023 at 11:42, Adam Rice wrote: > Our mitigations if a serious compatibility issue should occur are more > effective with Chrome. If we discovered we needed to urgently disable zstd > we could do it with a config push. However, in the case of WebView every > app would have to

Re: [blink-dev] Intent to Prototype: Zstd Content-Encoding

Our mitigations if a serious compatibility issue should occur are more effective with Chrome. If we discovered we needed to urgently disable zstd we could do it with a config push. However, in the case of WebView every app would have to start at least once in the broken configuration before the

Re: [blink-dev] Intent to Prototype: Zstd Content-Encoding

Unless you have specific reasons to believe that there are going to be compatibility issues that are specific to WebView and a plan for how they're going to be addressed, we would strongly prefer that the rollout happens at the same time for WebView. On Tue, 27 Jun 2023 at 08:10, Mihai Cîrlănaru

Re: [blink-dev] Intent to Prototype: Zstd Content-Encoding

Thank you for the clarification, Nidhi! Could you expand on the compatibility issues that might come up here? Given the overlap WebView has with Chrome in terms of source code, these might apply to both. Nevertheless, having WebView in the experiments from the start will help uncover WebView

Re: [blink-dev] Intent to Experiment: EditContext API

Hi, from a privacy perspective we have some concerns regarding the spellchecker section: we enforced in the past the concept that websites should not learn about the user dictionaries [1] and it seems like the spellcheking API proposal could leak those via the *textformatupdate *event. Was

Re: [blink-dev] Intent to Implement and Ship: Remove Payment Request User Activation Requirement

LGTM2 conditional on the PR landing On Mon, Jun 26, 2023 at 5:02 PM Rick Byers wrote: > This makes good sense to me. Obviously there's so much risk and potential > for abuse around payments, getting the user to click seems like a very weak > mitigation anyway (eg. the prevalence of "click to