User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Visit a Classic Google Site that features an HTML Box Gadget. Any site will do as long as it features an HTML Box. Visiting the following test site demonstrates the issue: https://sites.google.com/site/nightlytest163/

Actual results:

The contents of the HTML Box will not be visibly displayed, yet when viewing the source of the page the contents within the HTML Box are still there.

Expected results:

The contents of the HTML Box as per the test site "My First Heading" and "My first paragraph." should be displayed in FireFox Nightly 80.0.1, as they correctly display in Firefox 78.0.1.

Prior screenshot had only Nightly refreshed, this screenshot was taken with both Nightly 80.0.1 and Firefox 78.0.1 refreshed to default no-addon configuration.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Thanks for the reproducible test case. When the site fails clearStorage throws DOMException: The operation is insecure. I tracked this down to Bug 1628486, so this is a Nightly only problem. Setting network.cookie.cookieBehavior to 4 fixes this.

(In reply to Tom Schuster [:evilpie] from comment #3)

Thanks for the reproducible test case. When the site fails clearStorage throws DOMException: The operation is insecure. I tracked this down to Bug 1628486, so this is a Nightly only problem. Setting network.cookie.cookieBehavior to 4 fixes this.

The localStorage access is denied [1] by Anti-Tracking because of sandboxing [2] and therefore an exception is raised [3] when clearStorage is called.

If we propagate the reason: *aRejectedReason = blockedReason; in [2], it will get a partitioned localStorage.
But I'm not sure if we didn't do this out of a security reason.

[1] https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/toolkit/components/antitracking/StorageAccess.cpp#177
[2] https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/toolkit/components/antitracking/ContentBlocking.cpp#985
[3] https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/dom/base/nsGlobalWindowInner.cpp#4527

(In reply to Tom Schuster [:evilpie] from comment #3)

Thanks for the reproducible test case. When the site fails clearStorage throws DOMException: The operation is insecure. I tracked this down to Bug 1628486, so this is a Nightly only problem. Setting network.cookie.cookieBehavior to 4 fixes this.

Thanks, the network.cookie.cookieBehavior fix works.

Set release status flags based on info from the regressing bug 1628486

(In reply to Gary Chen [:xeonchen] from comment #4)

(In reply to Tom Schuster [:evilpie] from comment #3)

Thanks for the reproducible test case. When the site fails clearStorage throws DOMException: The operation is insecure. I tracked this down to Bug 1628486, so this is a Nightly only problem. Setting network.cookie.cookieBehavior to 4 fixes this.

The localStorage access is denied [1] by Anti-Tracking because of sandboxing [2] and therefore an exception is raised [3] when clearStorage is called.

If we propagate the reason: *aRejectedReason = blockedReason; in [2], it will get a partitioned localStorage.
But I'm not sure if we didn't do this out of a security reason.

[1] https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/toolkit/components/antitracking/StorageAccess.cpp#177
[2] https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/toolkit/components/antitracking/ContentBlocking.cpp#985
[3] https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/dom/base/nsGlobalWindowInner.cpp#4527

Thanks for the investigation Gary! I believe this is a bug. The "Storage Access" sandbox attribute is actually "can this iframe request access to its first-party/unpartitioned cookies (i.e. call the Storage Access API)" and not "can this iframe use storage". Check out the requestStorageAccess docs. See also, the definition of the sandbox flag: https://searchfox.org/mozilla-central/rev/9b282b34b5aa0f836beb735656c55efb2cc4c617/dom/base/nsSandboxFlags.h#114-117.

So we want the iframe to continue to have whatever restrictions are applied to it by default; for things on the blocklist storage access should be denied and for things not on the blocklist partitioned storage should be provided. In neither case should the sandboxed iframe be permitted to requestStorageAccess or have access granted by heuristic, unless the allow-storage-access-by-user-activation flag is set.

Thanks for investigating, Steven

https://hg.mozilla.org/mozilla-central/rev/6b8198545396