Add function Cookies.enabled(): bool that returns if cookie access is enabled

[cdrini]

Is your feature request related to a problem? Please describe.
Cookies are disabled when a page is in a sandboxed iframe. In this case, trying to access document.cookie throws an error:

SecurityError: Document.cookie getter: Forbidden in a sandboxed document without the 'allow-same-origin' flag.

Describe the solution you'd like
It would be helpful to have a function from the Cookies library to check.

Describe alternatives you've considered
I've implemented my own:

function cookies_enabled() {
  try {
    // In security locked iframes, document.cookie throws an error.
    document.cookie;
    return true;
  } catch (e) {
    return false;
  }
}

Additional context
Add any other context or screenshots about the feature request here.

[carhartl]

Isn‘t that what’s navigator.cookieEnabled is for? Have you tried it?

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/cookieEnabled

[cdrini]

Great suggestion! I just tested, and unfortunately it appears to return true in this case 🙃

[cdrini]

I tested by:

1. Go to https://www.betterworldbooks.com/product/detail/bridges-0393731367
2. Click "See preview"
3. In dev tools, toggle the iframe's console.
4. Type navigator.cookieEnabled. Returns true
5. Type document.cookie. It errors

[carhartl]

This has been discussed in #115 and #531

So far we‘ve been rejecting this feature. In particular regarding sandboxed iframes please see: #531 (comment) — I haven’t changed my mind on this.

[carhartl]

That said — if you have to deal with an iframe of which you don‘t know if it‘s sandboxed or not, the error handling imo is correctly located in userland. We will not be able to deal with this in a way that suffices all cases. And if you try to access cookies in a (knowingly) sandboxed iframe, even more so throwing an error, e.g. doing nothing on our side, is the right thing to do, namely signaling the mistake to the developer.

[cdrini]

My apologies for not finding those existing issues! To be clear I think it makes sense for e.g. Cookies.get to error, for the reasons you've mentioned. But I still think a Cookies.enabled() method is potentially useful! I've had to implement a function to try/catch document.cookie a few times now, and if such a fn was in Cookies it would be handy. And in my mind it makes sense since Cookies is a small helper library to make working with cookies more sane, and to avoid the boilerplate one usually needs to access cookies. Handling document.cookie throwing an error has recently been one of those cookie boilerplate for me.

But if that use case doesn't make sense for the library, that's fine, too 😊 Thanks for your help! Feel free to close as necessary.

[FagnerMartinsBrack]

@carhartl Alternatively, we can use this issue to document the Error that can be thrown on Cookies.get as part of the contract of the API. That means we need to simulate non-sandboxed iframes in a test and check it throws the same across browsers.

I believe Cookies.enabled() is also a pointless exercise as there's no way for us to know.

Actions from this thread:

1. Test the behaviours of non-sandboxed iframes across 99% of major browsers, do they throw the same Error type? Can we detect it?
2. Write a test to throw that error
3. Document the Error can be thrown in non-sandboxed iframes so users can handle that with try/catch in userland.