On Thu, Sep 17, 2009 at 4:05 PM, Maciej Stachowiak <[email protected]> wrote:
> > On Sep 17, 2009, at 2:09 PM, Darin Fisher wrote: > > > > On Thu, Sep 17, 2009 at 12:52 PM, Maciej Stachowiak <[email protected]> wrote: > >> >> On Sep 17, 2009, at 12:14 PM, Darin Fisher wrote: >> >> >> >> On Thu, Sep 17, 2009 at 2:28 AM, Maciej Stachowiak <[email protected]> wrote: >> >>> >>> On Sep 17, 2009, at 12:35 AM, Darin Fisher wrote: >>> >>> >>>> >>>> For <a ping> to be used as I suggested, you would need to set the href >>>> to a javascript URL such as javascript:void(), so that it would not >>>> interfere with an existing navigation. >>>> >>> >>> Navigating to a javascript: URL will still cancel with an existing >>> pending navigation, both per spec and in at least some browser engines >>> (including WebKit). For spec reference see step 5 here: < >>> http://dev.w3.org/html5/spec/Overview.html#navigate>. Note lack of >>> exception for "javascript:" URLs. >> >> >> nit: WebKit and most browsers that I tested _only_ do so if the >> javascript: URL evaluates to a string. Take a look at >> FrameLoader::executeIfJavaScriptURL(). I can also share my test case with >> you if you are still doubting! ;-) >> >> >> My test case did this from an onclick handler, and the navigation to >> yahoo.com did not happen: >> >> location.href="http://yahoo.com/";; >> location.href="javascript:void()"; >> >> > Yes, in that case the scheduled location change from the first href > assignment is cancelled by the second. > > My test case was to dispatch a click event to an anchor tag during the > unload handler. Set the anchor's href to javascript:void() and notice that > it does not interrupt the existing navigation. > > > Navigation from unload handlers is buggy. > I agree. _but_ my point about javascript:void() not disturbing an existing navigation is not specific to unload. If I have a page that does AJAXy things with a background iframe, I can still let the user click on anchors, provided they have href="javascript:void(...do stuff...)". Maybe no one does that... > > > It may be that other ways of navigating to a javascript: URL don't stop a >> pending load, but that would be a bug. >> > > I'm not sure. It seems like each browser goes out of its way to only > cancel the existing navigation when the javascript: URL results in a string. > Coincidence, really?? > > > It seems like a bug that it's inconsistent between different ways of > navigating. > > Perhaps. We're talking about the web platform, right? > > >> >> Based on your comments below, I think the expedient thing to do is to let >> Image loads (only) complete their I/O when initiated from unload or >> pagehide. >> > > Why exclude beforeunload? Some of the sites we found use the busy loop > hack in beforeunload. > > > I wasn't deliberately excluding it. Including beforeunload seems fine. > > Cool! -Darin
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
