- From: Sreeram Ramachandran <sreeram@google.com>
- Date: Thu, 19 Apr 2012 22:26:07 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-web-perf@w3.org
On Thu, Apr 19, 2012 at 16:33, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 4/19/12 1:44 PM, Sreeram Ramachandran wrote:
>>>
>>> Well, one benefit is that UAs won't claim navigated-away-from documents
>>> as
>>> "visible", no? From a developer point of view, that's just weird.
>>
>> Is it actually possible to observe, interact or in any way script a
>> document that has been navigated-away-from?
>
> It's possible to observe it from script and to script it, yes. Script can
> interact with it, too.
>
>> If so, could you show an example of how to do it?
>
> Sure. Here you are:
>
> <!doctype html>
> <script>
> var doc;
> window.onload = function() {
> var frame = document.querySelector("#f");
> doc = frame.contentWindow.document;
> doc.documentElement.textContent = "First"
> frame.onload = doIt;
> frame.src = 'data:text/html,Next';
> }
> function doIt() {
> alert(doc);
> alert(doc.documentURI);
> alert(doc.documentElement.textContent);
> }
> </script>
> <iframe id="f" src="about:blank"></iframe>
>
> Replace about:blank with a same-origin URI of your choice (can't use data:
> there in WEbKit, of course). But in any case, both WebKit and Gecko alert
> "about:blank" for the URI and "First" for the textContent.
Right, but this is for an iframe. Sorry, I should've been clearer that
I was asking about top level documents. Your example above works, as
does the iframe example earlier in the thread
(navigation-page-visibility.html). However, since iframes are given
the same visibility as the "top level browsing context", their
visibilitystate doesn't change when they are navigated or removed from
the DOM, etc. So, it seems to me that iframes don't motivate the case
for firing visibilitychange events during pagehide or unload. In
contrast, a top-level document that is navigated away from does have
its visibilitystate changed, but I haven't been able to find a way to
script it.
The defaultView issue remains, but I suppose that can be handled by
being more flexible in the spec (i.e., perhaps change the "MUST"
language to something more relaxed).
Received on Friday, 20 April 2012 05:27:16 UTC