These are the tests that timeout.
I'm skipping them for the moment as it seems it's a bug in libsoup. The culprit seems to be this commit 38aab0e2b.
fast/loader/file-URL-with-port-number.html passes for me
Created attachment 134692 [details]
libsoup patch to fix fast/encoding/percent-escaping
Can you try this patch against libsoup? It definitely fixes the percent-escaping test, but I seem to get lots of other differences in the test output (mostly in -stderr.txt files) as well, but I can't be sure if that's because of an actual behavior change, or just random trying-to-run-tests-on-a-non-blessed-machine flakiness.
(In reply to comment #2)
> Created an attachment (id=134692) [details]
> libsoup patch to fix fast/encoding/percent-escaping
> Can you try this patch against libsoup? It definitely fixes the percent-escaping test, but I seem to get lots of other differences in the test output (mostly in -stderr.txt files) as well, but I can't be sure if that's because of an actual behavior change, or just random trying-to-run-tests-on-a-non-blessed-machine flakiness.
It fixes that one indeed but the other two are still failing.
Wouldn't it be simpler just to back to soup_uri_decode()/g_file_new_for_path() and put the windows code inside some guards? Yeah I know it isn't very beautiful and that libsoup code does not have things like that, but if the glib implementations behave in a different way ... I mention that because I asked the author of the commit and he kind of remembers some issues with slashes when using g_file_new_for_path(), that's why he switched to g_file_new_for_uri().
(In reply to comment #3)
> It fixes that one indeed but the other two are still failing.
Ah, I thought fast/loader/file-URL-with-port-number.html was passing, because it shows "SUCCESS" if you run it in GtkLauncher, but that's just because the test isn't distinguishing the requested resource from an error page...
However, fast/loader/location-port.html is completely unrelated; it fails with any version of libsoup. Perhaps it's because of something that changed in ResourceHandleSoup.cpp rather than something that changed in libsoup?
fast/encoding/percent-escaping.html and fast/loader/file-URL-with-port-number.html are now fixed with the latest libsoup, and the fix will also be in 2.38.1. I don't know if it's worth bumping the requirements over. (If we want to un-skip the tests we could just update the packages on the bots without changing the required minimum version.)
(In reply to comment #5)
> fast/encoding/percent-escaping.html and fast/loader/file-URL-with-port-number.html are now fixed with the latest libsoup, and the fix will also be in 2.38.1. I don't know if it's worth bumping the requirements over. (If we want to un-skip the tests we could just update the packages on the bots without changing the required minimum version.)
We can just update the version in the WebKit jhbuild and unskip.
Same failures in EFL of course, I'll take a look.
Created attachment 137890 [details]
Bumping libsoup to 2.38.1
I tested the previously failing tests that were moved to the skip list as well as http/*
On my machine, for GTK I got a couple of unexpected passes afterwards. Maybe Philippe can unskip them in a separate commit if that's verified on the buildbot? I figure these are related to bug 52798.
Test / Expected Failure
Comment on attachment 137890 [details]
Bumping libsoup to 2.38.1
Clearing flags on attachment: 137890
Committed r114653: <http://trac.webkit.org/changeset/114653>
All reviewed patches have been landed. Closing bug.
Please remember to raise the libsoup versions in configure.ac and Source/cmake/OptionsEfl.cmake.
(In reply to comment #11)
> Please remember to raise the libsoup versions in configure.ac and Source/cmake/OptionsEfl.cmake.
This isn't actually a requirement in this case. The libsoup version in configure.ac is the necessary API level, whereas the version in jhbuild is what's necessary to pass the tests.