[whatwg] Avoiding synchronous iframe load

[Ian Hickson]

On Fri, 25 Oct 2013, Boris Zbarsky wrote:
> On 10/25/13 2:42 PM, Ian Hickson wrote:
> > Step 17 (after going async) can jump back to step 8.
> 
> Ah, I see.  That's pretty non-obvious.  Can we restructure this somehow 
> to not have this random goto?  That might help the understandability of 
> the spec here...

Dunno about restructuring it exactly, but I've done the next best thing, 
which is to add ample non-normative text explaining it.


> > > The main hard design constraint I know of here is that navigating 
> > > frames to about:blank via appending them to the DOM should ideally 
> > > not change which document scripts see in the frame (though it does 
> > > in Gecko right now; as I said we consider that a bug).
> > 
> > Not sure exactly what case you mean here. Do you mean:
> > 
> >     <iframe></iframe>
> > 
> > ...or:
> > 
> >     <iframe src="about:blank"></iframe>
> > 
> > ...or:
> > 
> >     <iframe src="about:blank?"></iframe>
> 
> I think those should all behave identically, ideally.  As long as that's 
> not too complicated to specify/implement.

Well, at the end of the day it's "just" a string comparison. Right now I 
treat the missing attribute as meaning "do nothing, just leave the default 
about:blank", and I treat a src="" attribute with _any_ value, even the 
empty string, as "load this URL", where the empty string gets mapped to 
"about:blank". It would be relatively trivial to consider "about:blank" 
and variants thereof, in the initial load, as "no-op" values, just like 
the missing attribute. The question is whether it matters, and if doing so 
makes sense. The advantage of the current model is that it's nice and easy 
to understand: if there's a src="" attribute, then it gets loaded, and 
therefore it replaces the document that was there before it (though the 
Window object is maintained if it's same-origin), but if there's no 
attribute, nothing happens except the fake 'load' event being fired.


> > I don't really understand what Safari are Chrome are doing, given 
> > their behaviour with other values like "bogus:" which also returns 
> > true. Maybe "about:blank" is being treated like a bogus URL?
> 
> I expect the simplest way to do that is to not do a navigation to 
> about:blank at all under some conditions.  The devil is in the details 
> of the conditions. :(

Yeah.


> And thank you for walking through all this stuff, again.  I agree that 
> this stuff is way too complicated (in terms of its web-compat behavior, 
> which has knock-on effects on spec complexity), and I really appreciate 
> you having taken the time to disentangle at least parts of it...

You're welcome. Thanks.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'