1859532 - Cache interface is undefined in content scripts

Status: RESOLVED FIXED

(Core :: Storage: Cache API, defect, P3)

Description

[Gregory Pappas [:gregp]]

See bug 1859236 comment 4

Does anyone know if this was on purpose? If it is, we should document it.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

:saschanaz, since you are the author of the regressor, bug 1112134, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Kagami Rosylight [:saschanaz] (they/them) (OOO until 2025-08-18)]

Bug 1112134 definitely was not about hiding it from content scripts, it was to hide it from non-secure contexts. Can content script see any of [SecureContext] interfaces?

Comment 3

[Gregory Pappas [:gregp]]

Can content script see any of [SecureContext] interfaces?

Yes, content scripts can normally see [SecureContext] interfaces. Bug 1859236 comment 4 contains some analysis looking at why this specific one is not visible. Thank you for confirming that it was not intentional !

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

Edit: Ignore this, I was looking at this bug too quickly and misunderstood the situation.

I think our behavior for the Cache API makes sense here. If the content script is accessing storage APIs through the underlying content global, it makes sense to expose the storage as experienced by the underlying content global, which includes restrictions experienced by the underlying content global.

Comment 5

[Gregory Pappas [:gregp]]

Can you elaborate more on the restrictions experienced by the underlying content global?

This bug is just about the fact that Cache/CacheStorage interfaces are not being exposed to content scripts. My limited understanding is that this isn't much of an issue in practice because you can't actually construct them. It's just an interesting difference between content scripts and normal page scripts that I noticed while working on bug 1859236

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

Apologies, my comment 4 is wrong; we should be consistent with what the binding checks normally do per the codegen which is use IsSecureContextOrObjectIsFromSecureContext. Thank you very much for your detailed investigation in bug 1859236 and taking the time to file this follow-up and provide context.

I think this is just an oversight from the changes in that bug as :saschanaz says in comment 2, so I'm moving this bug to Cache API and tentatively assigning to :saschanaz.

Comment 7

[Kagami Rosylight [:saschanaz] (they/them) (OOO until 2025-08-18)]

It seems service worker also uses IsSecureContextOrObjectIsFromSecureContext instead, so maybe it makes sense to let cache api use the same function. (I think I used GetIsSecureContext because it works for WPT at least)

Comment 8

[Kagami Rosylight [:saschanaz] (they/them) (OOO until 2025-08-18)]

And our IDL [SecureContext] also uses IsSecureContextOrObjectIsFromSecureContext: https://searchfox.org/mozilla-central/rev/0ba4632ee85679a1ccaf652df79c971fa7e9b9f7/dom/bindings/Codegen.py#4105

Comment 9

[Kagami Rosylight [:saschanaz] (they/them) (OOO until 2025-08-18)]

Attachment: Bug 1859532 - Use IsSecureContextOrObjectIsFromSecureContext to match `[SecureContext]` behavior r=asuth

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ab349c95356f
Use IsSecureContextOrObjectIsFromSecureContext to match `[SecureContext]` behavior r=asuth

Comment 11

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/ab349c95356f