[whatwg] Avoiding synchronous iframe load

Boris Zbarsky bzbarsky at MIT.EDU
Thu Oct 17 19:28:21 PDT 2013

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");'
x.textContent += "2";

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.  ;)


More information about the whatwg mailing list