168193 2017-02-12 11:08:02 -0800 REGRESSION(r212192): [GTK] Broke downloads API tests 2017-02-14 05:05:08 -0800 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build PC Linux RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=168163 P2 Normal --- 1 mcatanzaro webkit-unassigned bugs-noreply cgarcia oldest_to_newest 1276004 0 mcatanzaro 2017-02-12 11:08:02 -0800 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? 1276093 1 cgarcia 2017-02-12 22:09:56 -0800 (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. 1276687 2 cgarcia 2017-02-14 05:05:08 -0800 Committed r212290: <http://trac.webkit.org/changeset/212290>