Bug 60397

Summary: Chromium ResourceResponse doesn't copy the download file path to other threads
Product: WebKit Reporter: Brett Wilson (Google) <brettw>
Component: PlatformAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: michaeln, schenney
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   

Description Brett Wilson (Google) 2011-05-06 12:47:12 PDT 
ResourceResponse in network/chromium can serialize itself to a CrossThreadResourceResponseData for sending to other threads. This does not support the downloadedFile and the file will be empty when the object is reconstituted.

It's not immediately clear how this should work. In my patch to bug 60281 I changed the file from a string to a File object so that the Blob system will keep the file in scope. This is likely not threadsafe so we can't use File objects from the background thread. We could use a string, but this may not handle all cases because it won't keep the file in scope, regressing bug 60281. For example, if the response is converted to a CrossThreadResponseData, the original is deleted, and then a response is reconstituted, the File reference will be deleted and the file on disk may be deleted in the middle.

The downloaded file isn't used except via the Chromium WebKit API right now, and this doesn't require threading, so this doesn't break stuff for now.