Remove event handling, as it's moving to the HTML spec. #73
Conversation
Fire the event when unloading or traversing history, instead of relying on hooks in other specs. See w3c/page-visibility#51 and w3c/page-visibility#73
|
Should be merged in conjunction with whatwg/html#7153 |
|
(Will take a proper look tomorrow… reviewing on my phone ☎️) |
|
So... hmm... this is kinda the bulk of the spec... I wonder if we should just move the whole thing over to HTML? I guess we can do that incrementally. @noamr, before merging, it might be good for us to figure out if we are going to break any specs there were calling into these steps. We probably are not, but we should give those specs a heads up. |
Yea that happened with a few of those specs, where they started disappearing and ended up mainly defining the interface.
Not sure how to do that. |
For example: (The file hint at the specs relying on the exported definition) Doing the above is optional... we can just "break" the references and then just email the various WGs to let them know we've moved stuff... we can deal with that before we merge tho. |
The users are https://github.com/w3c/device-posture, https://github.com/w3c/screen-orientation and https://github.com/w3c/web-nfc. Once the HTML spec changes are in I'll create issues for those. |
| <a>Fire an event</a> named "`visibilitychange`" that bubbles, isn't | ||
| cancelable, and has no default action, at the |doc|. | ||
| </li> | ||
| <li>Run <dfn data-export="" data-dfn-type="abstract-op">external now |
There was a problem hiding this comment.
I vaguely remember other specifications relying on this. Worthwhile to dig through past commits to see why we added this.
There was a problem hiding this comment.
The comments on this issue say otherwise, but it's possible...
I think the discussion here went in the direction of using direct calls rather than hooks, I tend to support that - much more straightforward.
There was a problem hiding this comment.
Oh, I see this already came up: #73 (comment)
Not saying we need to keep this, just that we need to give those specs a proper heads up.
Fire the event when unloading or traversing history, instead of relying on hooks in other specs. See w3c/page-visibility#51 and w3c/page-visibility#73
It's defined inside the HTML spec.
Fire the event when unloading or traversing history, instead of relying on hooks in other specs. See w3c/page-visibility#51 and w3c/page-visibility#73.
|
I gave the other specs a heads up (opened issues referencing this PR). |
| visible algorithm</a> before running the step to fire the | ||
| [=Window/pageshow=] event. | ||
| </li> | ||
| <li>Otherwise, <a>queue a task</a> that runs the <a>now visible |
There was a problem hiding this comment.
The events defined in HTML now seem to be run synchronously, which is not what was previously defined. Is this intentional? Do we know what implementations are doing here?
There was a problem hiding this comment.
The HTML spec only defines the event order in the cases of unload/page hide. Those have to be synchronous otherwise they will never be handled
What's not defined is the non standard firing of that event
There was a problem hiding this comment.
The HTML spec now fires the events directly, rather than queueing a task for them (which is what this spec defined before this PR). It'd be good to have tests that verify that the events indeed fire synchronously.
Can you expand on "Those have to be synchronous otherwise they will never be handled"?
/cc @rakina
There was a problem hiding this comment.
‘
visible algorithm before running the step to fire the
[=Window/pageshow=] event.’
that’s the equivalent line in the current spec… synchronous
if the document is being unloaded or suspended into BFcache, which are the cases handled by the HTML spec, when is the handler going to be called? The JS execution context is about to be gone…
There was a problem hiding this comment.
I re-read the algorithm, and you're right. For the cases of history traversal and unload, the events fire synchronously. They are firing async in "other cases" (e.g. tab moved to the background, tab switcher, app switcher, etc), but those other cases are not currently well-defined...
There was a problem hiding this comment.
https://html.spec.whatwg.org/multipage/webappapis.html#rendering-opportunity seems to use "page is in the background" without defining it. At worst, maybe we can use something like "page switches from background to foreground" to call the right visibility events?
- Expose the necessary attributes in the document WebIDL - Define "system visibility state" and document "visibility state" to represent the algorithms for updating the visibility - Update current reference of "page is in the background" to refer to the new definitions. To fully integrate specs referring to the Page Visibility spec with the changes in the HTML spec, i.e. defining the visibilitychange event, the different specs need to be called explicitly when the visibility of the page changes. For that, the visibilityState of the document needs to be properly defined within HTML. See w3c/page-visibility#74 and w3c/page-visibility#73
Defines the document.hidden and document.visibilityState APIs in the HTML Standard, while improving their definitions to be more rigorous. This is similar to 3285b98 which did the same for the visibilitychange event. Also updates the discussion of "page is in the background" to refer to the new definitions. See w3c/page-visibility#74 and w3c/page-visibility#73 for more background.
Defines the document.hidden and document.visibilityState APIs in the HTML Standard, while improving their definitions to be more rigorous. This is similar to 3285b98 which did the same for the visibilitychange event. Also updates the discussion of "page is in the background" to refer to the new definitions. See w3c/page-visibility#74 and w3c/page-visibility#73 for more background.
Defines the document.hidden and document.visibilityState APIs in the HTML Standard, while improving their definitions to be more rigorous. This is similar to 3285b98 which did the same for the visibilitychange event. Also updates the discussion of "page is in the background" to refer to the new definitions. See w3c/page-visibility#74 and w3c/page-visibility#73 for more background.
Fire the event when unloading or traversing history, instead of relying on hooks in other specs. See w3c/page-visibility#51 and w3c/page-visibility#73.
Defines the document.hidden and document.visibilityState APIs in the HTML Standard, while improving their definitions to be more rigorous. This is similar to 3285b98 which did the same for the visibilitychange event. Also updates the discussion of "page is in the background" to refer to the new definitions. See w3c/page-visibility#74 and w3c/page-visibility#73 for more background.
Fire the event when unloading or traversing history, instead of relying on hooks in other specs. See w3c/page-visibility#51 and w3c/page-visibility#73.
Defines the document.hidden and document.visibilityState APIs in the HTML Standard, while improving their definitions to be more rigorous. This is similar to 3285b98 which did the same for the visibilitychange event. Also updates the discussion of "page is in the background" to refer to the new definitions. See w3c/page-visibility#74 and w3c/page-visibility#73 for more background.
Closes #51
Preview | Diff