Closed Bug 1287985 Opened 8 years ago Closed 7 years ago

Expiry dates are stripped from cookies

Categories

(Remote Protocol :: Marionette, defect, P3)

x86_64
macOS
defect

Tracking

(firefox56 fixed)

RESOLVED FIXED
mozilla56
Tracking Status
firefox56 --- fixed

People

(Reporter: dylan, Assigned: ato)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

1: Spin up a small server issuing a cookie with an expiry one day in the future (eg by running this script with rackup (https://gist.github.com/DylanLacey/ecbd364ad28f612547510494d858d0dc#file-app-rb)

2: Started a Marionette enabled Selenium Server instance

3: Executed a small Selenium script that navigates to the above page with Firefox and Marionette and retrieves the cookies; Observing that the 'foo' cookie no longer has an expiry (For ease of use, script is here in delicious Ruby: https://gist.github.com/DylanLacey/ecbd364ad28f612547510494d858d0dc#file-test_script-rb)

4: Repeat 3 without Marionette; Expiry is present.

(NB: Github tags don't appear to correlate to the version field above?  Was using Selenium Server 2.53.1 and Marionette tag 0.9.0, latest at report date)


Actual results:

Cookie value {:name=>"foo", :value=>"bar", :path=>"/", :domain=>"localhost", :expires=>nil, :secure=>false}


Expected results:

Cookie value {:name=>"foo", :value=>"bar", :path=>"/", :domain=>"localhost", :expires=>#<DateTime: 2016-07-21T03:46:15+00:00 ((2457591j,13575s,999999850n),+0s,2299161j)>, :secure=>false}
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
Priority: -- → P3
I'm unable to reproduce this locally on mozilla-central. The example app didn't quite work for me, but even after trying to mimic this issue via geckodriver and a test, I could see the cookie expiration returned from both Marionette and geckodriver.

In Marionette I couldn't find code that would allow to retrieve an individual cookie, so IMO the getCookies() call is the only one that could be at fault, however the expiration time was returned and corresponded to the correct date in my case (OSX).
https://github.com/mozilla/geckodriver/issues/463 suggests that this was fixed for Firefox 56. There is a test for this in the Selenium test suite, and I just got that test to pass on Firefox 56 and fail on Firefox 55.
Thanks for the feedback. It has been most likely be fixed by the patch on bug 1371733 then.
Assignee: nobody → ato
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Depends on: 1371733
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.