[Bug 20975] New: [WebDriver Spec]: Undefined behaviour for Cookie setting against a Session that has had no Navigation yet

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20975

            Bug ID: 20975
           Summary: [WebDriver Spec]: Undefined behaviour for Cookie
                    setting against a Session that has had no Navigation
                    yet
    Classification: Unclassified
           Product: Browser Test/Tools WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: WebDriver
          Assignee: public-browser-tools-testing@w3.org
          Reporter: detronizator@gmail.com
        QA Contact: public-browser-tools-testing@w3.org
                CC: mike@w3.org
            Blocks: 20860

There is a corner case not covered in the Cookies section of the document
(https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#cookies).

When a WebDriver Session is first created, the Browser Window is "domain less".
Most probably pointing at "about:blank" or some similar page.

The operation to SET/ADD a Cookie allows, in the input object, allows to omit
the "domain" field. Current implementations of the specs "silently fill" the
domain field for the user, with the domain of the current page.

There is a corner-case scenario though. When a new Session, still "domain less"
(see above), cannot "fill" that "domain" field if an attempt to set a cookie
without domain is made.

Current implementations behaviour:
- ChromeDriver: throws an error "Couldn't set cookie"
- FirefoxDriver: accepts and sets the cookie, and it's available for retrieval
- GhostDriver: accepts the cookie, but it's not available for retrieval


Hence, it's important to define what should ACTUALLY happen in this scenario.

SUGGESTION: ChromeDriver behaviour is correct. Setting a cookie on a "domain
less" page should be forbidden and throwing an error/exception.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 12 February 2013 12:24:51 UTC