- From: James Robinson <jamesr@google.com>
- Date: Wed, 10 Apr 2013 20:19:13 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <CAD73mdJf59eqxhfCBsnrNN4m1si0vtVUMNhqyzGMW_bkmB=HBA@mail.gmail.com>
On Wed, Apr 10, 2013 at 5:45 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 4/10/13 6:32 PM, James Robinson wrote: > >> 1.) Gmail loads up a large portion of its script in an iframe styled to >> be 0x0. While this iframe is not display:none, it's hidden for any >> practical definition of hidden. >> > > That's not quite true. > > For example, it has a well-defined CSS viewport and hence can do media > queries and selector matching and other CSS things, unlike a display:none > iframe... > > > If animations on hidden iframes did not tick, script that ran inside this >> iframe would not be able to animate parts of the rest of gmail UI. I >> think this behavior would be broken. >> > > You could make the same argument about scripts in one tab that try to > script another one that they opened, no? Yes. And in fact we've hit some issues with this since we throttle setTimeout/setInterval in backgrount tabs. Robohornet (in an earlier version) window.open()'d a popup and then scripted the popup from the main page. Thus, if the main page was in a tab put into the background, the timers on the page were throttled down even if the user was staring right at the window that appeared to be running the benchmark. I think this case is relatively rare, though, compared to inter-iframe scripting. > > The common problem here is that the visibility of the document >> associated with the global context that requestAnimationFrame is picked >> up from is a poor proxy for the visibility of the thing the author is >> actually trying to animate. >> > > But that's not iframe-specific. I agree. I think anything here is a bit of a compromise but I feel more comfortable doing things on a top-level browsing context. If we could understand the relationships between the callbacks and the content the author is trying to animate we'd be better off but the current APIs don't give us that. - James > > context and document a bit more explicit, but it's possible that >> wouldn't have helped. >> > > I doubt it would have changed how authors think about it. > > In any case, I doubt that at this point we're going to agree on this > issue... > > -Boris >
Received on Thursday, 11 April 2013 03:19:40 UTC