Issue metadata
Sign in to add a comment
|
Regression:Unable to select file as file selection overlay closes unexpectedly after adding Capturecast chrome extension
Reported by
vineetha...@etouch.net,
Apr 13 2018
|
||||||||||||||||||||||
Issue descriptionChrome Version: 67.0.3396.0 (Official Build) Revision 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}(64 bit) OS: Mac(10.12.6,10.13.1), 10.13.4(Macbook Pro Touchbar) URL: https://chrome.google.com/webstore/detail/capturecast-chrome-screen/dmhhfoemgdlphenmfoicajbakonjcgee What steps will reproduce the problem? (1) Launch Chrome, navigate to above URL and add Capturecast chrome extension. (2) Click on the Capturecast extension icon near the omnibox to open the extension overlay. (3) Click on the 'Manage Media' tab and click on the 'Browse' button and observe. Actual Result: File selection overlay opens but does not stay, hence unable to browse for a file. Expected Result: File selection overlay should stay open so that file browsing is possible. This is regression issue broken in ‘M-67’ and providing the bisect using per-revision bisect, Good build: 67.0.3385.0(Revision: 547350) Bad build: 67.0.3386.0(Revision: 547395) The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/cce7668a987c08d515f8ab0d7996d4ea40d6d2de..902d73ba5f92c7f10ea8c07e5839a7143b28d107 Suspect: https://chromium.googlesource.com/chromium/src/+/902d73ba5f92c7f10ea8c07e5839a7143b28d107 @robliao: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: The issue is not seen Windows(7,8,8.1,10) and Linux(14.04) OS. Thank You!
,
Apr 16 2018
Pls land the change to trunk and request a merge to M67 ASAP. Thank you.
,
Apr 17 2018
,
Apr 17 2018
Prerequest for https://chromium-review.googlesource.com/c/chromium/src/+/1015181
,
Apr 17 2018
Approving merge for CL listed at #4 to M67 branch 3396. Pls merge once cl lands. Thank you.
,
Apr 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f58eccdd24c115ab1f70e310c3823880cdad04a8 commit f58eccdd24c115ab1f70e310c3823880cdad04a8 Author: Robert Liao <robliao@chromium.org> Date: Tue Apr 17 20:03:48 2018 Revert "Adjust ExtensionPopup Dismissal Behavior" This reverts commit 902d73ba5f92c7f10ea8c07e5839a7143b28d107. Reason for revert: This causes the ExtensionPopup to dismiss if it brings up a child dialog. See http://crbug.com/832623 Fixing this will require adding support to check for descendant NativeWidget activation, which is too big to merge. Original change's description: > Adjust ExtensionPopup Dismissal Behavior > > Before, dismissing the ExtensionPopup when the anchor window received > focus was an arbitrary decision ( http://crbug.com/179786 ) that allowed > the ExtensionPopup to dismiss at most of the right times. However, if > the some other top-level window received activation, the ExtensionPopup > would not dismiss, unlike a typical menu. > > This change adjusts the ExtensionPopup to always dismiss when it loses > activation as long as devtools is not attached. > > When devtools is detached, activation is placed back on the > ExtensionPopup so that the normal dismissal behavior can continue to > work. Failure to receive activation means the ExtensionPopup will not > dismiss until it receives activation at least once. > > BUG=825867 > > Change-Id: I802af281616c66013c370e892953ad2805533728 > Reviewed-on: https://chromium-review.googlesource.com/984404 > Reviewed-by: Scott Violet <sky@chromium.org> > Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org> > Commit-Queue: Robert Liao <robliao@chromium.org> > Cr-Commit-Position: refs/heads/master@{#547391} TBR=ellyjones@chromium.org,sky@chromium.org,robliao@chromium.org,rdevlin.cronin@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 825867, 832623 Change-Id: I69678b789fdbc56501e67b62dd41467e5f2f8cc9 Reviewed-on: https://chromium-review.googlesource.com/1015181 Commit-Queue: Robert Liao <robliao@chromium.org> Reviewed-by: Robert Liao <robliao@chromium.org> Cr-Commit-Position: refs/heads/master@{#551444} [modify] https://crrev.com/f58eccdd24c115ab1f70e310c3823880cdad04a8/chrome/browser/ui/cocoa/extensions/extension_popup_views_mac.mm [modify] https://crrev.com/f58eccdd24c115ab1f70e310c3823880cdad04a8/chrome/browser/ui/views/extensions/extension_popup.cc
,
Apr 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/51623832b41997874faf9ee68e9f0430f58e69e9 commit 51623832b41997874faf9ee68e9f0430f58e69e9 Author: Robert Liao <robliao@chromium.org> Date: Tue Apr 17 20:07:48 2018 Revert "Adjust ExtensionPopup Dismissal Behavior" This reverts commit 902d73ba5f92c7f10ea8c07e5839a7143b28d107. Reason for revert: This causes the ExtensionPopup to dismiss if it brings up a child dialog. See http://crbug.com/832623 Fixing this will require adding support to check for descendant NativeWidget activation, which is too big to merge. Original change's description: > Adjust ExtensionPopup Dismissal Behavior > > Before, dismissing the ExtensionPopup when the anchor window received > focus was an arbitrary decision ( http://crbug.com/179786 ) that allowed > the ExtensionPopup to dismiss at most of the right times. However, if > the some other top-level window received activation, the ExtensionPopup > would not dismiss, unlike a typical menu. > > This change adjusts the ExtensionPopup to always dismiss when it loses > activation as long as devtools is not attached. > > When devtools is detached, activation is placed back on the > ExtensionPopup so that the normal dismissal behavior can continue to > work. Failure to receive activation means the ExtensionPopup will not > dismiss until it receives activation at least once. > > BUG=825867 > > Change-Id: I802af281616c66013c370e892953ad2805533728 > Reviewed-on: https://chromium-review.googlesource.com/984404 > Reviewed-by: Scott Violet <sky@chromium.org> > Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org> > Commit-Queue: Robert Liao <robliao@chromium.org> > Cr-Commit-Position: refs/heads/master@{#547391} TBR=ellyjones@chromium.org,sky@chromium.org,robliao@chromium.org,rdevlin.cronin@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 832623 Change-Id: I69678b789fdbc56501e67b62dd41467e5f2f8cc9 Reviewed-on: https://chromium-review.googlesource.com/1015181 Commit-Queue: Robert Liao <robliao@chromium.org> Reviewed-by: Robert Liao <robliao@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#551444}(cherry picked from commit f58eccdd24c115ab1f70e310c3823880cdad04a8) Reviewed-on: https://chromium-review.googlesource.com/1015723 Cr-Commit-Position: refs/branch-heads/3396@{#58} Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428} [modify] https://crrev.com/51623832b41997874faf9ee68e9f0430f58e69e9/chrome/browser/ui/cocoa/extensions/extension_popup_views_mac.mm [modify] https://crrev.com/51623832b41997874faf9ee68e9f0430f58e69e9/chrome/browser/ui/views/extensions/extension_popup.cc
,
Apr 17 2018
,
Apr 18 2018
Update : Rechecked the above issue on Mac(10.12.6, 10.13.1), Macbook Pro Touchbar(10.13.5) OS with latest Dev Chrome version #67.0.3396.10 and the issue is fixed. Kindly refer the attached screen cast. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by robliao@chromium.org
, Apr 16 2018