Bug 168193 – REGRESSION(r212192): [GTK] Broke downloads API tests

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Michael Catanzaro]

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?

[Carlos Garcia Campos]

(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.

[Carlos Garcia Campos]

Committed r212290: <http://trac.webkit.org/changeset/212290>