Can not initialize a Power-Up in chrome when third party cookies are blocked

Hi again its me :wave: ,

This time with another pondering question :blush:

I’m not able to run a trello powerup under chrome Version 84.0.4147.89 (also has been reported on Safari 13+)

I get the following exception:

Uncaught (in promise) DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
    at new Pn (https://p.trellocdn.com/power-up.min.js:1:126215)
    at Rn.init (https://p.trellocdn.com/power-up.min.js:1:127994)
    at Un.initialize (https://p.trellocdn.com/power-up.min.js:1:132217)
    at initTrello (webpack:///./src/index.js?:9:31)

From using the following code:

window.TrelloPowerUp.initialize(
  {
    
  },
  {
    appKey: '...',
    appName: '...',
  },
)

Here is full output log from my workstation:

As far as I understand the issue is connected to the fact that in Chrome/Mac the seemingly default for some users is ‘Block 3rd party cookies’ setting been ON and it does produce the above exception.

update: seems this is a bug in chrome (?) and others have experienced it too see https://github.com/launchdarkly/js-client-sdk/issues/138

When changing that setting to ‘block 3rd party cookies in incognito’ it all works as expected.

Asking users to play with chrome settings is a way to mitigate the issue (still I doubt about its user friendliness :slight_smile: )

Do you have similar problems and do you know of any workaround to make trello powerup play nicely for those users having this setting (misaligned ?) ?

Yes, it appears that default Incognito settings in Chrome cause Power-Ups to fail to work as expected.

We’ll certainly explore what is within our power to handle this, but our general response to users reporting problems related to this is likely going to be something like, “Unfortunately, Power-Ups require that 3rd party cookies not be blocked. If you’d like Power-Ups to work as expected, please consider updating your browser’s settings accordingly.”

1 Like

That being said, this is only happening, as you mentioned, because you’re initializing with the appKey bit so that you can use the REST API helper.

We should fix this and fallback accordingly, but that work hasn’t been prioritized.

If you wanted to workaround this you could reimplement some of what the REST API helper does for you (ask user to authorize, store the token) and then fallback accordingly if localStorage is not available.