Re: [PageVisibility] Hooks in Unload Processing Model

On Tue, 3 Apr 2012, Boris Zbarsky wrote:

> 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?

I tend to agree with Boris here. If people are doing time-consuming things 
when the visibility state changes that seems likely to cause problems in 
other situations. And I believe people can already shoot themselves in the 
foot using other events such as pagehide.

Received on Tuesday, 3 April 2012 22:01:25 UTC