[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