W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Avoiding synchronous iframe load

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 17 Oct 2013 22:28:21 -0400
Message-ID: <52609CC5.9000403@mit.edu>
To: whatwg@lists.whatwg.org
On 10/17/13 6:14 PM, Elliott Sprehn wrote:

 > frame = document.createElement('iframe');
 > document.body.appendChild(frame);
 > frame.contentDocument; // synchronously available

Yes, but at least in Gecko the frame.contentDocument you observe there 
is not the same as what you'd observer after at trip through the event 
loop.  Again, we consider this to be a bug.

> Also javascript: URLs are not async in Firefox:

They most certainly are.  I know because I made them so.  ;)

> frame = document.createElement('iframe');
> frame.src = 'javascript:alert(1);'
> document.body.appendChild(frame);
> alert(2);
>
> This alerts 1 and then 2.

No, it alerts 2 and then 1.

What the _user_ sees is the "1" and then the "2" because the newer alert 
goes on top of the older one in the UI, then reveals the older one when 
it's dismissed.

I suggest not relying on alerts, which can trigger script reentry as 
they spin the event loop in Gecko, for determining order.  Here's a 
testcase without that confounding factor:

<body><div id="x"></div><script>
frame = document.createElement('iframe');
frame.src = 'javascript:void(parent.x.textContent += "1");'
document.body.appendChild(frame);
x.textContent += "2";
</script>

which clearly shows "21" in Firefox.

> Presumably all this behavior is required by spec.

Whatever the spec requires can't match all UAs here, because UAs totally 
disagree on details of this behavior.

This also means the spec might not be requiring anything particularly 
sane....  I suggest carefully reading it to find what it _does_ require 
right now, then fixing it as needed.  ;)

-Boris
Received on Friday, 18 October 2013 02:28:50 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:12 UTC