Bug 60397 - Chromium ResourceResponse doesn't copy the download file path to other threads
Summary: Chromium ResourceResponse doesn't copy the download file path to other threads
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-06 12:47 PDT by Brett Wilson (Google)
Modified: 2013-04-11 13:47 PDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.