[whatwg] Navigation events generated during unload

Ian Hickson ian at hixie.ch
Mon Oct 5 18:35:35 PDT 2009


On Mon, 5 Oct 2009, Adam Barth wrote:
> On Mon, Oct 5, 2009 at 6:01 PM, Ian Hickson <ian at hixie.ch> wrote:
> > I tried poking around a bit, and I found that an unload event handler
> > could call a parent frame and get it to set .src on another <iframe> to
> > cause navigation, but it couldn't post a form to that frame itself.
> >
> > It's not clear to me what the difference is. I can kill the navigation
> > algorithm altogether while an 'unload' (or 'beforeunload') is running, but
> > that would kill the case above of setting 'src' (which seems harmless
> > enough that it should be allowed). I don't really know what else to do
> > though. There's a variety of ways to trigger navigation.
> 
> Setting the src of another frame seems fine.
> 
> > Any suggestions? What do browsers actually do, white-box wise?
> 
> We ended up just stopping all navigation events on the frame whose
> unload handler is firing.  That seemed to be what other browsers did.

My testing showed browsers also stopped things like navigation triggered 
by submitting a form to another frame (<form target="">). Is that not 
something we should stop? How about navigating of other windows, e.g. 
settings location.href on a window that was opened with window.open()?


> Sounds like we don't need to change the spec.

The spec, as written, says that a navigation from onunload="" would 
override the current navigation, so _something_ needs to change.

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


More information about the whatwg mailing list