FYI @chrisdavidmills and @tomayac

(comment last updated: 2025-07-11 05:14:26)

@michaelwasserman Thankyou for this. A bit more had to be done, which was adding the secure context headers. I've added to overview page, properties, methods.

1. It wasn't clear to me if the destroy() methods need secure context. If they don't, you could drop the last commit in which they were added (separately)
2. Is there anything missing? (Can you sanity check?)
3. Some of the methods already had secure context. That makes me worry that perhaps the specification changed since this was implemented, and perhaps there are versions in which secure context only applies to some things and not others. Can you confirm that this is not the case? [if it is, we need to add information to the browser compatibility data as well]

Thanks for the additional fixes! Everything lgtm, responses:

1. It wasn't clear to me if the destroy() methods need secure context. If they don't, you could drop the last commit in which they were added (separately)

AFAIK, the entire interface and everything therein is SecureContext in spec and impl.

2. Is there anything missing? (Can you sanity check?)

I did a pass over the live pages and changes. This looks complete, thank you!

3. Some of the methods already had secure context. That makes me worry that perhaps the specification changed since this was implemented, and perhaps there are versions in which secure context only applies to some things and not others. Can you confirm that this is not the case? [if it is, we need to add information to the browser compatibility data as well]

This seems to be a documentation discrepancy, the interfaces themselves have been SecureContext from initial spec work, and before Chrome origin trials and launches.