- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 6 Oct 2009 01:35:35 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 5 October 2009 18:35:35 UTC