- From: Jatinder Mann <jmann@microsoft.com>
- Date: Tue, 3 Apr 2012 21:26:54 +0000
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: James Graham <jgraham@opera.com>, Ian Hickson <ian@hixie.ch>, "arvind@google.com" <arvind@google.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
> 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. If completeness is an issue, we have already explicitly called one scenario out of scope. E.g., when the UA is fully obscured by other windows, we report as being visible as it is technically difficult to determine whether you are truly hidden in that situation. Likewise, we may choose to not support the unloading scenario. 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. 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, what decisions can a developer make during the unload that would further that goal? Wouldn't not giving an opportunity to plug in here be a more efficient approach? - Other than completeness, what additional benefit over the unload event would firing the visibilitychange event in this scenario provide? Thanks, Jatinder
Received on Tuesday, 3 April 2012 21:27:28 UTC