Issue metadata
Sign in to add a comment
|
when the code inspector is open, if you once again request to show the element on the page, a white window will appear
Reported by
prestige...@gmail.com,
Jan 3
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3642.0 Safari/537.36 Steps to reproduce the problem: 1. open inspector - on element 2. minimize the window with the inspector (icon _ in Windows) 3. again we request on the page to inspect the item 4. a white window opens What is the expected behavior? expect to open an already open console with an inspector What went wrong? an additional white window opens instead of the already open inspector (this behavior is noticed from version 69) Did this work before? Yes 68 Chrome version: 73.0.3642.0 Channel: dev OS Version: 10.0 Flash Version: capture screen with playback bug https://www.useloom.com/share/69943ebd1b4b4836a5dd532180f953e5
,
Jan 4
Able to reproduce the issue on reported chrome 73.0.3642.0 however issue seems to be fixed in latest chrome canary 73.0.3660.0 using Windows 10 with steps mentioned in comment# 0. Note: As we getting error while running tool bisect,hence providing Manual change log form https://omahaproxy.appspot.com/ and issue is not seen on Mac and Ubuntu. Reverse Bisect Info: ================ Bad build: 73.0.3644.0 Good build: 73.0.3645.0 CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/73.0.3644.0..73.0.3645.0?pretty=fuller&n=10000 As we are unable to find the correct suspect form the above change log.Hence marking it as Untriaged and requesting Dev for finding the correct suspect from the above change log and adding RBS to M-72 if not required feel free to remove it. Thanks..!
,
Jan 7
Friendly ping! Some one from Platform>DevTools dev team could you please provide any update on this issue as it has been marked as a stable blocker. Thank You!
,
Jan 7
The issue exists on Beta (72.0.3626.28) and Dev (73.0.3642.0) but doesn't exist on Canary (73.0.3664.0). Start investigating on which commit fixed the bug.
,
Jan 8
This is related to how Chromium restores minimized windows on Windows.
Bisecting on Windows gives me the range 617580 (last bad) - 617588 (first good)
Judging by commit messages, it was commit 617581 that addressed the bug, but rebuilding on Windows is slow so I didn't verify it.
Canary: 73.0.3665.0, commit 620590
73.0.3645.0, commit 617713 (Good build per comment #2)
commit 617581 (this commit)
Dev: 73.0.3642.0, commit 616996
Beta: 72.0.3626.28, commit 612437
73.0.3644.0, commit 617389 (Bad build per comment #2)
Stable: 71.0.3578.98, commit 599034
,
Jan 8
Rebuilding Chromium at commit 617581 on Windows..
,
Jan 9
Can confirm commit 617581 fixed this bug on Windows.
,
Jan 9
,
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 15
Unable to reproduce the issue on Win 10 / 64 bit - 73.0.3672.0 [Canary Build] & 72.0.3626.53 [Beta Build]. hhli@, could you pls change/adjust the status accordingly ?
,
Jan 17
(5 days ago)
Removing the stable blocker label for M72 as this is no longer reproducible on latest M72 beta build # 72.0.3626.64 - Win10/64 bit
,
Jan 18
(4 days ago)
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by swarnasree.mukkala@chromium.org
, Jan 3