Interoperability with `document.cookie` when all cookies are blocked

[tomayac]

Consider the following code:

// All cookies are blocked in browser settings.

document.cookie = 'silently=ignored'; 
// > 'silently=ignored'
document.cookie;
// > ''

await cookieStore.set('throws', 'on-write');
// > Uncaught DOMException: An unknown error occured while writing the cookie.
await cookieStore.getAll();
// > []

To align with document.cookie's write behavior, should write operations for the Cookie Store API fail silently when cookies are blocked? The reading behavior is the same, both act as if there were no cookies by returning an empty string or an empty array respectively. The writing behavior is different, though.

— Meta: Chrome's implementation misspells "occurred" (https://crbug.com/1359247).

[bsittler]

I believe the failures in document.cookie writes are silent to avoid breaking too many older scripts written in an earlier era of no blocking that assume a write cannot fail. As a new API, cookieStore is not bound by that constraint. Similarly, cookie writes on a page whose storage access is deprived via content-security-policy: sandbox or by by virtue of being a data: URL do throw exceptions, since those are environments where such writing has never succeeded previously

[annevk]

This concern seems similar to #182. As with that issue, I don't think parity with document.cookie on the setter side is important.

It does seem plausible you'll run into exceptions in certain corner cases, but if that becomes a big issue we can usually remove exceptions, whereas adding them later on is always impossible.