Queue a task on the permissions task source #101
Conversation
…d from a different document
|
Also added a few changes to the processing model here based on feedback from @dtapuska on the relevant Chromium CL |
index.bs
Outdated
|
|
||
| 2. Run the following steps [=in parallel=]: | ||
| 2. If [=this=]'s [=relevant global object=] is not identical to {{NavigatorUAData}}'s [=relevant global object=], then: |
There was a problem hiding this comment.
@dtapuska - Is this a good equivalent to !GetExecutionContext()?
There was a problem hiding this comment.
I don't think this is quite right. Isn't this the same as NavigatorUAData? I think what you mean is that the RelevantRealm != IncumbentRealm then throw WrongDocument ?
There was a problem hiding this comment.
Incumbent realm should not be used by new specs.
If you are trying to make sure that the document is alive, then you need to check if the relevant global object is a Window and its associated Document is fully active.
What are you actually trying to express here, in terms of developer-facing benefit, not in terms of Chromium implementation details?
There was a problem hiding this comment.
If you are trying to make sure that the document is alive, then you need to check if the relevant global object is a Window and its associated Document is fully active.
Makes sense, thanks!
What are you actually trying to express here, in terms of developer-facing benefit, not in terms of Chromium implementation details?
I'm trying to express that detached frames should reject here.
The developer-facing benefit is reduced confusion as the rest of UA data returns nullyfied values in that case.
There was a problem hiding this comment.
the rest of UA data returns nullyfied values in that case.
That doesn't appear to be true, at least for anything in https://html.spec.whatwg.org/multipage/system-state.html#client-identification .
There was a problem hiding this comment.
Ugh, that's bizarre. I hope we can align Chromium with the spec? There's just no reason to make these getters dependent on state like that.
There was a problem hiding this comment.
Maybe the easiest path forward would be to downsize this PR to the task queueing only, drop the Promise rejection, find a different ExecutionContext to queue the task on in the Chromium implementation (from the ScriptState) and open an issue on the HTML spec to figure out the nullification of attributes on detached documents.
There was a problem hiding this comment.
That makes sense to me.
Note that the spec as written rejects the promise but the rejection will never be seen, since the event loop is inactive for those documents.
There was a problem hiding this comment.
Removed the promise rejection, but left the realm on which the promise is created.
Note that the spec as written rejects the promise but the rejection will never be seen, since the event loop is inactive for those documents.
Is this because of the realm the promise is created with?
There was a problem hiding this comment.
No, it's because the event loop just doesn't run for inactive documents.
Co-Authored-By: Domenic Denicola <d@domenic.me>
Closes #77
Preview | Diff