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

Issue 655857 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Notification actions don't bring Chrome to the foreground

Project Member Reported by sdy@chromium.org, Oct 14 2016

Issue description

Version: 54.0.2840.59
OS: Linux (Windows needs to be tested)

What steps will reproduce the problem?
(1) Go to any website (e.g. google.com) and trigger a notification by running this code in the JS console (click "allow" if prompted):
Notification.requestPermission().then(() => { (new Notification('foo')).onclick = () => window.focus(); });
(2) Bring another application's window in front of Chrome.
(3) Click the settings (gear) button in the notification, OR click the body of the notification.

What is the expected output?
Chrome comes to the foreground and shows the settings page, or the page which sent the notification (depending on whether you clicked the gear or the notification body).

What do you see instead?
The right page appears within Chrome, but the Chrome window doesn't come to the front/Chrome doesn't activate.

This was a very recent Mac regression ( issue 655443 ), but it repros on Linux stable. I'm unsure if it's a regression there, and haven't tested on Windows yet.
 

Comment 1 by sdy@chromium.org, Oct 14 2016

Summary: Notification actions don't bring Chrome to the foreground (was: Clicking "settings" on a notification doesn't bring Chrome to the foreground)

Comment 2 by sdy@chromium.org, Oct 14 2016

Description: Show this description

Comment 3 Deleted

Owner: thomasanderson@chromium.org
Status: Assigned (was: Available)
Able to reproduce the issue on Linux Ubuntu 14.04 using chrome version 54.0.2840.59 and it is working fine on chrome version 56.0.2890.0.
Please find the reverse bisect information as below

Good:: 55.0.2841.0  -- (Official build revision  414854)
Bad:: 54.0.2840.67  -- (Official build revision  414607)

Change Log::
https://chromium.googlesource.com/chromium/src/+log/03fe53dc4730038b5d13613fcbad10fc9a204c54..3b6aeffa075816129e32e57412b1c89ba619df10

Possible suspect::
https://chromium.googlesource.com/chromium/src/+/3b6aeffa075816129e32e57412b1c89ba619df10

thomasanderson@ could you check and merge this to M54 if it is a valid candidate to merge.

Note :: This is working fine on Windows 7 using chrome version 54.0.2840.59
Thanks,
Labels: pre-stable-54.0.2840.59 hasbisect-per-revision
#4 I can confirm that CL would fix the issue.
However, I'd be afraid to merge since that CL touches a lot of things.

Does this need to be Pri-1?  AFAIK this issue must have existed for years on desktop Linux.  Maybe we can settle for a selective merge?
Status: WontFix (was: Assigned)
Setting to WontFix because the fix should roll out in M55.

Sign in to add a comment