Issue metadata
Sign in to add a comment
|
Regression: [MAC]Sign In to Chrome overlay and devtools panel is seen blank.
Reported by
aiman.an...@etouch.net,
May 23 2018
|
||||||||||||||||||||||
Issue descriptionChrome version: 68.0.3438.0 (Official Build) Revision 92f33534f404595554fb708537b29568da70f384-refs/branch-heads/3438@{#1} (64-bit) OS: Mac(10.12.6, 10.13.1, 10.13.5). Pre-Condiiton: Enable 'Use Views browser windows instead of Cocoa' flag from chrome://flags and relaunch the browser. Steps to reproduce: 1. Launch chrome, click on Avatar icon in omnibox and click on 'Sign in to Chrome' button. 2. Observe Sign-In to chrome overlay. Note: Also, Open Devtools on NTP and observe Devtools panel (Devtools panel is seen blank) Actual Result: Sign In to Chrome overlay is seen blank. Expected Result: Sign In to chrome overlay should not be seen blank. This is a regression issue, broken in 'M-68', and below is the bisect provided using per-revision script. Good Build:68.0.3437.0 (Revision:560454) Bad Build: 68.0.3438.0 (Revision:560883) You are probably looking for a change made after 560679 (known good), but no later than 560680 (first known bad). CHANGE-LOG URL: 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/e0042c0f1b632e43b9f5343822bbdf1294fc6d1c..200d56fbfb923ba7fb14d7374e198ebea272fbf6 Suspect: https://chromium.googlesource.com/chromium/src/+/200d56fbfb923ba7fb14d7374e198ebea272fbf6 @ccameron: Could you please help to reassign if your change is not the cause for this change. Note: 1.Issue is MAC OS specific and is not reproducible on Win(7,8,8.1,10), Linux(14.04 LTS) OS 2.On Mac Touchbar (10.13.5), the whole screen turns blank.
,
May 23 2018
Yep, definite RBS for this and maybe even RBB.
,
May 23 2018
Marking it as 'RBB'.
,
May 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b0c7ed414b3184e22efa85938ebf15c7271d9ee5 commit b0c7ed414b3184e22efa85938ebf15c7271d9ee5 Author: Christopher Cameron <ccameron@chromium.org> Date: Wed May 23 19:41:05 2018 MacViews: Disable embedding RWHVMac in browser UI's compositor Bug: 845807 , 840173 , 846018 Change-Id: I97768c5c2085f8e1f29371bfedff5aaeebc956fa Reviewed-on: https://chromium-review.googlesource.com/1070464 Commit-Queue: ccameron <ccameron@chromium.org> Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org> Reviewed-by: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/heads/master@{#561210} [modify] https://crrev.com/b0c7ed414b3184e22efa85938ebf15c7271d9ee5/content/browser/renderer_host/render_widget_host_view_mac.mm
,
May 24 2018
Update : Retested above issue in latest Canary build # 68.0.3439.0 on Mac(10.12.6, 10.13.1, 10.13.5) and the issue is fixed. Now, Sign-In overlay and dev-tools panel is seen properly and is not blank. Kindly review an attached screen-cast. Thank you..!
,
May 25 2018
,
May 25 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6f4d713f35161bc425b1032956e2b12fdd5f639f commit 6f4d713f35161bc425b1032956e2b12fdd5f639f Author: Christopher Cameron <ccameron@chromium.org> Date: Fri May 25 01:05:23 2018 MacViews: Re-enable single ui::Compositor view Decide at initialization whether or not a RenderWidgetHostViewMac will be displayed in its NSView or through a ui::Compositor. This fixes a bug whereby some windows (DevTools is a good example) would, through the vagaries of initialization order, draw a single frame to the NSView, which would then never go away, and cover up the ui::Compositor's version of the content (which was then updating correctly, though not visible). Bug: 840173 , 845807 Change-Id: If051d249956b10c9e56450ed1f58b9048d331562 Reviewed-on: https://chromium-review.googlesource.com/1070764 Commit-Queue: ccameron <ccameron@chromium.org> Reviewed-by: Sidney San Martín <sdy@chromium.org> Cr-Commit-Position: refs/heads/master@{#561717} [modify] https://crrev.com/6f4d713f35161bc425b1032956e2b12fdd5f639f/content/browser/renderer_host/render_widget_host_view_mac.h [modify] https://crrev.com/6f4d713f35161bc425b1032956e2b12fdd5f639f/content/browser/renderer_host/render_widget_host_view_mac.mm
,
May 25 2018
Update : Rechecked the above issue on Mac OS X(10.12.6,10.13.1,10.13.5) OS using latest Canary Chrome version : 68.0.3440.0 and the issue is fixed.Kindly refer the attached screen cast for reference.
,
May 25 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ad0e8656343a663932a696f128b5bc85df530cac commit ad0e8656343a663932a696f128b5bc85df530cac Author: Fady Samuel <fsamuel@chromium.org> Date: Fri May 25 13:49:14 2018 Revert "MacViews: Re-enable single ui::Compositor view" This reverts commit 6f4d713f35161bc425b1032956e2b12fdd5f639f. Reason for revert: This seems to have caused https://crbug.com/846691 Original change's description: > MacViews: Re-enable single ui::Compositor view > > Decide at initialization whether or not a RenderWidgetHostViewMac will > be displayed in its NSView or through a ui::Compositor. > > This fixes a bug whereby some windows (DevTools is a good example) > would, through the vagaries of initialization order, draw a single > frame to the NSView, which would then never go away, and cover up the > ui::Compositor's version of the content (which was then updating > correctly, though not visible). > > Bug: 840173 , 845807 > Change-Id: If051d249956b10c9e56450ed1f58b9048d331562 > Reviewed-on: https://chromium-review.googlesource.com/1070764 > Commit-Queue: ccameron <ccameron@chromium.org> > Reviewed-by: Sidney San Martín <sdy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#561717} TBR=ccameron@chromium.org,sdy@chromium.org Change-Id: Ic25ee96c567c3531d91ec5431f10d15d34bfee82 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 840173 , 845807 Reviewed-on: https://chromium-review.googlesource.com/1073089 Reviewed-by: Fady Samuel <fsamuel@chromium.org> Commit-Queue: Fady Samuel <fsamuel@chromium.org> Cr-Commit-Position: refs/heads/master@{#561850} [modify] https://crrev.com/ad0e8656343a663932a696f128b5bc85df530cac/content/browser/renderer_host/render_widget_host_view_mac.h [modify] https://crrev.com/ad0e8656343a663932a696f128b5bc85df530cac/content/browser/renderer_host/render_widget_host_view_mac.mm
,
May 31 2018
Please note this is marked as RB-Beta, and M68 Beta promotion is a week away.
,
Jun 3 2018
,
Jun 3 2018
[Auto-generated comment by a script] We noticed that this issue is targeted for M-68; 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-68 label, otherwise remove Merge-TBD label. Thanks.
,
Jun 4 2018
Re-opening and merge-requesting 68.
,
Jun 4 2018
,
Jun 4 2018
Approved - branch:3440
,
Jun 4 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e9942645e816b8f50f7f5e11b4194f850a522bd7 commit e9942645e816b8f50f7f5e11b4194f850a522bd7 Author: Christopher Cameron <ccameron@chromium.org> Date: Mon Jun 04 21:10:37 2018 Revert "MacViews: Re-enable single ui::Compositor view" This reverts commit 6f4d713f35161bc425b1032956e2b12fdd5f639f. Reason for revert: This seems to have caused https://crbug.com/846691 Original change's description: > MacViews: Re-enable single ui::Compositor view > > Decide at initialization whether or not a RenderWidgetHostViewMac will > be displayed in its NSView or through a ui::Compositor. > > This fixes a bug whereby some windows (DevTools is a good example) > would, through the vagaries of initialization order, draw a single > frame to the NSView, which would then never go away, and cover up the > ui::Compositor's version of the content (which was then updating > correctly, though not visible). > > Bug: 840173 , 845807 > Change-Id: If051d249956b10c9e56450ed1f58b9048d331562 > Reviewed-on: https://chromium-review.googlesource.com/1070764 > Commit-Queue: ccameron <ccameron@chromium.org> > Reviewed-by: Sidney San Martín <sdy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#561717} TBR=ccameron@chromium.org, fsamuel@chromium.org, sdy@chromium.org (cherry picked from commit ad0e8656343a663932a696f128b5bc85df530cac) Change-Id: Ic25ee96c567c3531d91ec5431f10d15d34bfee82 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 840173 , 845807 Reviewed-on: https://chromium-review.googlesource.com/1073089 Reviewed-by: Fady Samuel <fsamuel@chromium.org> Commit-Queue: Fady Samuel <fsamuel@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#561850} Reviewed-on: https://chromium-review.googlesource.com/1085866 Reviewed-by: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/branch-heads/3440@{#169} Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733} [modify] https://crrev.com/e9942645e816b8f50f7f5e11b4194f850a522bd7/content/browser/renderer_host/render_widget_host_view_mac.h [modify] https://crrev.com/e9942645e816b8f50f7f5e11b4194f850a522bd7/content/browser/renderer_host/render_widget_host_view_mac.mm
,
Jun 4 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4e92c669455bee60be035a0b9b849644cc88fa0a commit 4e92c669455bee60be035a0b9b849644cc88fa0a Author: Christopher Cameron <ccameron@chromium.org> Date: Mon Jun 04 21:16:33 2018 Fix Cast dialog not appearing on non-MacViews Resize the ui::Compositor's size in BrowserCompositorMac's SynchronizeVisualProperties method. Re-disable using a unified ui::Compositor (it was accidentally enabled by a botched merge). Bug: 840173 Change-Id: I701574e385ae288b991adce81e1ab5efde23e0c2 Reviewed-on: https://chromium-review.googlesource.com/1073682 Reviewed-by: Fady Samuel <fsamuel@chromium.org> Commit-Queue: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/heads/master@{#562047} (cherry picked from commit e28df26f9442362f169e55d9a82fc7cb59208bd1) Merged for TBR=ccameron@chromium.org Bug: 845807 Change-Id: Ic2515fcf91ecdc25de05ab36f7d89bd17fa37bbf Reviewed-on: https://chromium-review.googlesource.com/1086119 Reviewed-by: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/branch-heads/3440@{#170} Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733} [modify] https://crrev.com/4e92c669455bee60be035a0b9b849644cc88fa0a/content/browser/renderer_host/browser_compositor_view_mac.mm [modify] https://crrev.com/4e92c669455bee60be035a0b9b849644cc88fa0a/content/browser/renderer_host/render_widget_host_view_mac.mm
,
Jun 4 2018
This should be fixed on 68 now.
,
Jun 5 2018
Update: Retested above issue on Mac(10.12.6, 10.13.1, 10.13.6) OS using latest Dev #68.0.3440.15 and issue is fixed. Now, Sign-In to chrome overlay and DevTools window is seen properly and is not blank. Kindly refer the attached screen-cast for reference. Thank you..! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by nyerramilli@chromium.org
, May 23 2018Labels: ReleaseBlock-Stable