You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reporting the gist of the discussion in w3c/webref#1142 (comment): to avoid redundancy, interfaces may not be flagged as [SecureContext] in specs when they are only exposed to globals that are themselves only available in secure contexts, such as the ServiceWorker global. As a result, the logic that determines whether an IDL construct is secure context only also needs to take globals into account.
Updating the logic may not be worth the hassle in practice. This would likely only add the ExtendableCookieChangeEvent to the list of interfaces that are only usable in secure contexts.
(For Service Workers, the underlying interface ServiceWorkerGlobalScope did not have a [SecureContext] flag. Now fixed in the spec!)
The text was updated successfully, but these errors were encountered:
Reporting the gist of the discussion in w3c/webref#1142 (comment): to avoid redundancy, interfaces may not be flagged as
[SecureContext]
in specs when they are only exposed to globals that are themselves only available in secure contexts, such as theServiceWorker
global. As a result, the logic that determines whether an IDL construct is secure context only also needs to take globals into account.Updating the logic may not be worth the hassle in practice. This would likely only add the
ExtendableCookieChangeEvent
to the list of interfaces that are only usable in secure contexts.(For Service Workers, the underlying interface
ServiceWorkerGlobalScope
did not have a[SecureContext]
flag. Now fixed in the spec!)The text was updated successfully, but these errors were encountered: