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

Issue 882335 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit 18 days ago
Closed: Sep 14
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: [NTP] User is automatically navigated back to normal window from incognito window.

Reported by sanyam.g...@etouch.net, Sep 10

Issue description

Chrome Version: 71.0.3548.0 (Official Build) Revision 94235d806bd7d3be1608cd07bf5118d2cb3f3187-refs/branch-heads/3548@{#1}(32/64-bit)
OS:  Windows(7,8,8.1,10), Mac(10.12.6 , 10.13.1 , 10.13.6, 10.14) & Linux(14.04) OS

Pre-condition : Enable 'Google local NTP' & 'New Tab Page Custom Links' from chrome://flags.

Steps to reproduce:
1. Launch Chrome, navigate to NTP and click on 'Add Shortcut' to open the overlay.
2. Enter the text in 'Name' & 'URL' text-fields and click on 'Done' button to add shortcut.
3. Now, while the notification bar is still displayed ,navigate to 'New Incognito Window' from wrench menu and observe.

Actual Result  : User is navigated back to normal window from incognito window after few seconds.
Expected Result: User should stay on incognito window and focus should stay in omnibox of incognito window.

This is a Regression issue, broken in 'M-71' and below is the bisect info:
Good Build: 71.0.3543.0 (Revision: 588719)
Bad Build : 71.0.3544.0 (Revision: 589076)

You are probably looking for a change made after 588740 (known good), but no later than 588741 (first known bad).

Narrow Bisect info: 
https://chromium.googlesource.com/chromium/src/+log/212d5c5369080305b74a1bb65fab755b2dec2a72..f107e6c78054dca34047d4a029f92b9d3bff7177

Suspecting: r588741 ?

@sweilun: 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.

Kindly review the attached screen-cast for reference.

Note:
1.Providing suspect through 'chromium bisect' script because unable to perform bisect using 'per-revision' 
2.Tried performing 'per revision' bisect on multiple Windows, Mac and Linux machines but unable to perform the same since getting following error: 
(a) Error message on Windows and Linux OS : Unable to find locale data files 
(b) Error message on Mac OS:[Errno 2] No such file or directory error message.
3. Same issue is observed if a shortcut is edited.

Thank You..!!
 
Actual_Behaviour.mp4
813 KB View Download
Expected_Behaviour.mp4
1.0 MB View Download
Cc: yyushkina@chromium.org
Labels: Needs-Feedback
Status: Started (was: Assigned)
The reason for that is after the notification bar floats down we refocus on the omnibox. However, omnibox is not part of the webpage but page of the browser. So, unless you work on other applications, you will be forced to focus back to that new tab page's omnibox even when you were in the middle of something on another page. One way to fix this is that we will not focus on the omnibox after the notification bar disappear unless the user interactive any buttons on the notification bar. Like clicking or hitting enter on "Undo" OR "Restore". wdyt?
Cc: ramyan@chromium.org
Is this platform-specific? I couldn't replicate it on 71.0.3550.0 / Mac.
Yes, I believe so. I can't reproduce on my Mac either, but it is reproducible on Linux.
Labels: -OS-Mac
Thanks! Removing Mac label. Let's check if it occurs on Windows too.

Also, is there anything specific with incognito windows here, or does this happen with any window?
This will happen with any window as long as it's not the same window as the one with the float bar. This change also introduce a weird behavior on  crbug.com/883228 .
Regarding comment #1: I think it makes sense to apply focus after the notification toast pops up if the current tab is active, regardless of whether the user has interacted with any items on the notifications toast. If they've interacted with the notification, focus moves immediately anyway, so they wouldn't get into the scenario with this incognito window (I think!).
Update: This will also happen on Windows.
Cc: sweilun@chromium.org
 Issue 883228  has been merged into this issue.
@c7: this wouldn't fix the disruption to a user typing text somewhere else like in  crbug.com/883228 . I think we should probably just do as Weilun suggest in c1.
@c10: That's fair. It'll just mean that there's only a partial fix for  crbug.com/873978 .
Yep, agreed.
Project Member

Comment 13 by bugdroid1@chromium.org, Sep 14

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

commit 4c56a2e09b12195ce4a9e4eb6b592d089941c008
Author: Weilun Shi <sweilun@chromium.org>
Date: Fri Sep 14 00:43:45 2018

[NTP] Refocus on omnibox only when user clicks the undo/restore button

Refocusing on the omnibox only when user clicks any buttons on the
notification bar. In that way, we can make sure that the user is
interacting with that new tab. Bluring the buttons on the notification
bar if user don't do anything to make sure we will not focus on the
hidden item.

Bug:  882335 
Change-Id: I2310e1318764f8cae77ce59155164cbf14233324
Reviewed-on: https://chromium-review.googlesource.com/1222871
Commit-Queue: Weilun Shi <sweilun@chromium.org>
Reviewed-by: Kristi Park <kristipark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591235}
[modify] https://crrev.com/4c56a2e09b12195ce4a9e4eb6b592d089941c008/chrome/browser/resources/local_ntp/local_ntp.js

Status: Fixed (was: Started)
Labels: TE-Verified-M71 TE-Verified-71.0.3554.0
Update :
---------
Tested above issue in Canary build #71.0.3554.0 on Windows(7, 8, 8.1, 10), Linux(14.04 LTS) OS and the issue is fixed. 
Hence adding TE-Verified labels. Kindly review an attached screen-cast for reference.
Thank You.
Fixed_Behaviour.mp4
875 KB View Download
Labels: SupportedInRemoteNTP

Sign in to add a comment