"UnableToSetCookieException: Message: unable to set cookie" error after upgrading to Chrome 77.0.3865.75 + Chromedriver 77.0.3865.40

[dfu...@sentry.io]

I'm seeing most of my selenium tests using Chromedriver failing after we upgraded to Chrome 77 + corresponding version of chromedriver. Nothing else has changed from what I can tell, just the version bump.

Stacktrace looks like

```

  File "/Users/dfuller/.virtualenvs/sentry/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py", line 894, in add_cookie

    self.execute(Command.ADD_COOKIE, {'cookie': cookie_dict})

  File "/Users/dfuller/.virtualenvs/sentry/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py", line 321, in execute

    self.error_handler.check_response(response)

  File "/Users/dfuller/.virtualenvs/sentry/lib/python2.7/site-packages/selenium/webdriver/remote/errorhandler.py", line 242, in check_response

    raise exception_class(message, screen, stacktrace)

UnableToSetCookieException: Message: unable to set cookie

  (Session info: headless chrome=77.0.3865.75)
```

I also see `WARNING: Failed to gather log types: Message: unknown command: Cannot call non W3C standard command while in W3C mode`. Passing `options.add_experimental_option("w3c", False)` allows the tests to pass, but from what I understand it's generally bad practice to do so?

Is this a bug with the latest chromedriver?

[T Crichton]

Regarding log types, this command for w3c mode isn't working in the Selenium code in version 3.14. There is a fix already committed to the Selenium code base, but it has not yet been assigned to a release.

The updated file is here:
https://github.com/SeleniumHQ/selenium/blob/master/py/selenium/webdriver/remote/remote_connection.py

You will need this version or later:
https://github.com/SeleniumHQ/selenium/commit/15d8c41747c754c7b121939c1781de529142fc69

ChromeDriver currently offers the following levels: ALL, DEBUG, INFO, WARNING, SEVERE, and OFF

You are correct that setting w3c to false is not recommended, and is certainly not a permanent fix. It can help you get through testing while you are updating code or waiting for other bug fixes, but we expect to discontinue support for the legacy mode at some point in the future.

Regarding the Cookies, the stacktrace doesn't give enough information. Please attach a verbose ChromeDriver log, sample html, and simple repro code so that we may troubleshoot further.

What version are you upgrading from? W3C mode was made default at version 75. Version 76 made substantial changes to the javascript used by ChromeDriver - this is why seeing your html may be helpful.

[Dan Fuller]

We're basically following stable most of the time. Previously we were on Chrome 76 latest + Chromedriver 76 latest (sorry, I don't have exact versions on hand). It has been working fine for the most part, although I've seen

Cannot call non W3C standard command while in W3C mode

a few times, which would then be resolved by a later version.

I'll look into upgrading Selenium, although since it's a major version bump I'm not sure how practical that will be short term.

I've attached my chromedriver log.

Repro code:

class ReproTest(AcceptanceTestCase):
    def test(self):
        self.browser.save_cookie(name="hi", value="hello")

Where `browser` is a `selenium.Browser` instance. We're not even hitting a webpage at this point, so I haven't included any sample html. I can further break this down if you need, but I think just calling `save_cookie` on a browser should be enough to reproduce this.

[T Crichton]

Hi Dan,

I don't find a selenium.Browser class in the python Selenium bindings (your code looks like python). So I used the following to reproduce your issue:

driver.add_cookie({'name' : 'noPage', 'value' : 'hello'})

I get a different error - invalid cookie domain. But if I navigate to a proper url, then I am able to set a cookie successfully.

My repro is working according to the w3c spec. According to https://w3c.github.io/webdriver/#add-cookie:

If the current browsing context’s document element is a cookie-averse Document object, return error with error code invalid cookie domain.

And according to https://html.spec.whatwg.org/#resource-metadata-management:

A Document object that falls into one of the following conditions is a cookie-averse Document object:

A Document object whose browsing context is null.

A Document whose URL's scheme is not a network scheme.

ChromeBrowser's Cookie handling was made spec-compliant in version 77, which is why you are just seeing it now. 

If your test navigates to a http(s) site prior to setting the cookie, it should work.

[Dan Fuller]

Sorry, Browser is our class, I missed that while debugging yesterday. Your response pointed me in the right direction, although I'm not quite there yet. 

We do navigate to a page (http://localhost:8081/auth/login/, which loads successfully), and when creating the cookie we set the domain explicitly to "localhost", which fails. If I don't explicitly pass a domain then we're able to successfully create the cookie.

The cookie I'm passing to `add_cookie` looks like:

cookie = {
    "name": "hi",
    "value": "hello",
    "expires": "Tue, 20 Jun 2025 19:07:44 GMT",
    "path": "/",
    "domain": "localhost",
}

I've tried passing the domain explicitly as 

{"domain": "localhost"}

{"domain": "localhost:8081"}

{"domain": "localhost", "port": 8081}

These all fail with "UnableToSetCookieException: Message: unable to set cookie"

If I omit domain completely like:

cookie = {
    "name": "hi",
    "value": "hello",
    "expires": "Tue, 20 Jun 2025 19:07:44 GMT",
    "path": "/",
}

It succeeds and when I retrieve the cookie it looks like

{u'domain': u'localhost', u'name': u'hi', u'value': u'hello', u'path': u'/', u'httpOnly': False, u'secure': False}

I could potentially just stop passing along the domain, although I'm hesitant to change our tests since they've been working ok up until this point. Is it possible that there's some problem with dealing with localhost and ports if we pass domain explicitly?

[T Crichton]

Interesting. I was just told, and then confirmed, that setting any domain for the cookie will fail. For example, visiting stackoverflow, and setting the cookie domain to stackoverflow gives the same message as localhost on localhost.

This looks like a change in Chrome rather than ChromeDriver. We are trying to determine exactly which change is responsible.

[T Crichton]

Disregard my last comment, I misunderstood. We can set domain to stackoverflow.com when visiting that site.

[John Chen]

The current WebDriver standard isn't clear on how cookie domain should be handled. ChromeDriver's implementation attempts to follow https://tools.ietf.org/html/rfc6265#section-5.3. According to item 6 of the cookie storage model, specifying a cookie domain results in a domain cookie, while not specifying the domain results in a host-only cookie. However, creating a domain cookie for localhost doesn't really make sense, as localhost doesn't following the domain naming conventions. Chrome used to be lenient with this, but Chrome 77 now has code to reject creating domain cookie for localhost, so specifying domain for localhost cookie is no longer allowed.

--
You received this message because you are subscribed to the Google Groups "ChromeDriver Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromedriver-us...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chromedriver-users/53e9b320-345e-4171-9a08-f536e121b1f3%40googlegroups.com.

[Dan Fuller]

I see, so really the correct thing to do here is not set domain if we're attempting to set a cookie on localhost. Will go ahead with that fix, thanks for the information!

To unsubscribe from this group and stop receiving emails from it, send an email to chromedriver-users+unsub...@googlegroups.com.