Re: [PageVisibility] Hooks in Unload Processing Model

On 4/3/12 5:26 PM, Jatinder Mann wrote:
>> 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?
>
> There is a fourth option to revert the spec to not fire the event or change the attributes when unloading.

That's option #1 in my list, isn't it?  If not, how is it different?

> If completeness is an issue

The issue was that every single use case we (Mozilla) have run into so 
far for visibility changes wanted to be told that the document is being 
hidden when it got unloaded.  So it's not so much completeness as basic 
usability...  And we've covered that ground on this very mailing list 
before.  Yes, we're using this for several things internally now.

> I agree that throttling may not always take substantial work, but it is additional work nonetheless that we may be requiring the UA to do when they're unloading. Before we add another hook here, I just want to make sure that we all agree that this is the right thing to do.

Sure.  I think at least my opinion is pretty clear; I'd love to hear 
from others.

> Some questions to consider:
> - If the goal of the spec is to help developers programmatically determine the visibility state to make power- and cpu-efficiency decisions

Why is that the goal?  The goal is to determine visibility state.  This 
is not only used for power- and cpu-efficiency decisions; there are 
various other use cases (e.g. turning off audio associated with a 
document, removing event listeners of various sorts, etc, etc).  It's 
_possible_ to do all this by registering the same event handler for both 
visibilitychange and pagehide, but it's certainly more complex for 
developers.

-Boris

Received on Tuesday, 3 April 2012 21:33:13 UTC