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

I've updated the blog so that it's clear that this change is not happening in Chrome 112. Has the new milestone been determined yet? On Mon, Apr 3, 2023 at 11:27 PM Marijke Hoste wrote: > Thanks for the update indeed! > > On the Ente

Re: [blink-dev] Re: Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

Hi Eric, On 4/13/23 8:13 PM, Eric Lawrence wrote: What I mean by "hard to reason about" is that we are, retroactively shipping changes to APIs such that they no longer "do what they say on the tin"-- BroadcastChannels no longer broadcast, SharedWorkers are no longer shared, etc. That's only p

Re: [blink-dev] Re: Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

Right, it's lumped under the Communication API section of the explainer. We could call it StorageKey Partitioning to be more precise, but I'm not sure that gains us much. On 4/13/23 8:09 PM, Alex Russell wrote: It's going to be surprising to developers that BroadcastChannel is "storage" On T

Re: [blink-dev] Re: Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

What I mean by "hard to reason about" is that we are, retroactively shipping changes to APIs such that they no longer "do what they say on the tin"-- BroadcastChannels no longer broadcast, SharedWorkers are no longer shared, etc. When we change longstanding behaviors, we break existing code, and f

Re: [blink-dev] Re: Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

It's going to be surprising to developers that BroadcastChannel is "storage" On Thu, Apr 13, 2023, 4:30 PM Domenic Denicola wrote: > I don't think there's much that's hard to reason about here. Storage is > being partitioned, uniformly. It's the same for BroadcastChannel as it is > for localStor

Re: [blink-dev] Re: Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

I don't think there's much that's hard to reason about here. Storage is being partitioned, uniformly. It's the same for BroadcastChannel as it is for localStorage or IndexedDB. IdP-subframe-in-RP will uniformly be treated as different from IdP-as-top-level, with regard to storage access. I sympath

[blink-dev] Re: Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

My read of this: https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md#communication-apis is that BroadcastChannel will not allow a IdP loaded in a top-level frame to communicate authentication tokens to IdP subframes within RP websites (Approach #4 in https://text

Re: [blink-dev] Allow Navigator.registerProtocolHandler to register "payto"

Thank you. Created https://chromestatus.com/feature/5199727026503680 On Thursday, April 13, 2023 at 4:57:13 PM UTC+2 mike...@chromium.org wrote: > Got it - we'll treat this as an Intent to Prototype then (typically an > Intent starts with "Intent to Prototype" (or Experiment, Ship, etc.). > > Yo

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

"Below 1 second" for something that can block the main thread is not particularly heartening. Can you please provide the histogram data you're seeing to justify this? Would you be happy to raise the cap to a larger (but still fixed) size based on a baseline device config instead?, e.g.: https:/

[blink-dev] Re: PSA: Web MIDI Permissions Prompt Change

A correction. The permission prompt will not be released on Webview at this time. This is planned for to be revisited later. On Wednesday, April 5, 2023 at 4:54:20 PM UTC-7 Ajay Rahatekar wrote: > Contact emails > > mjwi...@chromium.org, sinaf...@chromium.org, hong...@chromium.org > > Specificat

Re: [blink-dev] Intent to Ship: Quick intensive timer throttling of loaded background pages

Hi Blink API owners, The experiment has been running on 50% of stable for 4 weeks. There are no regressions to guiding metrics on any platform and I'm not aware of any breakage. Median CPU usage is reduced by 1% on Windows and Mac. IIUC, I already have your LGTM

Re: [blink-dev] Intent to Extend Experiment: Privacy Sandbox Ads APIs

Hi John, Could you comment on any additional progress made in the 5 required areas for OT extensions (see https://www.chromium.org/blink/launching-features/#origin-trials)? thanks, Mike On 4/12/23 5:44 PM, John Delaney wrote: Greetings, We would like to extend the origin trial for all of t

Re: [blink-dev] Allow Navigator.registerProtocolHandler to register "payto"

Got it - we'll treat this as an Intent to Prototype then (typically an Intent starts with "Intent to Prototype" (or Experiment, Ship, etc.). You'll want to create a chromestatus.com entry with the proposed new feature (see https://www.chromium.org/blink/launching-features/#launch-process - tha

Re: [blink-dev] Allow Navigator.registerProtocolHandler to register "payto"

Sure, Mike. As the protocol is defined in RFC 8905, it may be implemented in the system. The bug is located here: https://bugs.chromium.org/p/chromium/issues/detail?id=1432881 Prototype and PR are in progress. On Thursday, April 13, 2023 at 3:28:27 PM UTC+2 mike...@chromium.org wrote: > Hi Ra

Re: [blink-dev] Intent to Remove: Support for Web Push Notifications using FCM Sender IDs

LGTM3 On 4/12/23 11:14 AM, Daniel Bratell wrote: LGTM2 /Daniel On 2023-04-12 14:20, Yoav Weiss wrote: LGTM1 On Wed, Apr 12, 2023 at 2:04 PM Peter Beverloo wrote: On Wed, Apr 12, 2023 at 12:02 PM Yoav Weiss wrote: Sounds like breakage is tolerable, and senders would be

Re: [blink-dev] Allow Navigator.registerProtocolHandler to register "payto"

Hi Rastislav, Can you clarify - do you intend to prototype this? Do you have a bug or CL where you're doing the work? thanks, Mike On 4/13/23 5:24 AM, Rastislav Vašička wrote: Explainer A unified URI scheme for all payment target types allows applications to offer user interactions with URI

[blink-dev] Allow Navigator.registerProtocolHandler to register "payto"

Explainer A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications. Specification RFC 8905 Summary Add

[blink-dev] Intent to Extend Origin Trial (3): Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

Contact emails v...@chromium.org cl...@chromium.org Explainer https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k Specification https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects Design docs Including the new security requirements https://developer.mozi