Conversation
|
I think we should instead invoke https://w3c.github.io/page-visibility/#dfn-steps-to-determine-the-visibility-state directly. IDL attributes is generally what is exposed to JavaScript, whereas specification algorithms should operate on what is exposed to IDL. You can contrast this with C++, where we'd also generally use some underlying concept. |
|
Also, I'd like @foolip to sign off on the general idea. |
|
Can you confirm that the |
|
It returns We stop background window from entering fullscreen via detecting whether the document has focus, I think. Chrome seems to allow background window to enter fullscreen. Do we want to add the focus check to the element ready check instead? |
|
Is the example in #58 (comment) the only thing that this is supposed to prevent? In my testing, the newly opened window is not hidden, which I think matches your testing. Presumably it's easy to also give the new window focus, but is the goal to prevent all new windows from going fullscreen, or just some cases? |
|
I think the goal is to prevent a background window from going fullscreen silently, so probably we want to check whether the document or the top browsing context of document currently has focus. |
|
Can you test if |
|
Ping @upsuper |
|
If it is not allowed to trigger fullscreen asynchronously, the top level document should always get focused before So should we allow a foreground document to put a background document into fullscreen? Given that window cannot raise itself in general, I don't see how allowing that could be useful. |
I agree that doesn't sound useful. What should the spec say to prevent that? One thing that might work is a document-bound user gesture concept, so that it's only possible to request fullscreen for the document that was clicked. Is that what you had in mind? |
Fixes #58.
Preview | Diff