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

Issue 654441 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Chrome no longer activates when bringing a window to the front

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

Issue description

Version: 56.0.2885.0
OS: macOS

[There might be a more realistic repro, this is the first one I could come up with.]

What steps will reproduce the problem?
(1) Install the attached "five second alarm" extension.
(2) Click its browser action.
(3) Switch to another app and wait a few seconds.

What is the expected output?
A window pops up and comes to the front. Chrome is the active application; it shows up in the menu bar and the window can be closed with cmd+W.

What do you see instead?
A window appears in front of other Chrome windows, but Chrome doesn't become active.

Regressed in crrev.com/2395083003.
 

Comment 1 by rsesek@chromium.org, Oct 10 2016

Labels: M-55 ReleaseBlock-Stable

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

Correction, regression happened at crrev.com/2386343004.
Project Member

Comment 3 by bugdroid1@chromium.org, Oct 10 2016

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

commit d694190ff0e1e1d594ccd644f807a1309ee61d5e
Author: sdy <sdy@chromium.org>
Date: Mon Oct 10 18:02:34 2016

[Mac] Pass YES to activateIgnoringOtherApps: to actually activate Chrome.

Passing NO doesn't activate our app in most cases; it seems to be mainly
useful when an app is launched (so there may be a long delay before it's
ready to become active) but the user might have switched to another app
in the mean time. In that case, the activation isn't the immediate
result of a user gesture, so it shouldn't steal focus.

This is a recent regression from crrev.com/2386343004.

BUG= 654441 , 653483 , 650845 

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

[modify] https://crrev.com/d694190ff0e1e1d594ccd644f807a1309ee61d5e/chrome/browser/ui/cocoa/browser_window_utils.mm

Comment 4 by sdy@chromium.org, Oct 12 2016

Labels: Merge-Request-55
Status: Fixed (was: Started)
Looks good in Canary.
fivesecondalarm.zip
1.7 KB Download

Comment 5 by dimu@chromium.org, Oct 12 2016

Labels: -Merge-Request-55 Merge-Approved-55 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M55 (branch: 2883)
As per comment #6, this is already merged to M55. If nothing is pending for M55, please apply "merge-merged-2883" label and remove "Merge-Approved-55" label.
Thank you.

Comment 8 by rsesek@chromium.org, Oct 13 2016

Labels: -Merge-Approved-55 merge-merged-2883
That's really bugdroid's job. I'm not sure why it's slacking off.

https://chromium.googlesource.com/chromium/src/+/dcb9b2152f0875df5fa0352b92da1ee97e2bba89

Comment 9 by hdodda@chromium.org, Oct 13 2016

Cc: ranjitkan@chromium.org hdodda@chromium.org
Labels: TE-Verified-M55 TE-Verified-55.0.2883.11
Verified the fix on Mac 10.11.6  using chrome dev version # M55- 55.0.2883.11 and followed the below steps:

1. Installed the provided five second alarm extension.
2. Clicked on the Installed extensions and then immediately navigated to Hangout app pre installed
3. After few seconds a pop-up appeared with the message .
4. Closed the pop-up with cmd+w.

Observed that Popup window closed and Chrome browser was in active.

Hence, the fix is working as expected.

Adding the verified labels.

Thank You !


Comment 10 by sdy@chromium.org, Oct 13 2016

hdodda@: Thanks, but I meant another system app (not Chrome). I'm sorry, in retrospect that was confusing ;).

Comment 11 by sdy@chromium.org, Oct 13 2016

(That was supposed to be a regular ':)', not a ';)'…)
Project Member

Comment 12 by bugdroid1@chromium.org, Oct 27 2016

Labels: merge-merged-2840
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dcb9b2152f0875df5fa0352b92da1ee97e2bba89

commit dcb9b2152f0875df5fa0352b92da1ee97e2bba89
Author: Robert Sesek <rsesek@chromium.org>
Date: Wed Oct 12 23:16:57 2016

[Mac] Pass YES to activateIgnoringOtherApps: to actually activate Chrome.

Passing NO doesn't activate our app in most cases; it seems to be mainly
useful when an app is launched (so there may be a long delay before it's
ready to become active) but the user might have switched to another app
in the mean time. In that case, the activation isn't the immediate
result of a user gesture, so it shouldn't steal focus.

This is a recent regression from crrev.com/2386343004.

BUG= 654441 , 653483 , 650845 

Review-Url: https://codereview.chromium.org/2409623002
Cr-Commit-Position: refs/heads/master@{#424182}
(cherry picked from commit d694190ff0e1e1d594ccd644f807a1309ee61d5e)

Review URL: https://codereview.chromium.org/2415783002 .

Cr-Commit-Position: refs/branch-heads/2883@{#77}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/dcb9b2152f0875df5fa0352b92da1ee97e2bba89/chrome/browser/ui/cocoa/browser_window_utils.mm

Comment 13 by dimu@google.com, Nov 4 2016

[Automated comment] removing mislabelled merge-merged-2840

Comment 14 by dimu@google.com, Nov 4 2016

Labels: -merge-merged-2840
[Automated comment] removing mislabelled merge-merged-2840

Sign in to add a comment