New issue
Advanced search Search tips

Issue 719230 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Navigating away from a page with a dark background is flashing the new page with that dark background

Project Member Reported by meh...@chromium.org, May 7 2017

Issue description

Chrome Version: 60.0.3091.0 Canary
OS: MacOS 10.12.4

What steps will reproduce the problem?
(1) go to a page with a dark background, eg. https://www.theverge.com/
(2) press CMD-T to open the NewTabPage or press ALT-CMD to open the Bookmarks Manager

What is the expected result? What happens instead?
The new tab that is opening is flashing with the dark background before it renders.

Please use labels and text to provide additional information.
This is a regression. Please find a screencast attached.


 
screencast.mov
1.2 MB Download
correction step 2: ... or press ALT-CMD-B to ...
Cc: chrishtr@chromium.org
This was done intentionally in https://codereview.chromium.org/2466413009.

IMO this isn't the right solution -- we should draw, in order of availability
- the current page content
- the current page background color (not the previous page background color)
- the theme color
Attaching a video of an example of this issue. We have a dark theme, and a white tab open.

We open a new tab, and the tab is white for a while as the new tab page loads.

chrishtr, any objections to me disabling this behavior on Mac?

Note that Mac has the theme color correctly plumbed through, so we can use that instead.
wrong-color.mov
774 KB Download
When opening a new tab to the NTP, if the theme background is
already available, then yes it makes sense to use it instead
of the previous page's background color. Not for navigating
between sites though, since we don't know what the color of
the new site will be.

This should be done for all platforms also.
Labels: -Needs-Bisect hasbisect-per-revision M-60
Owner: ccameron@chromium.org
Status: Assigned (was: Untriaged)
Able to reproduce the issue on Mac-10.12.4 using chrome canary 60.0.3091.0 with the steps provided in comment#0.This is regression issue,broken in M60.

Using the per-revision bisect providing the bisect results,
Good build:60.0.3073.0 (Revision:464873).
Bad build: 60.0.3074.0 (Revision:465085).
CHANGE-LOG URL:
https://chromium.googlesource.com/chromium/src/+log/57d77a1786e9b7a6c7a86a6d8f9f0d914e317cd4..e1979f60524da9dab9d8cc19a23910f8d5dcf180

Review-Url: https://codereview.chromium.org/2824613002
ccameron@ Could you please look into this issue, help us to assign this issue to the right owner.

Note:Issue is specific to Mac.

Thanks.
Labels: OS-Chrome OS-Linux OS-Windows
Re #4, this bug is filed specifically against navigation, and I'm not convinced that this is the right thing to do for navigation.

That said, since we agree about new tabs (and since I find that more jarring), I'll put that code in a #if !defined(OS_MACOSX), saying "needs to be done on Aura too".

Have we looked at initializing the background color correctly from the theme in Aura?
Project Member

Comment 7 by bugdroid1@chromium.org, May 10 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/39db31b0859157dc9848bb25181d50b553a72ddf

commit 39db31b0859157dc9848bb25181d50b553a72ddf
Author: ccameron <ccameron@chromium.org>
Date: Wed May 10 06:59:58 2017

mac: Don't transfer background color to new tabs

New tabs should be created with the NTP background color, which is what
happens on Mac.

On Aura, this doesn't happen, and the workaround is to open the new tab
with the color from the previous page.

This workaround has no place on Mac, so disable it.

BUG=719230

Review-Url: https://codereview.chromium.org/2869063002
Cr-Commit-Position: refs/heads/master@{#470509}

[modify] https://crrev.com/39db31b0859157dc9848bb25181d50b553a72ddf/chrome/browser/ui/browser.cc
[modify] https://crrev.com/39db31b0859157dc9848bb25181d50b553a72ddf/chrome/browser/ui/browser_unittest.cc

Cc: sky@chromium.org
Components: UI>Browser>TabContents
Labels: -OS-Mac
Owner: ----
Status: Available (was: Assigned)
The Mac part for new tab is done.

For navigation, it's a moot point for now because Aura needs to do that.

Marking as -Mac and Available -- next step is for someone to take on sending the theme color to the RenderWidgetHostView (or WebContentsView) in Aura as well.
Project Member

Comment 9 by sheriffbot@chromium.org, May 10 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
I can confirm that the issue is fixed for macOS (see comment #8).

Not sure, if this is still an issue on the other platforms? Unfortunatly I have no other OS'es to test it.
Cc: susan.boorgula@chromium.org
 Issue 910697  has been merged into this issue.
This is still an issue.  Issue 910697  has repro in php.
I noticed that, if you open a link that has 'target' set to '_blank', it properly shows through the background color of the theme. For example, in incognito mode in Windows, the background is dark gray until the page loads, as it should be.

Still, if you switch to another page and back, the background does become the one of the previous tab.

In every other case (like opening in the background or using a shortcut) it seems the issue still happens.

Sign in to add a comment