It seems GTK WTR is not setting Accept-Language header.
Using minibrowser, the test is passing. This may be an issue with GTK WTR setup?
Created attachment 289814 [details] Patch
(In reply to comment #2) > Created attachment 289814 [details] > Patch The soup session accept-language is well initialized, making minibrowser work as expected. But we are creating a new soup session for testing in WRT. This patch takes the simple approach to set Accept-Language for testing session with a fixed default value.
So, maybe the bug is that we are using SoupNetworkSession::defaultSession() directly in NetworkProcess::userPreferredLanguagesChanged() and we should use NetworkStorageSession::defaultStorageSession().soupNetworkSession()?
AIUI, the default soup session gets updated after the network process is launched and properly set. When we launch tests using WTR, test controller asks to use the testing network session. At that time, we lose all soup session specific options previously set and we are back to the default values.
(In reply to comment #5) > AIUI, the default soup session gets updated after the network process is > launched and properly set. > > When we launch tests using WTR, test controller asks to use the testing > network session. At that time, we lose all soup session specific options > previously set and we are back to the default values. Ok, there's probably more places where we are using the default soup session directly, we need to check that carefully, for now it make sense to use a sane default value for the accept-language property.
Comment on attachment 289814 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=289814&action=review > Source/WebCore/platform/network/soup/SoupNetworkSession.cpp:69 > + auto cookieJar = adoptGRef(createPrivateBrowsingCookieJar()); > + auto newSoupSession = std::unique_ptr<SoupNetworkSession>(new SoupNetworkSession(cookieJar.get())); > + g_object_set(newSoupSession.get(), "accept-language", "en-us", nullptr); > + return newSoupSession; Maybe we could simply add a fixme here.
Please do add a FIXME
Created attachment 289842 [details] Patch for landing
Comment on attachment 289842 [details] Patch for landing Clearing flags on attachment: 289842 Committed r206387: <http://trac.webkit.org/changeset/206387>
All reviewed patches have been landed. Closing bug.
Patch is not working according bots.
Created attachment 289931 [details] Patch
(In reply to comment #13) > Created attachment 289931 [details] > Patch This time, it should work...
(In reply to comment #10) > Comment on attachment 289842 [details] > Patch for landing > > Clearing flags on attachment: 289842 > > Committed r206387: <http://trac.webkit.org/changeset/206387> It made all perf tests fail on EFL and GTK performance bots: - https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Perf%29/builds/6718 - https://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2%20%28Perf%29/builds/10018 (process:23353): GLib-GObject-CRITICAL **: g_object_set: assertion 'G_IS_OBJECT (object)' failed ...
Comment on attachment 289931 [details] Patch Clearing flags on attachment: 289931 Committed r206431: <http://trac.webkit.org/changeset/206431>