WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
169915
[GTK] Several WPT tests are failing since they were added in the last update in
r213882
https://bugs.webkit.org/show_bug.cgi?id=169915
Summary
[GTK] Several WPT tests are failing since they were added in the last update ...
Carlos Garcia Campos
Reported
2017-03-21 06:26:29 PDT
imported/w3c/web-platform-tests/XMLHttpRequest/getallresponseheaders-cl.htm imported/w3c/web-platform-tests/XMLHttpRequest/getallresponseheaders.htm imported/w3c/web-platform-tests/XMLHttpRequest/setrequestheader-content-type.htm All of them fail because libsoup fails to load the requests because the response doesn't include the empty line after the headers. Other browsers allow that, so I've written a patch for libsoup in
https://bugzilla.gnome.org/show_bug.cgi?id=780352
. While the patch is reviewed and we have a new libsoup version to depend on, we can probably add the patch to our jhbuild to make sure those test pass and don't regress.
Attachments
Patch
(6.31 KB, patch)
2017-03-21 07:51 PDT
,
Carlos Garcia Campos
mcatanzaro
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Carlos Garcia Campos
Comment 1
2017-03-21 06:41:09 PDT
Actually, with libsoup patched imported/w3c/web-platform-tests/XMLHttpRequest/getallresponseheaders-cl.htm passes, imported/w3c/web-platform-tests/XMLHttpRequest/getallresponseheaders.htm still fails, but it no longer timeouts and resultds are pretty much the same, and imported/w3c/web-platform-tests/XMLHttpRequest/setrequestheader-content-type.htm still fails with the same errors.
Carlos Garcia Campos
Comment 2
2017-03-21 07:10:10 PDT
imported/w3c/web-platform-tests/XMLHttpRequest/setrequestheader-content-type.htm no longer works with the current version of wptserve, so I'm going to remove our expectations, since the test is skipped globally.
Carlos Garcia Campos
Comment 3
2017-03-21 07:41:25 PDT
Our result for imported/w3c/web-platform-tests/XMLHttpRequest/getallresponseheaders.htm is valid with libsoup patched, it's just different to what CF does, but still valid.
Carlos Garcia Campos
Comment 4
2017-03-21 07:51:48 PDT
Created
attachment 305002
[details]
Patch
Michael Catanzaro
Comment 5
2017-03-21 18:09:43 PDT
Comment on
attachment 305002
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=305002&action=review
> LayoutTests/platform/gtk/imported/w3c/web-platform-tests/XMLHttpRequest/getallresponseheaders-expected.txt:3 > +FAIL XMLHttpRequest: getAllResponseHeaders() 1 assert_equals: expected "also-here: Mr. PB\r\newok: lego\r\nfoo-test: 1, 2\r\n" but got "ALSO-here: Mr. PB\r\nfoo-test: 1, 2\r\newok: lego\r\n"
IMO the test should be updated to print PASS for either result, so we don't have the text FAIL in our expected results unnecessarily.
Carlos Garcia Campos
Comment 6
2017-03-22 00:41:14 PDT
(In reply to Michael Catanzaro from
comment #5
)
> Comment on
attachment 305002
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=305002&action=review
> > > LayoutTests/platform/gtk/imported/w3c/web-platform-tests/XMLHttpRequest/getallresponseheaders-expected.txt:3 > > +FAIL XMLHttpRequest: getAllResponseHeaders() 1 assert_equals: expected "also-here: Mr. PB\r\newok: lego\r\nfoo-test: 1, 2\r\n" but got "ALSO-here: Mr. PB\r\nfoo-test: 1, 2\r\newok: lego\r\n" > > IMO the test should be updated to print PASS for either result, so we don't > have the text FAIL in our expected results unnecessarily.
Tests are not passing, but now the expected failure is the same than in all other browsers.
Carlos Garcia Campos
Comment 7
2017-03-22 01:44:34 PDT
It seems webkit-patch doesn't know how to comment and close bugs with the new version of bugzilla. Committed
r214243
: <
http://trac.webkit.org/changeset/214243
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug