Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

isSecureContext definition seems wrong in multi-global situations #36

Closed
domenic opened this issue Jul 10, 2016 · 1 comment
Closed

Comments

@domenic
Copy link
Contributor

domenic commented Jul 10, 2016

Both Window's isSecureContext and WorkerGlobalScope's isSecureContext attributes' getters return true if the relevant settings object for the getter’s global object is a secure context, and false otherwise.

This is saying that it looks at the getter's global object. In other words, it is equivalent to

Both Window's isSecureContext and WorkerGlobalScope's isSecureContext attributes' getters return true if the current settings object is a secure context, and false otherwise.

I think you want to instead look at the object to which the getter is applied. That would be:

Both Window's isSecureContext and WorkerGlobalScope's isSecureContext attributes' getters return true if this global object's relevant settings object is a secure context, and false otherwise.

or just using the fact that you've already defined "secure context" to apply to to global objects, you could do

Both Window's isSecureContext and WorkerGlobalScope's isSecureContext attributes' getters return true if this global object is a secure context, and false otherwise.

The difference is observable when doing this:

const getter = Object.getOwnPropertyDescriptor(window1, "isSecureContext").get;
console.log(getter.call(window2));

With the current spec this tells you if window1 is a secure context. I think it should tell you if window2 is a secure context.

mikewest added a commit that referenced this issue Jul 15, 2016
This patch moves 'isSecureContext' to the 'WindowOrWorkerGlobalObject' mixin,
and addresses @domenic's feedback in #36 regarding
the language used to choose a global object upon which to operate.
@mikewest
Copy link
Member

Closed with 040600a. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants