[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");'
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
More information about the whatwg
mailing list