Rob Wu [:robwu] Reporter
	Description • 8 years ago

1. Load attached cookies-private.zip at about:debugging
2. Click on the addon button.
   -- It will open a private window, and set/get/print cookies.
3. Wait a second.
4. Open the global JS console (or the extension's debugger).

Expected:
result from cookies.set: {"name":"dummyname", ...} background.js:13:13
result from cookies.get: {"name":"dummyname", ...}  background.js:19:17
result from cookies.get (delayed): {"name":"dummyname","value":"dummyvalue", ...}

Actual:
result from cookies.set: {"name":"dummyname", ...} background.js:13:13
result from cookies.get: {"name":"dummyname", ...}  background.js:19:17
result from cookies.get (delayed): null

It seems that the cookie store associated with windows.create({incognito:true}) is somehow reset "soon" after the window is created. If there is already a private window, or if I insert an artificial delay of a split second to the callback of windows.create before continuing, the test passes.

This problem is causing an intermittent failure at http://searchfox.org/mozilla-central/rev/cd1be634c9309c7fc99a3fde67dd44d343875f60/toolkit/components/extensions/test/mochitest/test_ext_cookies.html#185
212 INFO TEST-PASS | toolkit/components/extensions/test/mochitest/test_ext_cookies.html | no expiry date created session cookie - Expected: true, Actual: true
JavaScript error: moz-extension://3dbaf234-532c-924a-befe-5fe93220f14f/%7B5a157cec-de97-a74e-b253-00a336eddff5%7D.js, line 175: TypeError: cookie is null
(and after this the test times out).

	Jesper Kristensen
	Comment 1 • 8 years ago

I have seen a similar bug sometimes, but I have not filed it yet since I was trying to find a way to reproduce it. Not sure if these are related, so sorry for messing up this bug if they are not.

My extension only reads from the cookies API.

My steps, only rarely reproducible:
1. Open a new private window.
2. Navigate to a login page and log in.
3. Quickly, within a second or two, click a button in my extension that navigate the current tab to a moz-extension:// page.
4. My extension tries to read the session cookie that was just set by the page, but did not find it.
5. Click Back in the browser to go back to the web site.
6. I am now logged out of the site.

Sorry for the vague description.

	Shane Caraveo (:mixedpuppy) Assignee
	Comment 2 • 8 years ago

If I take the attached addon, and add url to the window.create call, the delayed cookie getter always succeeds.  Still digging...

	Shane Caraveo (:mixedpuppy) Assignee
	Comment 3 • 8 years ago

@kmag, does the following information ring any bells?

failing repro:

window.create({incognito: true}).then
cookie.set for example.com OK
cookie.get for example.com OK
settimeout(cookie.get for example.com ) FAILS

* cookie is no longer set

working repro:

window.create({url for example.com , incognito: true)).then
cookie.set for example.com OK
cookie.get for example.com OK
settimeout(cookie.get for example.com ) SUCCEEDS

* cookie remains set for private mode until private windows are closed

	Shane Caraveo (:mixedpuppy) Assignee
	Comment 4 • 8 years ago

Adding to the above...this also works as I would expect:

window.create({incognito: true)).then
settimeout(
  cookie.set for example.com OK
  cookie.get for example.com OK
  settimeout(cookie.get for example.com ) SUCCEEDS
)

My suspicion is that there is a timing issue in the first test set in comment 3.  Even though window.create has resolved, something about the window has not completed setting up, so the set/get happens, then settimeout lets the window finish startup and the cookie store is cleared (a guess) except for any tabs that are being loaded at that time.

	Shane Caraveo (:mixedpuppy) Assignee
	Comment 5 • 8 years ago

possible origin attributes bug.

	Dave Huseby [:huseby]
	Comment 6 • 8 years ago

It looks like it might be.  cc'd Tanvi and Baku too.

	Tanvi Vyas[:tanvi]
	Comment 7 • 8 years ago

This may or may not be OA related.  Do you have a regression range?  Is this Firefox 52+?

The disappearing cookie doesn't show up in normal mode, right?

	Kris Maglione [:kmag]
	Comment 8 • 8 years ago

So, apparently the problem is that we create new private browsing windows with the default new tab URL, rather than about:privatebrowsing, when no URL is passed. I'm not sure exactly why, but this causes the last-pb-context-exited notification to be dispatched just after the window is created.

My best guess is that it's happening because we're creating the initial browser for the window as a remote browser, then switching it to a non-remote browser to load about:newtab, which winds up destroying the last private docShell in the content process. It only ever happens if the first URL that we load into the window needs to load in the parent process, though, so we're presumably later creating another ContentParent that keeps the private browsing state alive if the last tab switches remoteness.

	Gabor Krizsanits (INACTIVE)
	Comment 9 • 7 years ago

To land e10s-multi I had to turn off the private window parts of test_ext_cookies.html. Once this bug is fixed it should be turned back on.

	Julien Cristau [:jcristau]
	Comment 10 • 7 years ago

Mass wontfix for bugs affecting firefox 52.

	Jonathan Kingston [:jkt] he/him
	Comment 11 • 7 years ago

Baku does this look like something you would be responsible for or others in your team?
It looks like the cookie clearing code on startup might not be obeying origin attributes. I actually thought I had patched this already.
If I can get time assigned for this I could look at it too.

	Andrea Marchesini [:baku]
	Comment 12 • 7 years ago

Is this still a valid bug? I'm not able to reproduce it. jkt can you?

	Jonathan Kingston [:jkt] he/him
	Comment 13 • 7 years ago

Will check, leaving NI as I think this might have been fixed by the other bug related to this (can't remember the ID).

	Shane Caraveo (:mixedpuppy) Assignee
	Comment 14 • 6 years ago

I am no longer able to reproduce this, so closing.