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

Issue 817751 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
OOO Jan 14 - 25
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Regression: Black background is observed on 'default ntp' in incognito.

Reported by shruti.j...@etouch.net, Mar 1 2018

Issue description

Chrome Version: 66.0.3357.0 (Official Build) Revision 837639b937d3d1a084c246258ad1f460e4f0f68e-refs/heads/master@{#539659} (32/64-bit)

OS: Windows(7,8,8.1,10),MAC(10.12.6,10.13.1,10.13.4) and Linux(14.04 LTS).

Test URL:https://chrome.google.com/webstore/detail/google-arts-culture/akimgimeeoiognljlfchpbkpfbmeapkh?utm_source=chrome-ntp-icon

Steps to reproduce:
(1)Launch chrome and navigate to above URL and download the extension.
(2)Click on options and and select 'in every new tab' and enable all the options 'show apps button','show default new tab button','show top sites button'.
(3)Enable this extension in incognito. 
(4)Click on 'default new tab' visible on webpage and observe.

Actual Result:Black background is observed on google('default new tab') page in incognito.
Expected Result:Black background should not be observed on google('default new tab') page in incognito.

This is a regression issue broken in ‘M-65’ and using per-revision bisect providing the bisect results,

Good Build:65.0.3287.0(Revision:522297) 
 
Bad Build:65.0.3288.0(Revision:522666)

You are probably looking for a change made after 522427 (known good), but no later than 522428 (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/034134229bfcfe39482304614c615b826979d822..773623d293ed991e20596c4cb00e58610af5f395

Suspect:https://chromium.googlesource.com/chromium/src/+/773623d293ed991e20596c4cb00e58610af5f395

@Marc Treib : 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:
1.This issue is not reproducible on M-65 Beta (build # 65.0.3325.106) but it is reproducible on M-66 Dev(build # 66.0.3355.0).
Please refer the attached screen-cast for your reference.

Thank You!


 
Actual.mp4
1.2 MB View Download
Expected.mp4
1.6 MB View Download

Comment 1 by treib@chromium.org, Mar 1 2018

Cc: treib@chromium.org
Components: UI>Browser>NewTabPage
Labels: -Pri-1 Pri-3
Owner: ramyan@chromium.org
Hm, it's possible that that CL somehow affected this, but this is completely broken anyway, before or after. What happens is:
That extension doesn't actually link to the "default NTP", it links to "chrome-search://local-ntp/local-ntp.html", i.e. Chrome's local NTP. That isn't supported in Incognito, which has its own separate NTP. Note how the NTP is broken (in both "expected" and "actual"): There are no tiles, and the searchbox doesn't work.

So this is certainly not a P1, and arguably not even a regression. At least the broken dark NTP looks a bit more similar to the incognito NTP than the broken white NTP :D

Over to the new NTP owner for consideration, but I think this is WontFix. Maybe we could not even instantiate LocalNtpSource for incognito profiles, to make it more obvious to extension authors that they're doing something broken?
Labels: zine-triaged
Labels: -Target-65 -Target-66
Owner: yyushkina@chromium.org
This still occurs in M69. It seems like "Default new tab" in Incognito mode should reveal the Incognito tab, and not the Local NTP, as Marc points out in comment 1.

+Yana to help define behavior.


Does this mean that we'd essentially be ignoring the user's setting of "use in Incognito"?
Owner: ramyan@chromium.org
Cc: yyushkina@chromium.org ramyan@chromium.org

Sign in to add a comment