Issue metadata
Sign in to add a comment
|
Cookie updates cause address field badge bubble to grow or not appear
Reported by
tarq...@vivaldi.com,
Jan 23 2018
|
||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.97 Safari/537.36 Vivaldi/1.94.1008.34 Steps to reproduce the problem: 1. Open address field badge bubble (eg. click the padlock icon) 2. Page updates a cookie's value, or the values of multiple cookies. 3. Bubble gets 1px wider for each cookie that was updated. 1 cookie = 1px. 10 cookies = 10px. 4. If enough cookies are set quickly enough, it prevents the bubble from opening at all. What is the expected behavior? Bubble should always open. Bubble width should remain constant. It should always be possible to update settings (eg. to enable Flash). What went wrong? Bubble width grows every time a cookie updates. Bubble fails to open if there are enough updates. Did this work before? N/A Chrome version: 65.0.3322.3 Channel: dev OS Version: 10.0 Flash Version: Causes some CNN pages to fail to allow the user to make changes in the bubble (eg. to enable Flash), and the width grows constantly - one jump every second (the length of their interval timer which sets the cookies).
,
Jan 31 2018
Unable to reproduce the issue on chrome version 64.0.3282.119 using Windows 10 with steps mentioned below: 1) Launched chrome reported version 2) Dragged and dropped the files provided in comment#0 and opened address field badge bubble 3) Bubble got and opeend and it size remains constant and able to enable flash @Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue. Try to test this issue by creating new profile with no extensions and apps in it and let us know if the issue still persists. Thanks!
,
Jan 31 2018
,
Jan 31 2018
I am still able to reproduce this in the reported build. I am also able to reproduce it in 66.0.3335.0 (Official Build) canary (64-bit) on Windows 10, with a clean profile. I notice that you are not using a clean profile, since yours states that it has "3 cookies", while the code only sets 1 - something else has made profile changes on your machine. It reproduces on every (Windows 10) machine where we test it. Perhaps you have disabled script or blocked various things (like JavaScript or new cookies) on file: - what happens if you load it from http, in a clean profile, with nothing disabled, and no extensions that might alter the behaviour?
,
Jan 31 2018
Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 1 2018
Able to reproduce this issue on reported version 65.0.3322.3, on latest stable 64.0.3282.119 and latest canary 66.0.3336.0 using Windows 10 with steps given in comment#0. Issue is not seen in Linux and Mac Good Build: 64.0.3270.0 Bad Build: 64.0.3271.0 You are probably looking for a change made after 516962 (known good), but no later than 516967 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/82ec39abb4cd14bd9142fc4fb5547fbdc790a637..4dc44a24bceda5612481e1528d921d883facab1d Reviewed-on: https://chromium-review.googlesource.com/771050 Suspecting same from chagelog. @patricialor: Please confirm the bug and help in re-assigning if it is not related to your change. Adding RB-Stable for M-64. Please change if not the case. Thanks!
,
Feb 1 2018
Thanks for the bug report! I think this is a duplicate of issue 795272 . The specific change that caused this has been reverted, so hopefully you shouldn't see this any more. |
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by ajha@chromium.org
, Jan 24 2018