Unable to confirm alert
Reported by
joris.wi...@winfakt.com,
Mar 20 2018
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36 Steps to reproduce the problem: 1. Open site in new window, receive alert ( example Do you wish to refresh? ) 2. Open new window, receive a alert window 3. Unable to close the alert window, OK won't work 4. Cancel or OK the first confirmbox 5 Now I am able to to close the alert What is the expected behavior? Alerts should be closed whether there are other unconfirmed message on other windows What went wrong? I should be able to close the alert without closing the confirm on the other window Did this work before? Yes Chrome version: 65.0.3325.162 Channel: stable OS Version: OS X 10.12.6 Flash Version:
,
Mar 21 2018
,
Mar 21 2018
,
Mar 21 2018
Able to reproduce this on reported version 65.0.3325.162 and latest stable 65.0.3325.181. But issue is not seen in latest beta 66.0.3359.33 and latest canary 67.0.3376.1 using Mac 10.13.3. Issue is not applicable to Linux and Windows. Tested with https://lab.devzone.co.in/confirmation-box-using-javascript/ and https://www.w3schools.com/js/tryit.asp?filename=tryjs_alert URLS Observations: 1. 65.0.3325.0 to 65.0.3325.36 -- Good Build 2. 65.0.3325.39 to 65.0.3325.181 -- Bad Build 3. 66.0.3326.0 to 66.0.3359.33 -- Good Build 4. 67.0.3376.1 -- Good Build. Hence providing manual bisect info for 65.0.3325.36 and 66.0.3325.39 CL: https://chromium.googlesource.com/chromium/src/+log/65.0.3325.36..65.0.3325.39?pretty=fuller&n=10000 Suspecting https://chromium-review.googlesource.com/c/chromium/src/+/896503 or https://chromium-review.googlesource.com/c/chromium/src/+/896390 from changelog. @bsep:Please confirm the bug and help in re-assigning if it is not related to your change. Adding RB-Stable for M-65. Please remove if not the case. Thanks!
,
Mar 21 2018
,
Mar 21 2018
It's not me but it's probably Harmony-related. Mac folks: is this because Harmony is only partially launched on M65?
,
Mar 21 2018
Given M65 has been out since 03/06, we're not planning to block M65 further roll out for this. Pls let us know ASAP if there is any concern here. Thank you.
,
Mar 21 2018
Since it's fixed for M66, I don't think there's any action here then. We're not going to respin 65 for this.
,
Mar 21 2018
Yeah - Harmony probably *fixed* this bug \o/. The bisect goes forward from m65, but doesn't go backwards - I think a bisect in that direction will find that this is *not* a regression. Note the javascript dialog that appears in the screencast is the old one -- not Harmony.
,
Mar 22 2018
As per comment#10 bisected backwards and found this as Non-Regression issue. Observations: 1. From M60 to M64 last build -- 64.0.3282.186 -- Bad Build 2. From M65 first build i.e 65.0.3284.0 -- Good behavior is seen. Hence considering this as Non-Regression removing Needs-Bisect label. Please feel free to add for any further triaging. Thanks!
,
Mar 22 2018
Thanks for the update! I think we can call this fixed in m66, so no further action is required.
,
Mar 22 2018
[Auto-generated comment by a script] We noticed that this issue is targeted for M-65; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-65 label, otherwise remove Merge-TBD label. Thanks.
,
Mar 22 2018
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by susan.boorgula@chromium.org
, Mar 20 2018