Issue metadata
Sign in to add a comment
|
Opening a New Tab Flashes Old Content Before Rendering New Content |
||||||||||||||||||||||||
Issue descriptionChrome Canary Mac 69.0.3494.0 with MacViews occasionally flashes old content when opening a new tab (see video). Both groby@ and I have run into this on different days but have not been able to find exactly how to repro this.
,
Jul 23
,
Jul 23
We don't handle RWHVMac::SetVisible(false) correctly (we keep showing content). I suspect that that is the cause of this (I've seen it too, but can't reliably reproduce it). Fix is at: https://chromium-review.googlesource.com/c/chromium/src/+/1141148
,
Jul 23
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c27876f59a3df5b19b54dccc4e59894928665f1f commit c27876f59a3df5b19b54dccc4e59894928665f1f Author: Christopher Cameron <ccameron@chromium.org> Date: Mon Jul 23 23:44:13 2018 MacViews: Fix RenderWidgetHostViewMac ui::Layer visibility Two bugs here. First bug: Interactions with calling RWHVMac::Show/Hide. With the non-unified compositor, calling RWHVMac::Show/Hide will cause the Cocoa NSView to have its show or hide method called. With the unified compositor, calls to RWHVMac::Show/Hide are largely ignored. The ui::Layer will always be visible if it has a parent ui::Layer. This is a bug -- the ui::Layer should be made visible or not based on the visibility specified by the calls to RWHVMac::Show/Hide. Second bug: Child NSViews not matching child ui::Layers It is possible for a WebContentsViewCocoa NSView to have multiple RenderWidgetHostViewCocoa NSViews. Which of these views is visible is controlled by called to RWHVMac::Show/Hide. Track the parent RenderWidgetHostViewBases that added NSViews, and iterate through all of them when updating the parent ui::Layer. Unrelated cleanup: Remove parameter from BrowserCompositorViewMac that is always false (and add a DCHECK that it is false, just for good measure). Bug: 859834 , 865227 Change-Id: I8767692443d5eb6381a8ea4b087c5c312fef305d Reviewed-on: https://chromium-review.googlesource.com/1141148 Reviewed-by: Avi Drissman <avi@chromium.org> Reviewed-by: Sidney San Martín <sdy@chromium.org> Commit-Queue: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/heads/master@{#577334} [modify] https://crrev.com/c27876f59a3df5b19b54dccc4e59894928665f1f/content/browser/renderer_host/browser_compositor_view_mac.h [modify] https://crrev.com/c27876f59a3df5b19b54dccc4e59894928665f1f/content/browser/renderer_host/browser_compositor_view_mac.mm [modify] https://crrev.com/c27876f59a3df5b19b54dccc4e59894928665f1f/content/browser/renderer_host/render_widget_host_view_mac.mm [modify] https://crrev.com/c27876f59a3df5b19b54dccc4e59894928665f1f/content/browser/web_contents/web_contents_view_mac.h [modify] https://crrev.com/c27876f59a3df5b19b54dccc4e59894928665f1f/content/browser/web_contents/web_contents_view_mac.mm
,
Jul 26
,
Jul 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c9dfbbcb39c587ec98214f7c847569ec163eaf56 commit c9dfbbcb39c587ec98214f7c847569ec163eaf56 Author: Christopher Cameron <ccameron@chromium.org> Date: Sun Jul 29 22:43:44 2018 MacViews: Fix RenderWidgetHostViewMac ui::Layer visibility Two bugs here. First bug: Interactions with calling RWHVMac::Show/Hide. With the non-unified compositor, calling RWHVMac::Show/Hide will cause the Cocoa NSView to have its show or hide method called. With the unified compositor, calls to RWHVMac::Show/Hide are largely ignored. The ui::Layer will always be visible if it has a parent ui::Layer. This is a bug -- the ui::Layer should be made visible or not based on the visibility specified by the calls to RWHVMac::Show/Hide. Second bug: Child NSViews not matching child ui::Layers It is possible for a WebContentsViewCocoa NSView to have multiple RenderWidgetHostViewCocoa NSViews. Which of these views is visible is controlled by called to RWHVMac::Show/Hide. Track the parent RenderWidgetHostViewBases that added NSViews, and iterate through all of them when updating the parent ui::Layer. Unrelated cleanup: Remove parameter from BrowserCompositorViewMac that is always false (and add a DCHECK that it is false, just for good measure). TBR=ccameron@chromium.org (cherry picked from commit c27876f59a3df5b19b54dccc4e59894928665f1f) Bug: 859834 , 865227 Change-Id: I8767692443d5eb6381a8ea4b087c5c312fef305d Reviewed-on: https://chromium-review.googlesource.com/1141148 Reviewed-by: Avi Drissman <avi@chromium.org> Reviewed-by: Sidney San Martín <sdy@chromium.org> Commit-Queue: ccameron <ccameron@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#577334} Reviewed-on: https://chromium-review.googlesource.com/1154359 Reviewed-by: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/branch-heads/3497@{#193} Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753} [modify] https://crrev.com/c9dfbbcb39c587ec98214f7c847569ec163eaf56/content/browser/renderer_host/browser_compositor_view_mac.h [modify] https://crrev.com/c9dfbbcb39c587ec98214f7c847569ec163eaf56/content/browser/renderer_host/browser_compositor_view_mac.mm [modify] https://crrev.com/c9dfbbcb39c587ec98214f7c847569ec163eaf56/content/browser/renderer_host/render_widget_host_view_mac.mm [modify] https://crrev.com/c9dfbbcb39c587ec98214f7c847569ec163eaf56/content/browser/web_contents/web_contents_view_mac.h [modify] https://crrev.com/c9dfbbcb39c587ec98214f7c847569ec163eaf56/content/browser/web_contents/web_contents_view_mac.mm
,
Aug 20
Issue 875236 has been merged into this issue. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by robliao@chromium.org
, Jul 21