Issue metadata
Sign in to add a comment
|
Cookie domain list is incomplete when I refresh an existing page with devtools open |
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 10032.86.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.140 Safari/537.36 Platform: 10032.86.0 (Official Build) stable-channel chell Steps to reproduce the problem: 1. Visit a site which has cookies from several domains, eg, https://www.nytimes.com/ (without signin) or https://app.google.stackdriver.com (once signed in) Wait for the page to load. 2. Open Devtools 3. Switch to the applications tab 4. Expand the "Cookies" tree item 5. Observe the list of cookie domains 6. Refresh the page What is the expected behavior? The items under the "Cookies" tree item remain more-or-less identical once it fully repopulates on reload. What went wrong? Only a small number of cookie domains actually wind up being listed under the the "Cookies" tree item. You can confirm that this does not reflect reality by closing and re-opening DevTools after entering this state. At that point the full list of cookie domains will be available again. Did this work before? Yes Unknown Chrome version: 63.0.3239.140 Channel: stable OS Version: 10032.86.0 Flash Version: This has also been observed on Chrome 64 on Linux.
,
Feb 8 2018
Thanks for filing philipkovac. Something very strange indeed is going on with stackdriver. The entire domain is disappearing from the table after flashing for a second and cookies seem to get shuffled into the wrong frames/origins. Is this what you observe as well? For NYT though I've tried numerous refreshes/hard refreshes/opening closing DevTools and am not able to reproduce. I always see the same set of ~40 frames and same set of cookies for the nytimes root frame across a page load.
,
Feb 9 2018
Update on this, looks like it's an OOPIF issue. With the introduction of out of process iframes, the cookies are being cleared from the UI on every new google-origin iframe navigation. You also probably observed this on NYT even though I didn't because a different ad loaded that was covered under OOPIF for you :) https://chromium-review.googlesource.com/c/chromium/src/+/909832 contains a fix that ca n work for cookies as well once it lands
,
Feb 9 2018
Yes, that's precisely the behavior I observe for Stackdriver. Glad there's a fix in the pipeline, thanks for looking!
,
Feb 26 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7fd8040a214875fbb5b949e9e7c57a6c771ac0e6 commit 7fd8040a214875fbb5b949e9e7c57a6c771ac0e6 Author: Patrick Hulce <phulce@chromium.org> Date: Mon Feb 26 21:04:18 2018 DevTools: Fix cookies for OOPIFs on refresh * Use isTopFrame to determine when to reset resources panel BUG= 810000 Change-Id: I8cfde733fee4e97b7066411d849a844bc58525c5 Reviewed-on: https://chromium-review.googlesource.com/934962 Commit-Queue: Patrick Hulce <phulce@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#539268} [add] https://crrev.com/7fd8040a214875fbb5b949e9e7c57a6c771ac0e6/third_party/WebKit/LayoutTests/http/tests/devtools/oopif/oopif-cookies-refresh-expected.txt [add] https://crrev.com/7fd8040a214875fbb5b949e9e7c57a6c771ac0e6/third_party/WebKit/LayoutTests/http/tests/devtools/oopif/oopif-cookies-refresh.js [modify] https://crrev.com/7fd8040a214875fbb5b949e9e7c57a6c771ac0e6/third_party/WebKit/Source/devtools/front_end/application_test_runner/ResourcesTestRunner.js [modify] https://crrev.com/7fd8040a214875fbb5b949e9e7c57a6c771ac0e6/third_party/WebKit/Source/devtools/front_end/resources/ApplicationPanelSidebar.js
,
Feb 26 2018
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by pfeldman@chromium.org
, Feb 8 2018Status: Assigned (was: Unconfirmed)