Closed
Bug 1287985
Opened 8 years ago
Closed 7 years ago
Expiry dates are stripped from cookies
Categories
(Remote Protocol :: Marionette, defect, P3)
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}
Updated•7 years ago
|
Priority: -- → P3
Comment 1•7 years ago
|
||
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).
Comment 2•7 years ago
|
||
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.
Comment 3•7 years ago
|
||
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
status-firefox56:
--- → fixed
Depends on: 1371733
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Updated•1 year ago
|
Product: Testing → Remote Protocol
You need to log in
before you can comment on or make changes to this bug.
Description
•