[webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[John Abd-El-Malek]

On Thu, Sep 17, 2009 at 12:14 PM, Darin Fisher <darin at chromium.org> wrote:

>
>
> On Thu, Sep 17, 2009 at 2:28 AM, Maciej Stachowiak <mjs at apple.com> 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! ;-)
>
>
>
>>
>>
>>   I think it would also be necessary for the ping to be sent during the
>>> default event handler instead of when the href is normally processed.
>>>
>>
>> I'm not sure what you're suggesting, but link clicks are currently
>> processed in the default event handler for HTMLAnchorElement.
>
>
>
> Sorry, I was thinking of the Mozilla implementation :-/
>
>
>
>>
>>
>>  As for guaranteeing completion of I/O started during unload, I am fairly
>>> concerned about the code complexity that would result from allowing some
>>> resource loads to go uncanceled at page navigation time.  Pings are
>>> different since they are fire and forget, but other resource loads, which
>>> normally get read and processed by the frame / loader system are a bit
>>> problematic to keep active.  We'd want to put them in a special mode where
>>> they don't get canceled but also don't get processed when their responses
>>> arrive.  There may be a clean way to do this, but I am concerned about the
>>> potential maintenance cost due to the extra mode for resource loading.
>>>
>>
>>
>> Yes, it would be somewhat tricky, but the proposed <a ping> solution
>> simply doesn't work. Even if there was a way to make it work, it would be
>> pretty hard to use correctly, and not an intuitive choice.
>>
>
> I agree that it is tricky, but that doesn't sound like much of a barrier to
> the folks who would be using it.  I think people are desperate for anything
> that works, and given that nothing really works today, they end up with
> suboptimal hacks (e.g., busy looping).
>
>
>
>>
>> Here's what would need to happen to let loads from unload run to
>> completion:
>>
>> 1) Implement a way to track all entities that start loads during unload
>> (all owners of ResourceHandles, say).
>> 2) Add a way (perhaps via an abstract base class) for all such entities to
>> release their ResourceHandle to another owner and then cancel themselves.
>> 3) Add code after unload finishes to create an object that takes ownership
>> of all these ResourceHandles, and stays alive until they all complete their
>> loads (dropping results on the floor).
>>
>> I don't think this would be much harder than it would be to implement <a
>> ping>. The only hard part really is #1, particularly making sure we've
>> caught all possible kinds of resource loads.
>>
>
> This does sound workable.  It might even be best to only start out
> supporting Image requests.  That should make it easier to be confident in
> the solution.  I worry about supporting XHR since CORS makes for some
> complicated back-n-forth: not just a single ResourceHandle instance.
>
>
>
>>
>> Yet another possibility: we could introduce a Ping object or sendPing()
>> method that performs a ping without the need to follow a link, and
>> guarantees the I/O won't be cancelled due to navigation. That would localize
>> the need for added complexity. The downside is we'd have to either get it
>> into standards or do something WebKit-specific.
>>
>> A third possibility: limit unload persistence to Image and XMLHttpRequest,
>> to limit the complexity. That's assuming sites are not using scripts,
>> stylesheets or frames to do the exit ping - I don't know if that's a good
>> assumption.
>
>
> I think it is a good assumption.  Image is used today because of an IE
> *quirk* that causes it to not be cancelled upon page navigation.  Other ways
> of fetching subresources do not appear to be subject to that behavior.
>  However, I admit that I haven't personally studied IE enough to be certain.
>
> At any rate, I think I'm persuaded by your arguments.  Adam made a similar
> argument the other day too.  It seems reasonable to make Image behave this
> way when created in certain contexts.  We should probably include
> beforeunload and pagehide handlers since we have evidence that people do the
> same thing in beforeunload that they do in unload.  I include pagehide given
> the recent change to WebKit's page cache insertion policy.  We might even
> want to allow it in anchor tag click handlers for completeness.
>
> We should probably still consider an <a ping> implementation, but I agree
> that it doesn't have to be the only tool that we provide.
>

I think the image trick is more attractive than <a ping> because it's easier
for web developers to use.  But I'm not convinced it's the cleanest method
we can come up with.  If we are expecting web developers to change, then I'd
prefer something more explicit link asyncPing(url).  The benefit is that it
doesn't tie up connection limits like image loading would, and hence
shouldn't impact the navigated page's loading.  The UA is then free to pick
the best time to do the ping, i.e. when network activity has died down.


>
> -Darin
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090917/6a65d3cf/attachment-0001.html>