BroadcastChannel being blocked need permissions dialog

[taf2]

There needs to be away to allow an application that's embedded into a third party application like Salesforce, HubSpot, Zoho to still send messages back and forth between a WebRTC popout window and an embedded iframe. Web applications that need persistent connection to carry a voice call while still allowing the UI page to be reloaded are SOL with new privacy storage changes that were rolled out in Chrome 121. BroadcastChannel was an effective way for an iframe to communicate with a popout window. Further I would suspect if the iframe is the window.opener of the popout window they should* be able to communicate and be treated as the same "partition". I can see other tabs that are open separate outside of the iframe not being shared but if the original origin with the iframe did the window.open call would make a lot of sense to allow BroadcastChannel to postMessage and receive messages between the parent and child on the same origin.

At the very least having something like: ```

const handle = await document.requestStorageAccess({all: true});

handle.postMessage...
handle.onmessage

// or something similar or someway to send messages

IMO - these changes continue to push more web applications to consider desktop/mobile as the only viable path forward.

[wanderview]

I believe this is available in this origin trial:

https://developers.google.com/privacy-sandbox/blog/saa-non-cookie-storage

[taf2]

Sorry if I'm not seeing it - but the only things I see available in chrome 121 (current release)

caches: CacheStorage {}
indexedDB: IDBFactory {}
localStorage: Storage {}
locks: LockManager {}
sessionStorage: Storage {length: 0}

I'm not seeing BroadcastChannel, and trying to use it still fails with the origin trial. It appears to only work if chrome://flags/#third-party-storage-partitioning is disabled.

[wanderview]

@arichiv Can you help here? The blog post suggests BroadcastChannel was added in M121.

[arichiv]

The code went in trunk November 10 https://chromium-review.googlesource.com/c/chromium/src/+/5012979 and the branch cut for M121 was December 4 https://chromiumdash.appspot.com/schedule.

I think what you're seeing are the object members, and if you expand the prototype section you will see the BroadcastChannel function listed.

[taf2]

@arichiv ok thank you i see

const handle = await document.requestStorageAccess({all: true});
const bc = new handle.BroadcastChannel("channel")

I don't see documentation around being able to only request access to BroadcastChannel...

Any clarification to add on the expected June end of the origin trial. Is this then going to potentially be accepted and an API we can count on or do we need to start work on a native solution to avoid future outages related to modifications to the web platform?

[arichiv]

There's no 'new' needed in this context, try:

const handle = await document.requestStorageAccess({BroadcastChannel: true});
const bc = handle.BroadcastChannel("channel");

Depending on usage/feedback from developers and other browser vendors we hope it'll be generally available.

[taf2]

@arichiv

Thank you for the usage clarification!

• hoping there remains away to keep web applications viable... not everything is about ads (really enjoy building on the web!)

[arichiv]

I spent a bunch of time this month adding SharedWorker support, so I'm rooting for the API at least :-)

[taf2]

@arichiv i'm sorry i am still running into an issue or maybe misunderstanding of the way this should* work - (running a bit of a fever right now so might just be doing something silly)

Here is how my application works:

Within Salesforce I have an embedded iframe (OpenCTI AdapterURL) is pointing to my domain (calldomain.example.com/salesforce_phone)

I have a web component tag in a shadow DOM (sharing in case this matters) that class instance exposes a launch phone button.

the DOM within salesforce:

In the connectedCallback:

Controller UI in embedded iframe.

  connectedCallback() {
    this.shadow = this.attachShadow({ mode: 'open' });
    this.enableElement();
  }

  async enableElement() {
    // see: https://github.com/privacycg/storage-partitioning/issues/44
    if (typeof(document.requestStorageAccess) == 'function') {
      console.log("requestStorageAccess");
      this.context = await document.requestStorageAccess({BroadcastChannel: true});
      this.phone_channel = this.context.BroadcastChannel('__phone_device');
    } else {
      this.phone_channel = new BroadcastChannel('__phone_device');
    }
...

After getting an access token it pops a window passing that token to the popout window:

Click handler to launch phone device when it's not detected

  async openDevice() {
    try {
      const auth = await this.getLoginAccessToken();
      const windowFeatures = "width=600,height=450,menubar=no,location=no,resizable=no,scrollbars=yes,status=yes";
      window.open(`https://${window.location.hostname}/phoneapp/token?session=${auth.sessionId}&token=${auth.token}&email=${auth.email}`, "CT
    } catch (e) {
      this.displayAccessTokenError(e);
    }
  }

From which the popout window is defined by a device web component. That class handles the WebRTC elements of the communication and uses a BroadcastChannel created in it's connectedCallback to pass messages back and forth between the CRM embedded iframe interface. This allows the communication channel to be decoupled from the UI. Meaning agents can reload the page without dropping a phone call...

Device element:

  connectedCallback() {
    this.shadow = this.attachShadow({ mode: 'open' });
    this.enableElement();
  }

  async enableElement() {
    if (typeof(document.requestStorageAccess) == 'function') {
      console.log("requestStorageAccess");
      this.channel = (await document.requestStorageAccess({BroadcastChannel: true})).BroadcastChannel('__phone_device');
    } else {
      this.channel = new BroadcastChannel('__phone_device');
    }

What i'm missing is messages between the channels are not received even when using document.requestStorageAccess to get access to the channel... Should i see UI asking me to grant permission? Also interestingly when I add the conditional code to requestStorageAccess now when toggling the feature off here: chrome://flags/#third-party-storage-partitioning the communication remains broken. e.g. using requestStorageAccess must not be correct within the iframe to the popout window...

[arichiv]

Is cookie partitioning on? Without that you won't see the prompt.

Also:
(1) you will have had to interact with the iframe's origin as a top-level site at some point prior
(2) the call to requestStorageAccess must be called in the event response to some sort of user interaction (click) within the iframe

[taf2]

for (2) interesting I actually am not setting any cookies on my domain. The phoneapp loads within salesforce it's possible on page load an agent might click on the launch phone button before clicking on anything within the saleforce UI... Salesforce OpenCTI unfortunately does not allow us to expose a CallCenter adaptor that is not loaded in an iframe first...

(1) ah... this is problematic would this apply also to the popout window that was open in a response to a click as well?

[taf2]

If my understanding is correct with this new change there would be no way to have the child popout window signal to the parent iframe without having a user first interact by clicking on the salesforce.com interface and then clicking in the iframe and then clicking in the popout....

[arichiv]

Yes, interaction must happen in some top level frame on an origin, and then independent interaction must happen in the iframe for that same origin for requestStorageAccess to be callable.

It doesn't matter if you set cookies or not, the prompt only appears if third party cookies are off.

The other option is: https://developers.google.com/privacy-sandbox/3pcd/related-website-sets

[taf2]

Anyway someone from salesforce.com is going to allow related website sets...

[taf2]

@arichiv should we get an exception if we don't get access to the feature? I'm noticing I get a handle with what appears a valid handle.BroadcastChannel but it does not allow communication between my iframe and the popout window that my iframe opens. Does the popout window need to also request access or is it just the iframe? What is a good way of knowning when to directly use new BroadcastChannel vs requesting permission?