Bug 182330 – WebDriver: test imported/w3c/webdriver/tests/cookies/get_named_cookie.py::test_duplicated_cookie fails

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: WebDriver

[Carlos Garcia Campos]

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

[Blaze Burg]

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.

[Radar WebKit Bug Importer]

<rdar://problem/39212139>

[Michael Catanzaro]

(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.

[Blaze Burg]

(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.

[Carlos Garcia Campos]

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.

[Carlos Garcia Campos]

We could also propose a change in the test in WPT to avoid this issue instead of looking for workarounds in our side.

[Blaze Burg]

(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.

[Blaze Burg]

(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.