| Summary: | REGRESSION (r173356): Downloading a disk image appends ".txt" to it | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Antti Koivisto <koivisto> | ||||
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED DUPLICATE | ||||||
| Severity: | Normal | CC: | ap | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Antti Koivisto
2014-10-07 12:13:11 PDT
Created attachment 239424 [details]
patch
Comment on attachment 239424 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=239424&action=review > Source/WebKit2/Shared/Downloads/ios/DownloadIOS.mm:134 > + // FIXME: For some reason the filename needs to be accessed or it may be incorrect after > + // CFURLResponse is serialized/deserialized (gains .txt extension) > + response.suggestedFilename(); The fix looks OK to me, although mysterious. Antti is going to look into whether this can be tested with <iframe src="resources/image.dmg"> - we do log suggested file names in WKTR. Looks like this can't be tested with reasonable effort. The existing test code for file names runs in policy delegates for the original response. The bug occurs afterwards, when converting the load to download and doing IPC to UI process. The bug is somehow related to the CFNetwork heuristics for figuring out a file name from URL when Content-Disposition header is not present. Reverted in http://trac.webkit.org/changeset/175064. Turns out the root cause is in the MIME type sniffing. *** This bug has been marked as a duplicate of bug 137855 *** |