Chrome is sometimes unable to write a cookie from within an iframe
Reported by
mcam...@breadfinance.com,
Jan 10
|
||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Steps to reproduce the problem:
1. Unpack the attached zip, it contains 2 files: index.html, and cookie.html. Serve the directory where the files were unpacked and access that page.
2. Wait until the page alerts with "CANNOT COOKIE LOCAL" (You may need to open multiple tabs to see this behavior, as it is not consistent.
3.
What is the expected behavior?
I expect to be able to write and read cookies within the same operation so that I can feature detect that cookies are available.
What went wrong?
Our application uses iframes, within the iframe we attempt to set cookies. If the user has cookies blocked for some reason, we show an error message and stop the application.
Starting in April of 2018, we noticed an increase in the number of users that were being blocked due to not being able to set a cookie. We also observed those same users able to continue using our application after refreshing the page. We have found that *sometimes* we are unable to both write a cookie, and read that cookie within the same frame i.e.,
document.cookie="foo=true";
if (~document.cookie.indexOf("foo") {
// unable to set cookie
} else {
// expire test cookie and proceed
document.cookie="foo=true; expires=Thu, 01-Jan-1970 00:00:01 GMT";
}
I've found that the test case fails faster in Safari than Chrome, and I haven't been able to cause it to occur in Firefox or Internet Explorer.
The failure appears to be on write. Once the error condition occurs you can examine `document.cookie` and find that it won't contain the cookie that was set.
Did this work before? Yes 64
Does this work in other browsers? No
The behavior in Safari matches the Chrome behavior. I am not able to reproduce this in Firefox.
Chrome version: 71.0.3578.98 Channel: stable
OS Version: OS X 10.13.6
Flash Version:
,
Jan 10
No idea who owns this code, but it's in blink, not net/.
,
Jan 11
Sounds like this is more about document.cookie than cookies attached or set during Navigation, so I don't think that's the right component. Trying Blink>Storage>CookiesAPI (and maybe mkwst@?), to get folks at least familiar with document.cookie. Anyone able to take a look? I might have suspected Site Isolation (and I'm speculatively adding that component), given that this is observed in iframes and started around April 2018, shortly before Site Isolation launched on desktop. However, it sounds like the bug is not specific to cross-site iframes (which now run in a different process than their parent page), and even affects Safari. That means it's unlikely Site Isolation is the cause.
,
Jan 11
,
Jan 11
Tried testing the issue on reported chrome version #71.0.3578.98 using Mac OS 10.13.6 by following below steps. Steps: ===== 1.Launched chrome. 2.Extracted "cookie-test.zip". 3.Opened "index.html" and "cookie.html". 4.Observed an alert "CANNOT COOKIE LOCAL". Tested the issue on chrome version #64.0.3270.0, observed the same behaviour as mentioned above. Note: In Firefox when tested the issue observed that no alert being displayed on opening "index.html" and "cookie.html". Attached screencasts for reference. @reporter: Could you please review attached screencasts and let us know if this is the issue you are pointing to. Thanks.!
,
Jan 11
@swarnasree.mukkala@chromium.org The alert will appear when the test cookie is unable to be set. In your test run, it appears you are opening the file directly `file://` which I don't believe is able to set a cookie in normal circumstances. In my test I used an http server (https://www.npmjs.com/package/serve) to serve the files statically from my local machine. I don't have a video of the behavior, but I am attaching a screenshot from when it occurred with a local http server setup.
,
Jan 11
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 11
@swarnasree.mukkala@chromium.org Here is a screencast which also captures the behavior. Note at the end of the video, tabs that have a blue circle have fired the alert in the background. 2/5 tabs alerted.
,
Jan 14
Able to reproduce the issue on chrome reported version# 71.0.3578.98 and on latest chrome# 73.0.3670.0 using Mac 10.12.6,Windows-10 and Ubuntu 14.04 hence providing Bisect info Bisect Info: ================ Good build: 71.0.3569.0 Bad build: 71.0.3570.0 Change Log from Omahaproxy: https://chromium.googlesource.com/chromium/src/+log/71.0.3569.0..71.0.3570.0?pretty=fuller&n=10000 Note: On running tool bisect it is showing inconsistent result, hence requesting someone from the Dev team for further investigating on this issue and help in assigning to appropriate owner. Hence marking it as Untriaged. Adding ReleaseBlock-Stable for M-71, feel free to remove it if not applicable. Thanks!
,
Jan 14
,
Jan 14
[bulk update] Just a heads up, M72 stable is about 2 weeks away. This issue is marked as RB-Stable. Please take a look.
,
Jan 14
Since this is reported back to April of 2018 (per initial description), and affects Safari as well, I'm removing ReleaseBlock-Stable and Regression-71 We should still investigate it; leaving Priority/Status alone for now.
,
Jan 14
I spent some time downloading older version of Chromium today, and ran the same test (5 tabs running the test case, for 5 minutes). Chromium 60.0.3112.78 did not trigger the alert, while 61.0.3163.100 did so around the 3minute mark. Based on this result, it is my belief that the bug was introduced between these versions.
,
Jan 15
Thanks! Dropping SiteIsolation component, although it's still a plausible candidate. |
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by lgrey@chromium.org
, Jan 10