Storage partitioning in Web Agent Console (experimental workaround)

This article outlines an experimental workaround to address browser storage partitioning issues in ‘parent-child’ Web Agent Console (WAC) iframe setups, or customers accessing sessionStorage or localStorage of the WAC, or are using the browser flag --disable-features=ThirdPartyStoragePartitioning.

Storage partitioning changes by Google and Microsoft are already active  and are impacting browser storage access. These changes affect shared browser storage between iframes, which is critical for ‘parent-child’ WAC configurations.

To mitigate this, some customers are using the browser flag --disable-features=ThirdPartyStoragePartitioning. This flag might be deprecated  in Microsoft Edge version 145. Google Chrome’s timeline is currently unknown.

Workaround summary

We’re introducing a query string–based opt-in workaround that showed promising results in lab testing. This workaround is experimental, and we encourage you to test it and share feedback on its effectiveness in your environment.

Testing instructions

This section outlines the testing instructions for the experimental workaround.

Baseline test

  • Don’t start the browser with the --disable-features=ThirdPartyStoragePartitioning flag.
  • Observe behavior during incoming calls.
  • Expected failure: Child WAC may show an “unauthorized” message and fail to handle the call.

Opt in to workaround

  • Add storageMethod=1 to the WAC iframe URL.
  • Refresh the page after updating the URL.
  • If the workaround is functioning correctly, incoming calls should be handled successfully by the child WAC without showing an “unauthorized” message.

URL examples:

  • Child WAC: https://<agent-console-url>/call-handling/<conversation-id>?storageMethod=1
  • Parent WAC (depends on customer’s setup): https://<agent-console-url>/call-monitoring/login?storageMethod=1

Production trial

  • If successful in lab, test with one or several agents in production.
  • Monitor behavior and confirm stability.

Key notes

The following key notes are important to consider:

  • This workaround is designated for setups using shared browser storage between ‘parent-child’ WAC iframes, as well as any script that might access the WAC’s session or local storage.
  • Only supported in Microsoft Edge and Google Chrome. Other browsers (for example, Mozilla Firefox) aren’t officially supported and some of them don’t seem to support the workaround.
  • Customers using the --disable-features=ThirdPartyStoragePartitioning flag are required to opt-in and are expected to share feedback on whether the workaround was needed and if it worked.
  • Depending on your setup, the workaround might need to be applied to both the parent and child WAC iframe URLs. Ensure to test accordingly.
  • Gatekeeper doesn’t control browser flags or browser update cycles. Upgrade browsers with caution and after testing.

FAQs

This section addresses frequently asked questions about the workaround.

Who should care about this change?

Customers using WAC in ‘parent-child’ iframe setups or use WAC’s local or session storage, especially those relying on shared browser storage and using the --disable-features=ThirdPartyStoragePartitioning flag.

What happens if I don’t opt in to the workaround?

Once the flag is deprecated, shared storage may break, causing the child WAC to fail handling calls, typically showing an “unauthorized” message.

Is this workaround supported in all browsers?

The workaround is only supported in Microsoft Edge and Google Chrome. Other browsers, such as Mozilla Firefox, aren’t supported and don’t seem to support the workaround.

How do I opt in to the workaround?

Add storageMethod=1 to the WAC iframe URL (child – required; parent – depending on setup). Refresh the webpage after updating the URL.

What is this workaround?

The workaround uses the browser’s requestStorageAccess  API to restore access to storage that might be blocked by partitioning in embedded WAC setups.

What should I do after testing in the lab?

If the workaround works in your lab setup, try enabling it for one or several agents in production. Then, share feedback on whether it was needed and if it worked. Ensure to share your feedback with the Gatekeeper support team.

I performed the baseline test and it did not fail. Do I still need the workaround?

Possibly not. However, we recommend testing the workaround to ensure compatibility and confirm it doesn’t introduce side effects.

How do we know if the workaround will continue working?

We researched potential blockers and found no indication that the workaround will stop working, but this isn’t guaranteed.

What happens if the browser is upgraded and the workaround stops working?

Try re-adding the --disable-features=ThirdPartyStoragePartitioning flag. If that doesn’t help, downgrade the browser or switch between Microsoft Edge and Google Chrome and retest.

Ensure to report the broken version, so it can be investigated.

No. Unauthorized messages can occur for many reasons unrelated to storage partitioning.

How do I know if I applied the workaround correctly?

Click the log icon (<>) in WAC. Look for a message as follows:

Storage: unpartitioned (path: <some path>)

Or select DevTools > Console and check for messages starting with Storage:.

If it isn’t working, report back with:

  • WAC logs from the log icon (<>)
  • Console logs (right-click > Copy Console)