example.com - Cookies can not be saved
Categories
(Core :: Networking: Cookies, defect, P2)
Tracking
()
People
(Reporter: rbucata, Assigned: edgul)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [necko-triaged][necko-priority-queue])
Attachments
(2 files, 1 obsolete file)
From github: https://github.com/webcompat/web-bugs/issues/128244.
<!-- @browser: firefox108.0.0 -->
<!-- @ua_header: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 -->
<!-- @reported_with: unknown -->URL: https://example.com
Browser / Version: firefox108.0.0
Operating System: Windows 10
Tested Another Browser: Yes ChromeProblem type: Something else
Description: firefox浏览器，cookie过期后再次存储，存入不进去，需要存入两编
Steps to Reproduce:
firefox 浏览器在cookie过期后，再次存储，存入不进去，需要存两次才可以存入<details>
<summary>Browser Configuration</summary>
<ul>
<li>None</li>
</ul>
</details>From webcompat.com with ❤️
Change performed by the Move to Bugzilla add-on.
|
Reporter | |
Comment 1•2 years ago
|
||
The issue was reported via the webcompat.com 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.
|
|
Reporter | |
Updated•2 years ago
|
|
|
Reporter | |
Updated•2 years ago
|
|
||
Comment 2•2 years ago
|
||
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.
|
|
||
Comment 3•2 years ago
|
||
The translated STR from github issue is:
- Open this html file.
<!DOCTYPE html>
<html lang="zh">
<head>
<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" />
<title></title>
</head>
<body id="het">
<noscript>Sorry, we need js to run correctly!</noscript>
<div id="root">
<button onclick="getCookie()">Get cookie</button>
<br>
<button onclick="setCookie()">Set cookie</button>
</div>
</body>
<script>
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]);
return;
}
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()}`}`
}
</script>
</html>
- Click
Set Cookieand wait for 10s. - Click
Set Cookieagain. - Click
Get Cookieand we are not able to see the cookie.
|
|
||
Updated•2 years ago
|
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.
|
||
Comment 5•1 years ago
|
||
Set release status flags based on info from the regressing bug 1782561
|
||
Updated•1 years ago
|
|
||
Updated•1 years ago
|
|
|
||
Comment 7•1 year ago
|
||
Set release status flags based on info from the regressing bug 1782561
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
|
||
Updated•1 year ago
|
|
|
||
Comment 10•1 year ago
|
||
: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.
|
Assignee | |
Comment 11•1 year ago
|
||
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.
|
|
||
Updated•1 year ago
|
|
||
Updated•1 year ago
|
|
||
Comment 12•1 year ago
|
||
|
||
Comment 13•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/82d32b62666e
https://hg.mozilla.org/mozilla-central/rev/1c6aaa7485ee
|
||
Updated•1 year ago
|
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.
Description
•