-
Notifications
You must be signed in to change notification settings - Fork 25
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
Does window.getScreenDetails() always resolve with the same object? #80
Comments
Is returning the same promise just a question of ergonomics? We assumed that folks would call I am not sure we can should do anything when the permission is revoked on the current page as the ScreenDetails object could be referenced by a JavaScript variable. Are you suggesting that we should be throwing exceptions on ScreenDetails property accesses if the permission is revoked? |
There isn't that much of a difference between returning a new As for how to handle permissions being revoked, over time I've seen a shift in how this is handled (at least in Chromium). Originally many implementations made the assumption that permission updates wouldn't be reflected until the page was reloaded, acknowledging the issue that you raise about the |
I attempted to define this a bit better in #87, but I'm unsure how reusing a promise interacts with getScreenDetails() attempting to resolve or reject its promise(s) based on a dynamic permission state. FWIW, it's creating a new promise each time and using an internal slot to store and reuse the ScreenDetails interface object for now. I also have an issue to "Define behavior of cached objects and method steps when the permission is revoked. (See #80)". I hope this might be sufficient for now, and that we can refine this further at a later date. |
I think this is sufficient. Feel free to close this issue when your PR is merged. |
As written this seems to be implied by the idea that the
Promise
is resolved "with this's associated ScreenDetails object" but I don't see any specification text which defines how this object is initialized. I recommend extending theWindow
interface with an internal slot which holds thePromise
returned by this function. Future invocations ofgetScreenDetails()
can return this samePromise
which may have already resolved.This raises a related question about what happens when the
"window-placement"
permission is revoked. This should probably clear this internal slot (so that the permission check has to be rerun) as well as preventing new events for advanced observable properties from firing.The text was updated successfully, but these errors were encountered: