New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 768327 link

Starred by 4 users
Status: Archived
Owner:
lgrey@chromium.org
Closed: Sep 25
Cc:
nyerramilli@chromium.org
rbasuvula@chromium.org
█ msrchandra@chromium.org
erikc...@chromium.org
█ ranjitkan@chromium.org
█ shrike@chromium.org
pkasting@chromium.org
est...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

Unwanted white strip is observed on new tab button after applying Themes

Reported by nutan.ga...@etouch.net, Sep 25 2017 
Chrome Version: 63.0.3223.0 (Official Build) 569732c0a96ec8d0c4c5df7f7012188696c7d37c-refs/heads/master@{#503964}(64-bit)

OS: MAC(10.13-TouchBar)

Step to reproduce?
1. Launch chrome, navigate to https://chrome.google.com/webstore/category/themes?utm_source=chrome-ntp-icon
2. Apply any theme e.g. ‘Flying Paint’ and observe the NTP icon

Actual - Unwanted white strip is observed on NTP icon after applying Themes
Expected -  White strip should not be observed on NTP icon
 
This is an Non-Regression issue seen form M-45

Note: Issue is not seen on Windows and Linux
Actual Video.mov
26.3 MB Download

Comment 1 by treib@chromium.org, Sep 25 2017

Components: -UI>Browser>NewTabPage UI>Browser>TabStrip

Comment 2 by msrchandra@chromium.org, Sep 25 2017

Status: Untriaged (was: Unconfirmed)
Changing the status to Untriaged, so that the issue would get addressed.
Thank You.

Comment 3 by est...@chromium.org, Sep 25 2017

Summary: Unwanted white strip is observed on new tab button after applying Themes (was: Unwanted white strip is observed on NTP icon after applying Themes)

Comment 4 by sdy@chromium.org, Sep 26 2017

Labels: -Pri-2 Hotlist-CocoaBrowser Pri-3
Owner: lgrey@chromium.org
Status: Assigned (was: Untriaged)

Comment 5 by shrike@chromium.org, Oct 2 2017

Cc: erikc...@chromium.org shrike@chromium.org
 Issue 768776  has been merged into this issue.

Comment 6 by lgrey@chromium.org, Oct 10 2017

Labels: Needs-Feedback
I can't repro this anymore. nutan.gaikwad@etouch.net is this still occurring for you?

Comment 7 by nutan.ga...@etouch.net, Oct 11 2017 

Rechecked the issue on canary #63.0.3236.0 and it is still reproducing.

Kindly check the attached Screen shot for reference.

Thank you.
Actual Result.png
3.1 MB View Download
Project Member

Comment 8 by bugdroid1@chromium.org, Oct 13 2017 

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

commit 845cd4b6ab66023581f91dac03545d7ba0c60ddb
Author: Leonard Grey <lgrey@chromium.org>
Date: Fri Oct 13 14:32:46 2017

[Mac] Use default caching for new tab button image

NSImage's default caching policy defers to the backing image representation.
In the new tab button's case, that's an NSCustomRep subclass, which has
a default caching policy of "always".

That means setting the image's policy SHOULD be a no-op, but in practice
it causes the linked bug*. This seems related to a known issue where the
new tab button won't redraw when it should (for example, setting high
contrast mode,  crbug.com/774493 ). This change fixes the immediate bug while we 
continue to investigate the issue with redrawing

* Never mind that the image gets replaced! Mysteries abound.

Bug:  768327 
Change-Id: I6873dd958a0197d8f4149f9a8e1b682a06c8498f
Reviewed-on: https://chromium-review.googlesource.com/716960
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508696}
[modify] https://crrev.com/845cd4b6ab66023581f91dac03545d7ba0c60ddb/chrome/browser/ui/cocoa/new_tab_button.mm

Comment 9 by robliao@chromium.org, Sep 25

Status: Archived (was: Assigned)
Archiving old bugs that have only received trivial updates for some time.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!
►

Sign in to add a comment