Bug 299531 – REGRESSION (iOS 26): Popups timed incorrectly on websites using Hubspot CTA due to localStorage access being blocked

• Component: Website Storage
• Status: RESOLVED FIXED

[Conor Linehan]

Created attachment 476856 [details]
Local Storage not working from https://js.hubspot.com/web-interactives-embed.js

We have a product at Hubspot called CTAs which displays popups to our customers’ site visitors.

One of the features of this product is being able to set a timeout period before a popup shows.
The way we achieve this is by writing a timestamp to localStorage  keyed by the id of the popup and then determining if we should show the popup or not depending on how recently it’s been seen.

Yesterday, we became aware that this throttling behavior wasn’t working on Safari after a Mac OS update ( Safari version 26.0.1 ) and that popups would not experience a cooldown period before showing again.

The issue is that localstorage values can’t be read or written from a script coming from https://js.hubspot.com/web-interactives-embed.js while they do work from other domains e.g our qa version https://js.hubspotqa.com/web-interactives-embed.js

We've fixed this at the moment by falling back to IndexedDB if localStorage isn't usable (though it is available)
This is the check we are doing
```
const isLocalStorageUsable = () => {
  if (localStorageUsable == null) {
    try {
      localStorage.setItem('hs-cta-test', 'test');
      const result = localStorage.getItem('hs-cta-test');
      localStorage.removeItem('hs-cta-test');
      localStorageUsable = result === 'test';
    } catch (error) {
      localStorageUsable = false;
    }
  }
  return localStorageUsable;
};
```
We have a few questions.
Is this intentional? I know there's a 7 day window for ITP scripts but it doesn't mention preventing writes and reads.
Is this is an issue with our domain or the fact we are third party on our customers webpages
Also will this behavior be brought to IndexedDB?


Example page with a CTA https://cdpn.io/pen/debug/vELNvmB?localStorage=true


Thanks and let me know if ye have any questions.

[Radar WebKit Bug Importer]

<rdar://problem/161424408>

[Sihui Liu]

Not able to read / write localStorage is not intentional behavior.  Third-party context does have limited access. For example, it might only have access to in-memory storage that cannot persist across app relaunch; and it might only have access to partitioned storage (i.e. "example2.com embedded in example.com" will use different storage from "exampe2.com embedded in example2.com"). But window.localStorage is still expected to be functional with ITP, i.e. your example should still work.

If we do want to block localStorage access in certain case (i.e. WebKit client specifies to block all third-party storage), then the policy should be applied to all storage types. You mentioned IndexedDB works, and other domain works, so this does not seem like that.

A few questions:
- For the `localStorageUsable` function above, what is the exact behavior you get? Do you get an error?
- Does sessionStorage work correctly? (localStorage has similar implementation as sessionStorage, except that localStorage uses a persistent backend, so I wonder if there is bug there)
- Is there a way for us to try reproducing the issue (e.g. test site)?
- Could you reproduce the issue on Safari Technology Preview 229? It can be downloaded at https://developer.apple.com/safari/resources/. (It contains a latest fix to crash in localStorage area).

[Conor Linehan]

Hey Sihui we've tried to reproduce in Safari Technology Preview 229 and the issue is fixed there.

To reproduce you can go here https://cdpn.io/pen/debug/vELNvmB?localStorage=true and close the popup,
if there's data saved to localstorage it's working, but if it has fallen back to indexedDB it's bugged.

Thanks

[Sihui Liu]

Thanks Conor! I could reproduce the issue now. Will investigate and provide more info to you.

[Wenson Hsieh]

Pull request: https://github.com/WebKit/WebKit/pull/52131

[EWS]

Committed 301327@main (ed98ad21fc2b): <https://commits.webkit.org/301327@main>

Reviewed commits have been landed. Closing PR #52131 and removing active labels.