Closed
Bug 1238269
Opened 9 years ago
Closed 9 years ago
Setting session cookie using chrome.cookies.set fails
Categories
(WebExtensions :: Untriaged, defect, P2)
Tracking
(firefox47 verified, firefox48 verified)
People
(Reporter: frolovm, Assigned: bsilverberg, Mentored)
Details
(Whiteboard: [cookies][good first bug] triaged)
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36
Steps to reproduce:
Using chrome.cookies.set to set a session cookie.
'details' parameter contains url, name, value, httpOnly=true
url is an HTTP url with port number
'callback' parameter specifies the callback function
The following page says that setting session cookies might fail: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Chrome_incompatibilities See cookies section. However, there was no corresponding bug to fix this.
Actual results:
In the callback function, 'cookie' parameter is null. chrome.extension.lastError is undefined (this is another bug.) Session cookie is not set.
Expected results:
Session cookie should be set. 'cookie' parameter should contain the set cookie data.
Reporter | ||
Updated•9 years ago
|
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Updated•9 years ago
|
Flags: blocking-webextensions?
Priority: -- → P2
Whiteboard: [cookies] triaged
Comment 1•9 years ago
|
||
Can you please provide a testcase extension that shows the problem?
Reporter | ||
Comment 2•9 years ago
|
||
Test case for session cookie set failure
Reporter | ||
Comment 3•9 years ago
|
||
It looks like there is a workaround.
If I set expirationDate then the session cookie is set.
Comment 4•9 years ago
|
||
Hm. Yeah. Apparently we set an expiration time of 0 for session cookies, and the cookie service honors that. The cookie service itself uses INT64_MAX.
We also apparently need tests for session cookies.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-webextensions? → blocking-webextensions+
Updated•9 years ago
|
Mentor: kmaglione+bmo
Whiteboard: [cookies] triaged → [cookies][good first bug] triaged
Reporter | ||
Comment 5•9 years ago
|
||
(In reply to Michail Frolov from comment #3)
> It looks like there is a workaround.
>
> If I set expirationDate then the session cookie is set.
I guess this makes the cookie permanent instead of session. Not really a workaround.
Reporter | ||
Updated•9 years ago
|
Attachment #8715097 -
Attachment mime type: application/zip → application/x-xpinstall
Updated•9 years ago
|
Assignee: nobody → bob.silverberg
Assignee | ||
Updated•9 years ago
|
Iteration: --- → 47.3 - Mar 7
Assignee | ||
Comment 6•9 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/35887/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/35887/
Attachment #8722162 -
Flags: review?(kmaglione+bmo)
Assignee | ||
Comment 7•9 years ago
|
||
Comment on attachment 8722162 [details]
MozReview Request: Bug 1238269 - Setting session cookie using chrome.cookies.set fails, r?kmag
Review request updated; see interdiff: https://reviewboard.mozilla.org/r/35887/diff/1-2/
Assignee | ||
Comment 8•9 years ago
|
||
Note that in addition to fixing the bug and adding tests for session cookies, I also cleaned up the existing tests.
Some of the assert messages were inconsistent in their statement, the order of the arguments for a number of the the `assertEq` were incorrect, and the expected order of arguments for the internal `assertExpected` was counter-intuitive as it does not match the standard `assertEq`. I apologize that this will add a bit of extra time to the review, but I think it's worth the effort to have tests that are consistent and accurate in their messages and use of the `assertEq` API.
Comment 9•9 years ago
|
||
Comment on attachment 8722162 [details]
MozReview Request: Bug 1238269 - Setting session cookie using chrome.cookies.set fails, r?kmag
https://reviewboard.mozilla.org/r/35887/#review32543
::: toolkit/components/extensions/test/mochitest/test_ext_cookies.html:64
(Diff revision 2)
> - browser.test.assertEq(cookie.hostOnly, false, "not a hostOnly cookie");
> + browser.test.assertEq(false, cookie.hostOnly, "cookie is hostOnly cookie");
*is not a host only cookie
::: toolkit/components/extensions/test/mochitest/test_ext_cookies.html:68
(Diff revision 2)
> + // create a session cookie
Please capitalize and end with a period.
::: toolkit/components/extensions/test/mochitest/test_ext_cookies.html:74
(Diff revision 2)
> + browser.test.assertEq(true, cookie.session, "got session cookie");
We should remove this cookie, too, and ideally test the removal.
::: toolkit/components/extensions/test/mochitest/test_ext_cookies.html:76
(Diff revision 2)
> - browser.test.notifyPass("cookies");
> + browser.test.notifyPass("cookies");
This doesn't need its own promise handler. It can go in the last one.
Attachment #8722162 -
Flags: review?(kmaglione+bmo) → review+
Assignee | ||
Comment 10•9 years ago
|
||
Comment on attachment 8722162 [details]
MozReview Request: Bug 1238269 - Setting session cookie using chrome.cookies.set fails, r?kmag
Review request updated; see interdiff: https://reviewboard.mozilla.org/r/35887/diff/2-3/
Assignee | ||
Comment 11•9 years ago
|
||
https://reviewboard.mozilla.org/r/35887/#review32543
> *is not a host only cookie
Oops. Fixed.
Assignee | ||
Comment 12•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Keywords: checkin-needed
Comment 13•9 years ago
|
||
bugherder landing |
Keywords: checkin-needed
Comment 14•9 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox47:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Comment 15•9 years ago
|
||
Is there any proper way of manually testing this bug? If yes, could you please provide some reliable steps?
Flags: needinfo?(kmaglione+bmo)
Assignee | ||
Comment 16•9 years ago
|
||
There was a test case extension attached in comment 2, so you could load that into your instance of Firefox and then check the console log for messages. It looks like with the bug the log will show the cookie as `null`. I assume that with the bug fixed you would see some output other than `null`.
Flags: needinfo?(kmaglione+bmo)
Comment 17•9 years ago
|
||
(In reply to Bob Silverberg [:bsilverberg] from comment #16)
> There was a test case extension attached in comment 2, so you could load
> that into your instance of Firefox and then check the console log for
> messages. It looks like with the bug the log will show the cookie as `null`.
> I assume that with the bug fixed you would see some output other than `null`.
Thanks Bob! You were right: http://i.imgur.com/mrcLKef.jpg
I was able to reproduce the initial issue on Firefox 46.0a1 (2016-01-25) under Windows 10 64-bit.
Verified fixed on Firefox 48.0a1 (2016-04-04) and Firefox 46.0a2 (2016-04-04) under Windows 10 64-bit, Mac OS X 10.11 and Ubuntu 12.04 32-bit.
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•