The default bug view has changed. See this FAQ.

Private cookie set by cookies.set disappears within a second when the private window was just opened

NEW
Assigned to

Status

()

Toolkit
WebExtensions: General
P2
normal
5 months ago
2 months ago

People

(Reporter: robwu, Assigned: mixedpuppy)

Tracking

(Blocks: 1 bug)

52 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox52 affected)

Details

(Whiteboard: triaged[cookies])

Attachments

(1 attachment)

(Reporter)

Description

5 months ago
Created attachment 8800301 [details]
cookies-private.zip

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).

Updated

5 months ago
Assignee: nobody → mixedpuppy
Priority: -- → P2
Whiteboard: triaged

Comment 1

5 months 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.
(Assignee)

Comment 2

5 months ago
If I take the attached addon, and add url to the window.create call, the delayed cookie getter always succeeds.  Still digging...
(Assignee)

Comment 3

5 months 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
Flags: needinfo?(kmaglione+bmo)
(Assignee)

Comment 4

4 months 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.

Updated

4 months ago
Whiteboard: triaged → triaged[cookies]
(Assignee)

Comment 5

3 months ago
possible origin attributes bug.
Flags: needinfo?(huseby)

Comment 6

3 months ago
It looks like it might be.  cc'd Tanvi and Baku too.
Flags: needinfo?(huseby)
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?
Whiteboard: triaged[cookies] → triaged[cookies][OA]

Comment 8

3 months 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.
Flags: needinfo?(kmaglione+bmo)
Whiteboard: triaged[cookies][OA] → triaged[cookies]

Updated

2 months ago
Blocks: 1332809

Updated

2 months ago
No longer blocks: 1332809
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.
(Reporter)

Updated

2 months ago
Blocks: 1309610
You need to log in before you can comment on or make changes to this bug.