[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