This test expects the server to be web-platform.test, or at least something with a '.', but we are using localhost. When parsing the cookie, soup is failing because the domain doesn't have any '.'. I guess it would be the same in other platforms. Adding web-platform.test to /etc/hosts (as suggested by WPT) and changing the wpt server config to use web-platform.test as host fixes the problem. But that will fail in the bots unless we modify the /etc/hosts in all bots, so I don't think we will be able to fix this for the bots. ___________________________________________________________________________________ test_duplicated_cookie ___________________________________________________________________________________ session = <webdriver.client.Session object at 0x7fbf6c166750>, url = <function url at 0x7fbf6c190398> server_config = {'domains': {'': 'localhost'}, 'host': 'localhost', 'ports': {'http': ['8802']}} def test_duplicated_cookie(session, url, server_config): session.url = url("/common/blank.html") clear_all_cookies(session) create_cookie_request = { "cookie": { "name": "hello", "value": "world", "domain": server_config["domains"][""], "path": "/", "httpOnly": False, "secure": False } } result = session.transport.send("POST", "session/%s/cookie" % session.session_id, create_cookie_request) assert result.status == 200 assert "value" in result.body assert result.body["value"] is None session.url = inline("<script>document.cookie = 'hello=newworld; domain=%s; path=/';</script>" % server_config["domains"][""]) result = session.transport.send("GET", "session/%s/cookie" % session.session_id) assert result.status == 200 assert "value" in result.body assert isinstance(result.body["value"], list) assert len(result.body["value"]) == 1 assert isinstance(result.body["value"][0], dict) cookie = result.body["value"][0] assert "name" in cookie assert isinstance(cookie["name"], basestring) assert "value" in cookie assert isinstance(cookie["value"], basestring) assert cookie["name"] == "hello" > assert cookie["value"] == "newworld" E AssertionError: assert 'world' == 'newworld' E - world E + newworld E ? +++ cookie = {'domain': 'localhost', 'httpOnly': False, 'name': 'hello', 'path': '/', ...} create_cookie_request = {'cookie': {'domain': 'localhost', 'httpOnly': False, 'name': 'hello', 'path': '/', ...}} result = <Responsetatus=200 body={"value": [{"domain": "localhost", "name": "hello", "value": "world", "path": "/", "httpOnly": false, "secure": false}]}> server_config = {'domains': {'': 'localhost'}, 'host': 'localhost', 'ports': {'http': ['8802']}} session = <webdriver.client.Session object at 0x7fbf6c166750> url = <function url at 0x7fbf6c190398> WebDriverTests/imported/w3c/webdriver/tests/cookies/get_named_cookie.py:97: AssertionError
Hi Carlos, I'm seeing an XSSAuditor console message that this inline script evaluation was blocked. [Error] The XSS Auditor refused to execute a script in 'http://localhost:8802/webdriver/tests/support/inline.py?doc=%3Cscript%3Edocument.cookie+%3D+%27hello%3Dnewworld%3B+domain%3Dlocalhost%3B+path%3D%2F%27%3B%3C%2Fscript%3E&content-type=text%2Fhtml%3Bcharset%3Dutf-8' because its source code was found within the request. The auditor was enabled because the server did not send an 'X-XSS-Protection' header. (inline.py, line 1) Thus the cookie is not set via document.cookie. I believe this could be fixed by sending the X-XSS-Protection header with the main resource. Have you encountered this as well, or is it purely a problem is Soup backend? I'm pretty sure the problem of missing a leading period was already fixed and you added a test for it.
<rdar://problem/39212139>
(In reply to Brian Burg from comment #1) > Have you encountered this as well, or is it purely a problem is Soup backend? I played a bit with grep and found this: Scripts/webkitpy/webdriver_tests/webdriver_driver_gtk.py: return ['--auto mation', '--javascript-can-open-windows-automatically=true', '--enable-xss-audit or=false'] So that would be why we don't notice XSS auditor problems when running the WebDriver tests for GTK. It would probably make sense to reevaluate that.
(In reply to Michael Catanzaro from comment #3) > (In reply to Brian Burg from comment #1) > > Have you encountered this as well, or is it purely a problem is Soup backend? > > I played a bit with grep and found this: > > Scripts/webkitpy/webdriver_tests/webdriver_driver_gtk.py: return > ['--auto > mation', '--javascript-can-open-windows-automatically=true', > '--enable-xss-audit > or=false'] > > So that would be why we don't notice XSS auditor problems when running the > WebDriver tests for GTK. It would probably make sense to reevaluate that. Interesting. I run tests via Safari and it has no such option. I don't think this is something that should be unconditionally disabled for all Automation sessions since it is a legitimate error you would want to reproduce in a WebDriver test. For the purposes of making the W3C test pass, I think sending this header at some point is a reasonable workaround, and upstream opt would probably be OK adding that (at least for the 'inline' fixture used by WebDriver tests.
Yes, I disabled xss auditor for tests in GTK+ because of this. Of course this is only for tests, because there isn't any tests that require it, but we should not disable it for any normal automation session. The command line option of minibrowser is actually a web view setting. We could expose all settings via capabilities for example. I also had to enable js popups setting for the same reason.
We could also propose a change in the test in WPT to avoid this issue instead of looking for workarounds in our side.
(In reply to Carlos Garcia Campos from comment #5) > Yes, I disabled xss auditor for tests in GTK+ because of this. Of course > this is only for tests, because there isn't any tests that require it, but > we should not disable it for any normal automation session. The command line > option of minibrowser is actually a web view setting. We could expose all > settings via capabilities for example. I also had to enable js popups > setting for the same reason. In the Cocoa port, the _WKAutomationSessionDelegate method to create a new browsing context is where some WKPreferences are set, such as allowing JS to open popups and allowing fullscreen. There have also been some fixes to add a fake user gesture for WebDriver-initiated scripts, which fixes some similar issues, such as user gesture required for Storage Access API.
(In reply to Carlos Garcia Campos from comment #6) > We could also propose a change in the test in WPT to avoid this issue > instead of looking for workarounds in our side. I landed a fix in WPT a while ago: https://github.com/web-platform-tests/wpt/pull/10968 Closing this bug.