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 :)
~Brady
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.
Thanks,
Patrick
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
