beidson at apple.com
Thu Dec 6 10:38:53 PST 2007
Committing a failed icon load to the icon database was intended
behavior - if an icon doesn't exist at the calculated url, we want to
store that result so we don't hammer the server for it over and over.
Committing a *cancelled* load to the icon database was an oversight
and is a bug. The fix is straight forward - SubresourceLoaders know
the difference between cancellation and failure, but their clients
don't. Give SubresourceLoaderClient the ability to distinguish between
failures and cancellations and its a peace of cake.
If you wanted to file a bug at bugs.webkit.org, that'd be awesome :)
On Dec 6, 2007, at 8:46 AM, Patrick Hanna wrote:
> Quick question about the IconLoader code. I just noticed that if I
> cancel a load where an Icon was in the process of being loaded (i.e.
> didReceiveResponse was called with a good response), didFail is
> called. This method then calls finishLoading with a valid url since
> the ResourceHandle is non-null. Is this the intended behavior? This
> will commit the url to the icon database even though the icon load
> was canceled.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev