Client throws exception on third disabled third party cookies and Chrome, when running in iFrame

[dr-divu]

In Google Chrome, going under Settings > Advanced > Privacy and security > Content Settigns > Block third-party cookies, and enabling the Block third-party cookies option will break the initialize function of the ldclient-js.

Our application is running in an iFrame, hosted on a different domain, so localStorage is considered as a third-party cookie in this scenario.

Wrapping any access to the localStorage object (even checking it's value) in a try catch solves this problem. Currently I have to wrap the whole LaunchDarkly part of the codebase.

Eg.

// throws exception
if (localStorage) localStoorage.getItem('foo)'

// throws exception
localStorage.getItem('foo')

// doesn't throw exception
try {
  localStoorage.getItem('foo)'
} catch (e) {
  // cookies disabled, use default value
}

// throws exception
const client: LDClient = LaunchDarkly.initialize(key, user, options)

// doesn't throw exception

try {
  const client: LDClient = LaunchDarkly.initialize(envApiKey, user, options)
} catch (e) {
  // cookies disabled, use default value
}

[eli-darkly]

Hmm. I can see why local storage would be blocked for an iframe with a different origin if third-party cookies are blocked... but I am surprised that just accessing window.localStorage at all, without calling getItem or setItem, would throw an exception. If that's the case, then this should be an easy fix, since we already do have try/catch blocks around all the getItem and setItem calls (at least, in the current version of the SDK; I don't know which version you're using).

Thanks for bringing this to our attention.

[dr-divu]

Thanks for looking into it. I was using 2.7 of the js client, but the 2.9 behaves the same. Yes, this is quite unexpected, I wasn't expecting this setting to throw an exception.

[eli-darkly]

Yeah, unfortunately 2.9 may have made the problem slightly worse, because it always checks the browser capabilities at initialization time—so (I think) it would trigger this error regardless of whether you had actually specified bootstrap: 'localstorage'—whereas prior to 2.9, if you did not do that then it wouldn't look at window.localStorage at all.

We'll have a patch release to address this soon.

[dr-divu]

Thanks for the quick answer!

[eli-darkly]

We've released version 2.9.4 which should fix this. Sorry about the inconvenience.