[whatwg] Should events be paused on detached iframes?

Tue Jan 17 16:24:43 PST 2012

On 1/17/12 6:31 PM, Ian Hickson wrote:
>>> It should put it up in the context of the top-level browsing context
>>> of the script that led to that point (the "first script"). This is the
>>> same as if someone in one tab calls another tab's script and that
>>> script calls alert().
>>
>> Is that last what browsers actually do?  I'm pretty sure that's not what
>> Gecko does...
>
> If there's specific features in the spec that are incorrectly specified,
> I'm happy to address them. Send mail with a test case showing the problem.

Sure.  Here's a testcase.  You need two files.  test2.html contains:

   <script>function f() { alert('Called'); }</script>

test1.html contains:

   <!DOCTYPE html>
   <script>
     var w;
     function openWindow() {
       w = window.open("test2.html");
     }
     function alertMe() {
       w.f();
     }
   </script>
   <input type="button"
          value="Click me to open a new tab then switch back to this
                 tab and click the other button"
          onclick="openWindow()">
   <input type="button" value="Put up an alert"
          onclick="alertMe()">

Make sure to not test with a file:// URI to avoid same-origin policy 
issues.  Load test1.html, and follow the directions on the first button.

Results in various browsers:

Firefox: Clicking the "Put up an alert" button switches to the tab that 
test2.html is loaded in and shows the alert.

Opera:  Clicking the "Put up an alert" button does nothing visible.  If 
the user ever switches to the test2.html tab, he sees the alert.

Chrome:  Same as Firefox.

Safari:  Needs a preference changed to open a tab instead of a window. 
After that, same as Firefox.

IE9: Same as Opera, but flashes the test2.html tab to indicate that it's 
got an alert associated with it.

None of them associate the alert with test1.html.

> Well, I'm not sure I'm up for sanity checking the entire spec, especially
> for edge case areas like this where interop isn't really present anyway so
> it's not clear what a "wrong" answer would be.

Yeah, I know.  And neither am I.

The end result is likely to be that UAs implement whatever is simplest 
in their impl.  Or most secure.  Or both.  Or neither I guess, depending 
on priorities...

> The best way forward here might be just to add tests to the test suite and
> see who complains...

That seems somewhat reasonable to me.

-Boris