Re: [PageVisibility] Hooks in Unload Processing Model

On 4/3/12 7:03 PM, Jatinder Mann wrote:
>> No, some of them are basic user-facing correctness behavior and have nothing to do with CPU usage...  Those are the ones where getting it right on unload matters very much, because the worst case is completely incorrect behavior, not just more CPU hogging.
>
> Help me understand this one better. What scenarios are you thinking? The main unload scenario for visibilitychange I can think of is saving data before the unload and this is the typical unload event use case.

The use cases we've run into are apps that load content of some sort in 
a tab they control and expose some APIs to that content.  Then they want 
to be able to shut off access to those APIs when the tab is not being 
viewed by the user.  So for example, they might expose an audio API that 
lets the content in the tab hand off some audio to the app, or an API to 
allow the content to trigger the device to vibrate; in both cases the 
API access needs to cut off, and any existing sound or vibration 
stopped, whenever the content in the tab stops being viewed by the user, 
whether this happens on tab switch or navigation.

Does that help?

-Boris

Received on Wednesday, 4 April 2012 01:10:17 UTC