- From: Jatinder Mann <jmann@microsoft.com>
- Date: Tue, 17 Apr 2012 00:23:55 +0000
- To: Anne van Kesteren <annevk@opera.com>, James Graham <jgraham@opera.com>, Boris Zbarsky <bzbarsky@mit.edu>
- CC: "public-web-perf@w3.org" <public-web-perf@w3.org>
On 4/16/12 11:14 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > I agree that this is not as clear as it should be. It should probably > just says that the event is fired at a Document when the UA determines > that the .visibilityState of that Document has changed. You are correct that the spec isn't very clear here. I will update the spec to tie firing the visibilitychange event with a change in the visibilityState attribute. On 4/16/12 12:52 PM, Anne van Kesteren <annevk@opera.com> wrote: >On 4/16/12 12:16 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: >> On 4/16/12 3:14 PM, James Graham wrote: >> No, you're not wrong (modulo the discussion about what should happen >> during page unloading). >> >>> Assuming I am not wrong about that, I think the right fix to the >>> problem above is to specify that when the visibility of a top level >>> browsing context changes, an event is fired on that browsing >>> context's document object and on the document object of each descendant browsing context. >> >> That might be fine, yes. > > If that happens a) those events need to be queued (using HTML's event > loop) and b) order needs to be defined as it would be observable. I agree here as well. I will update the spec and define the ordering to be preorder traversal. Thanks, Jatinder
Received on Tuesday, 17 April 2012 00:24:32 UTC