Unable to check this issue as we need to have purchase license for reeder. 

@Reporter: Could you please provide URL of another app where we can check this issue.

Thanks!

Deleted: 798739.png 362 KB

	798739.png 362 KB View Download

You could test with Evergreen (https://ranchero.com/evergreen/).

To replicate the issue:
1. Go to Preferences and check "open in background in browser";
2. Select one item from the default feeds and click the Safari icon at the top.

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce this issue on reported version 65.0.3298.3 dev and latest canary 65.0.3312.0 using Mac 10.13.1. Issue is not applicable to Linux and Windows.

Bisect Info:
=============
Good Build: 65.0.3288.0
Bad Build: 65.0.3289.0

You are probably looking for a change made after 522802 (known good), but no later than 522803 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/45e1654501f6bd0f407b0ff03dba54f48650f860..fe15df9c055bb0c48e94aa915c5fde61ac84b03d

Reviewed-on: https://chromium-review.googlesource.com/801030

Suspecting same from changelog.

@lgrey: Please confirm the bug and help in re-assigning if it is not related to your change.

Adding RB-Stable as this is a recent regression. Please change if not the case.

Thanks!

lgrey@,
Friendly ping to get an update as it is marked as stable blocker.
Thanks..!

Sorry, just got back from OOO.

I think I know what this is, should be a fairly easy fix. Will update when I've verified.

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

commit df414429eefc9c65c9d98cc68d225855d7ff2abd
Author: Leonard Grey <lgrey@chromium.org>
Date: Thu Jan 11 21:29:35 2018

[Mac] Don't activate Chrome while handling an OpenURL AppleEvent

For background:
In 10.13, if Chrome has updated in the background, and the user attempts
to open a URL from an external program, LaunchServices attempts to launch
a second Chrome instead of passing the event to the running instance.

A workaround to this was shipped in https://chromium-review.googlesource.com/801030
That change causes a newly opened Chrome to forward the "GURL" AppleEvent to
the running instance if a previously running instance is detected.

Along with sending the GURL AppleEvent, LaunchServices should also activate
Chrome. Since we couldn't find a reason that opening a URL shouldn't make Chrome
frontmost, we addressed this by brute force, causing Chrome to activate itself
when handling the GURL event.

It turns out that there *is* a good reason for Chrome not to always activate:
External applications that want to open links in the background via
the NSWorkspaceLaunchWithoutActivation option. The brute force approach
broke this. This change removes the automatic activation which should
fix the "link in background" issue at the cost of somewhat degrading the
already janky workaround (to be fixed later in a more subtle way).

Bug:  798739 
Change-Id: Ida62a0f72f8c8f2ed4c80f30eeb7a227077a8007
Reviewed-on: https://chromium-review.googlesource.com/861824
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528759}
[modify] https://crrev.com/df414429eefc9c65c9d98cc68d225855d7ff2abd/chrome/browser/app_controller_mac.mm

Verified the fix on Mac 10.13.1 using Chrome latest version #65.0.3319.0 as per the comment #0 & #3
Attaching screen cast for reference.
Observed that focus is still in the original app.
Hence, the fix is working as expected.
Adding the verified labels.

Deleted: 798739.mp4 3.0 MB

	798739.mp4 3.0 MB View Download

lgrey@ Thanks for looking in to it, Could you please change the status of this bug it the fix has landed completely.

Thanks!

[Auto-generated comment by a script] We noticed that this issue is targeted for M-65; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-65 label, otherwise remove Merge-TBD label. Thanks.

"Commit df414429... initially landed in 65.0.3319.0" so I think we're OK.