Re: [PageVisibility] Hooks in Unload Processing Model

On 4/3/12 2:47 PM, Jatinder Mann wrote:
>> Is there an updated draft somewhere that uses this hook? The latest editor's draft seems to try to override parts of the algorithm instead.
>
> Sorry, I haven't edited that section of the spec yet; the current text was prior to the hook being added to the HTML5 unload processing model.
>
> However, I do have a question on that section. I have been receiving feedback from within Microsoft and partners regarding firing the visibilitychange event when the Document is unloading. Based on the current usage of this interface, we have seen that most developers rely solely on the hidden attribute and not the visibilityState attribute. Considering most activity throttling work is designed for when the page is hidden but active, if we fire the visibilitychange event during the unload, we may be running code developers did not intend to run during the unload. This may unexpectedly increase the overall time it takes to navigate.
>
> Considering adoption of the unload event for end of page activities is prolific on the web, and seeing that the pagehide event also fires in this case, I want to understand if we really need to provide another hook here.

I believe we have three basic options:

1)  Do not change visibility state to "hidden" when unloading.
2)  Change the visibility state but do not fire an event for the change.
3)  Change the visibility state and fire an event.

Do you see any other options?

I believe that #1 is a bad idea because it causes this API to return 
bogus information in various cases.  In my opinion.

I also believe that #2 is not a great idea, because it breaks basic code 
that keys off visibility change events.

Hence my support for #3.  I agree that it has the issue that you point 
out, but it seems like the amount of work needed for throttling is 
pretty small: set a boolean and maybe reschedule some timers.  Are 
people doing more substantial throttling work?  If not, then the 
drawbacks of approaches #1 and #2 seem like bigger problems.  If people 
_are_ doing throttling work that takes a while (as in, user-noticeable 
on page loads), then I think we should think about redesigning this 
whole thing, since otherwise the current API setup will make switching 
between tabs using the keyboard also have user-noticeable lags, no?

-Boris

Received on Tuesday, 3 April 2012 18:55:38 UTC