Closed Bug 1858366 Opened 8 months ago Closed 5 months ago - Cookies can not be saved


(Core :: Networking: Cookies, defect, P2)

Windows 10



123 Branch
Tracking Status
firefox-esr115 --- wontfix
firefox120 --- wontfix
firefox121 --- wontfix
firefox122 --- wontfix
firefox123 --- verified


(Reporter: rbucata, Assigned: edgul)


(Blocks 1 open bug, Regression)


(Keywords: regression, Whiteboard: [necko-triaged][necko-priority-queue])


(2 files, 1 obsolete file)

From github:

<!-- @browser: firefox108.0.0 -->
<!-- @ua_header: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36 -->
<!-- @reported_with: unknown -->


Browser / Version: firefox108.0.0
Operating System: Windows 10
Tested Another Browser: Yes Chrome

Problem type: Something else
Description: firefox浏览器,cookie过期后再次存储,存入不进去,需要存入两编
Steps to Reproduce:
firefox 浏览器在cookie过期后,再次存储,存入不进去,需要存两次才可以存入

<summary>Browser Configuration</summary>

From with ❤️

Change performed by the Move to Bugzilla add-on.

The issue was reported via the reporter. Since the issue is related to cookie storage, we have moved the issue. Please feel free to move the issue to the correct Product and Component.

Component: General → Networking: Cookies
OS: Android → Windows 10
Hardware: Unspecified → Desktop

I can reproduce this with the example provided here.

This seems to be caused by the error below:

[Parent 59694: Main Thread]: W/cookie ===== COOKIE NOT ACCEPTED =====
[Parent 59694: Main Thread]: W/cookie request URL: http://localhost:8888/Untitled-1.html
[Parent 59694: Main Thread]: W/cookie cookie string:
[Parent 59694: Main Thread]: W/cookie current time: Fri Oct 13 09:57:24 2023 GMT
[Parent 59694: Main Thread]: W/cookie rejected because stale cookie was purged

In content process, we were able to store the cookie in the CookieList, but it was removed because the error above.

Blocks: cookie
Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged][necko-priority-new]

The translated STR from github issue is:

  1. Open this html file.
<!DOCTYPE html>
<html lang="zh">
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta http-equiv="Access-Control-Allow-Origin" content="*" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" />
<body id="het">
    <noscript>Sorry, we need js to run correctly!</noscript>
    <div id="root">
        <button onclick="getCookie()">Get cookie</button>
        <button onclick="setCookie()">Set cookie</button>
    function getCookie(cookieName) {
        console.log('Get cookie',);
        const strCookie = document.cookie
        const cookieList = strCookie.split(';')
        console.log("cookieList: " + JSON.stringify(cookieList))
        for (let i = 0; i < cookieList.length; i++) {
            const arr = cookieList[i].split('=')
            if ("userInfo" === arr[0].trim()) {
                console.log('cookie is:', arr[1]);
            console.log('no cookie');
        return ''
    function setCookie(params) {
        console.log('Set cookie',);
        const exdate = new Date()
        exdate.setTime(exdate.getTime() + 10 * 1000)
        document.cookie = `${'userInfo'}=test${`;expires=${exdate.toGMTString()}`}`

  1. Click Set Cookie and wait for 10s.
  2. Click Set Cookie again.
  3. Click Get Cookie and we are not able to see the cookie.
Whiteboard: [necko-triaged][necko-priority-new] → [necko-triaged][necko-priority-queue]
Assignee: nobody → edgul

The issue is that the mProcessingCookie flag blocks a relay of the cookie back to the Content Process.
In theory, this shouldn't matter because we would expect the content process cookie list to be aware of the cookie as it is first set when it comes directly into the Content Process via document.cookie.

The problem arises because the cookie purging of the old cookie doesn't trigger until the set-cookie reaches the parent process, at this point the parent process broadcasts a purge (of the old cookie) to the content process and relays the new cookie back to the content process for a second update to the cookie list. So the content process purges the cookies, including the new one, and now that we are blocking the new-cookie broadcast, we lose the second update and the new cookie along with it.

This bug is a regression revealed by Bug 1782561.

Keywords: regression
Regressed by: CVE-2023-4055

Set release status flags based on info from the regressing bug 1782561

Set release status flags based on info from the regressing bug 1782561

Attachment #9368466 - Attachment is obsolete: true
Attachment #9369658 - Attachment description: WIP: Bug 1858366 - Only purge cookies in content process memory with matching expiry → Bug 1858366 - Only purge cookies in content process memory with same or older expiry. r?valentin,dveditz

:edgul is this something we would like to include as a ride-along in an Fx122 dot release or should it ride the train? The same question goes for ESR115.
I see this was just reviewed. If you're going to land it before Fx123 merge day on 2024-01-22.

Flags: needinfo?(edgul)

I'm looking to make some changes on the child patch, so we might not get this in on 2024-01-22, but this will be fine to ride the train once we get it in.

Flags: needinfo?(edgul)
Comment 5 is private: false
Comment 7 is private: false
Pushed by
Added notifications for updates to content-side cookie lists that were triggered by parent process. r=valentin,cookie-reviewers
Only purge cookies in content process memory with same or older expiry. r=valentin,dveditz,cookie-reviewers
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 123 Branch
Flags: qe-verify+

Reproduced the issue with Firefox 120.0a1 (2023-10-13) on Windows 10x64. no cookie message is displayed inside the web console after following steps from comment 3.
The issue is verified fixed with Firefox 123.0b2 on Windows 10x64, macOS 12 and Ubuntu 20.04. The cookie is: test message is displayed inside the web console after following the steps from comment 3.

Has STR: --- → yes
Flags: qe-verify+
Duplicate of this bug: 1877844
See Also: → 1877844
You need to log in before you can comment on or make changes to this bug.