[Webkit-unassigned] [Bug 168193] REGRESSION(r212192): [GTK] Broke downloads API tests

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=168193

Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cgarcia at igalia.com

--- Comment #1 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #0)
> Implementing MIMETypeRegistry::getPreferredExtensionForMIMEType in r212192
> broke our downloads API test:
> 
> TEST:
> ./Tools/gtk/../../WebKitBuild/Release/bin/TestWebKitAPI/WebKit2Gtk/
> TestDownloads... (pid=31826)
> 
>   /webkit2/Downloads/local-file:                                       OK
> 
>   /webkit2/Downloads/overwrite-destination-allowed:                    OK
> 
>   /webkit2/Downloads/overwrite-destination-disallowed:                 OK
> 
>   /webkit2/Downloads/local-file-error:                                 OK
> 
>   /webkit2/Downloads/remote-file:                                      **
> 
> ERROR:../../Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestDownloads.cpp:186:void
> DownloadTest::checkDestinationAndDeleteFile(WebKitDownload*, const char*):
> assertion failed (destBasename.get() == expectedName):
> ("webkit-downloaded-file.pdf" == "webkit-downloaded-file")
> 
> FAIL
> 
> I guess it's now expected that the .pdf file extension be added even though
> it's not included in the server suggested filename, so the change was
> correct and the test should be updated, right? It seems a bit odd that we
> would add the file extension on the client side, but I guess that's the
> expected behavior?

Yes, it's a matter of checking the extension now too. I was going to do it yesterday but was tired, I'll fix this today. It's the suggested filename, it's perfectly ok to suggest a filename with a extension when we know the mime type.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170213/672ce82a/attachment.html>