Adding ellyjones@ for Mac triage. It seems to me more of a platform specific issue than failure in navigation code. I've noticed myself that upon resume from sleep my MacBook very often hits memory pressure, so adding erikchen@ for triage from memory perspective.

joe@externl.com, does it open a second instance of Chrome? We've seen reports of something similar, also after High Sierra upgrade.

I never noticed specifically, but I don't think so. IIRC only one Chrome icon in my dock. I can check tomorrow morning and report back.

Thank you for providing more feedback. Adding requester "lgrey@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

This morning everything is working. Will wait to try again tomorrow.

After checking for updates at chrome://settings/help it's happening again.

Only one instance of Chrome is open. Each time a click a link a new window with one "new tab" is opened.

I'm seeing this any time an update has started but chrome has not relaunched.
Any call to `open <url>` invoking the URL/Protocol handler in OSX results in a new blank tab from Chrome.  See attached image.

Deleted: Screen Shot 2017-11-07 at 8.26.44 AM.png 11.8 KB

	Screen Shot 2017-11-07 at 8.26.44 AM.png 11.8 KB View Download

Thanks, jbaker@duosecurity.com, that's really helpful! Are you on High Sierra also?

borisv@ any idea where the best place to look might be?

You're right, that's also exactly when I'm experiencing this too!

I am on high sierra.

I've seen this issue sporadically too for the last week or two. The only way I've been able to fix it is by completely crashing Chrome and opening it up again.

I'm on High Sierra as well.

We have an workflow here at Duo that relies on opening the web browser (as a part of the BeyondCorp model) to complete authentication. We've been seeing this issue a lot as we're opening more windows than most people.

FWIW, on Linux, I'm unable to reproduce this issue. In fact, I just completed a Chrome upgrade through the Arch package manager, and then ran `xdg-open https://google.com` and a new tab opens in my browser to the Google home page, as expected.

In regards to the updates - the updater typically doesn't open links, unless there is an app that requests it as part of the update process. To see what the updater has done, can someone who experienced the problem recently run Google Software Update diagnostics tool and let us know at what time and date was the blank page observed, so that I can try to correlate the logs to the problem?

To run the diagnostic tool, open Terminal app and start the following program:
~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/ksdiagnostics

If the command fails with 'No such file or directory', please try without the '~' at the start:
/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/ksdiagnostics

Then attach the generated .zip file with the logs or send the file to borisv@chromium.org.
Feel free to inspect the logs - they are text files and any personal information is stripped automatically by the tool.

I am having this problem too, on High Sierra. I have sent my ksdiagnostics logs to you Boris. One thing I have noticed that might be related is, in the system settings for "Security & Privacy", in the Privacy/Accessibility tab, there's an entry for "Google Software Update" that is not checked/enabled. I don't remember that being there before and have not yet opted to enable it. 

@ borisv@chromium.org, I wasn't saying that the updater opened the links.
What I was saying is that while the updater was processing updates and the chrome process had not been relaunched was when I noticed this happening from external applications.  I just used the open command on OSX to invoke the protocol/url handler to launch something in the default browser.

Before relaunching chrome this results in a blank tab opening in a new window.
After relaunching chrome to finish applying the update this results in the open <url> command successfully opening the page in a new tab.

Ah, my bad - I misunderstood the problem. Adding rsesek@ and kerrnel@. I am wondering if Chrome signing is not as strong immediately after the update and High Sierra has strengthen the code signing requirements.

Based on the reports, particularly from jbaker@, the problem started happening immediately after the update finished. Only Chrome update was applied on that box, so it is unlikely that other updates are interfering with Chrome state.

I am also wondering if this bug is related: https://bugs.chromium.org/p/chromium/issues/detail?id=781825

To back up the update theory - I've just seen this issue, when I checked About there was a update waiting for a relaunch. After clicking the relaunch button the issue resolved itself.

I was seeing this issue after I upgraded to High Sierra yesterday. Today, after reading here, I tried checking for Chrome update. Chrome was already auto-updated but was waiting for relaunch. Once relaunched, the issue is fixed.

This continues for me.  High Sierra, Chrome Canary.  Restarting Chrome fixes it for a while, but at least once a day I have to restart Canary.  This began after the update to High Sierra, and affects links opened from any source that isn't Chrome itself, including Terminal, Airmail, and Adium.

This has persisted through a month or so of updates.

Is there anything I can do to aid this?  It's an incredibly annoying bug, although the actual impact isn't incredibly high due to a relatively straightforward temporary fix.

lgrey@ will own this from the Mac side.

 Issue 782408  has been merged into this issue.

Also experiencing this issue. Quitting chrome is the only solutions. Links opened anywhere within the OS open into a blank tab.

As one bit of info, it definitely does not require going to sleep.  I had to restart Canary this morning to resolve the problem, and a few minutes ago I had to restart it again despite opening links successfully between throughout the day.  I cannot think of anything in particular that happened between the last successful link and the first failed link a few minutes ago to tie this to.

Thanks for the reports everyone. We can now reproduce this and are working on figuring out the exact issue.

So what appears to be going on here is that High Sierra's launchservicesd isn't finding the running application because the CFBundleExecutablePathINode is different.

borisv@ would we be able to reuse the existing inode when updating the exe?

No, there isn’t any way to do that safely.

Followup to my previous comment #17 and @borisv. Enabling Accessibility options for Google Software Update did not resolve the problem, I still saw the same behavior.

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

commit fe15df9c055bb0c48e94aa915c5fde61ac84b03d
Author: Leonard Grey <lgrey@chromium.org>
Date: Fri Dec 08 17:09:53 2017

[Mac] Forward "open URL" AppleEvents to running Chromium instance.

In macOS 10.13, if:
- Chromium is the default browser
- Chromium has updated
- The user has *not* relaunched

and the user tries to open a link from an external program, instead of
opening the link in the running instance of Chromium, LaunchServices
tries to open a second instance of Chromium.

Currently, this causes the running instance to open a blank new window.

This change, when detecting that a running instance exists, checks
for any queued open URL events and forwards them to the running instance.

Bug:  777863 
Change-Id: I9532b1f8bf4c6624992cc4f18ec41857b89d94d5
Reviewed-on: https://chromium-review.googlesource.com/801030
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522803}
[modify] https://crrev.com/fe15df9c055bb0c48e94aa915c5fde61ac84b03d/chrome/browser/BUILD.gn
[modify] https://crrev.com/fe15df9c055bb0c48e94aa915c5fde61ac84b03d/chrome/browser/app_controller_mac.mm
[modify] https://crrev.com/fe15df9c055bb0c48e94aa915c5fde61ac84b03d/chrome/browser/process_singleton.h
[add] https://crrev.com/fe15df9c055bb0c48e94aa915c5fde61ac84b03d/chrome/browser/process_singleton_mac.mm
[modify] https://crrev.com/fe15df9c055bb0c48e94aa915c5fde61ac84b03d/chrome/browser/process_singleton_posix.cc

ssb@ or any other affected Canary users, can you see if this is fixed* for you?

* It's still expected that a second instance of Chrome will bounce on the dock before the link opens.

As of last night, what would happen is a second instance of Chrome would open, and then just hang until I force quit it.

I'm taking my laptop in for unrelated service today, and I'm not sure if I'll get to take it home with me, so I may not be able to do a better test for a bit.  Is there any specific testing you'd like me to do?

Turns out opening via link sends a different event than the "open" Terminal command, unlike we assumed. Trying to figure out if I can fix forward quickly, will roll back if not.

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

commit 883d108c78f69c2d6b72634fc0911ec629e98f58
Author: Leonard Grey <lgrey@chromium.org>
Date: Wed Dec 13 15:06:11 2017

[Mac] Create a new AppleEvent when forwarding to open instance

The previous fix for this (see linked bug) was tested via the `open`
command in Terminal. Turns out that the system sends a slightly
different AppleEvent in the case of a link being clicked (in, say,
Notes.app) than via `open`. Something about the "click a link"
version doesn't take well to being forwarded the way we were doing it.

This change extracts the URL from the received event and sends a fresh
event with that URL instead.

Bug:  777863 
Change-Id: Ie8c0dc6187806756fda898440849b6830ab9d345
Reviewed-on: https://chromium-review.googlesource.com/822892
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523773}
[modify] https://crrev.com/883d108c78f69c2d6b72634fc0911ec629e98f58/chrome/browser/process_singleton_mac.mm

I got my laptop back surprisingly quick, so I ran some tests.  As I noted and you verified, it definitely would just hang with a spinning cursor forever when clicking a link with the initial change.  I updated Canary to the latest version, and it initially appears to work.  Then again, it generally did for at least a few hours after restarting Chrome.  I'll post again to verify probably tomorrow after it's had some time to try to break itself.

Thanks again for looking into this!

 Issue 794774  has been merged into this issue.

Ok - after a couple days, this appears to work.  It's a bit strange having something pop up in the task bar (or whatever it's called) briefly, but it's not a huge issue, and it appears to work well enough.

Chrome is due to relaunch after update an the issue reproduced itself again.

 Issue 800211  has been merged into this issue.

Very glad the cause for this issue has been identified.

Theoretically, disabling autoupdates should also be a workaround to prevent this from happening, correct?

Re. #45, I would strongly recommend leaving updates turned on, if only because they let us quickly fix security bugs — browsing the web with an older version can be dangerous. (I'm not sure that Chrome even offers a setting to turn off updates.)

 Issue 800535  has been merged into this issue.

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

commit e69253fdb76d9c2d6094bc5fa3746a6cc82c15c4
Author: Leonard Grey <lgrey@chromium.org>
Date: Fri Jan 12 20:23:54 2018

[Mac] Activate running Chrome instance after forwarding open URL event

This change replaces the method that was removed in
https://chromium-review.googlesource.com/c/chromium/src/+/861824

Now, instead of the running instance activating itself on receiving
a GURL AppleEvent, ProcessSingleton sends a second AppleEvent after
forwarding the GURL to activate the running instance.

This specific event type/class is what AppleScript sends on
"tell application 'Chromium' to activate" per AEDebugReceives

Bug:  777863 
Change-Id: Ie76973f2db0f7d3c4a18acbd9be28b846b51a794
Reviewed-on: https://chromium-review.googlesource.com/865175
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529046}
[modify] https://crrev.com/e69253fdb76d9c2d6094bc5fa3746a6cc82c15c4/chrome/browser/process_singleton_mac.mm

mail opens empty link in new web browser page

sdy, I understand the risks in turning auto update off, but it's also worth considering that the very nature of the issue is that it occurs until the browser is relaunched to take advantage of the update. So if I have Chrome open for an entire week without relaunching, whether or not updates are on is moot because said update won't be applied until relaunch. 

I'm trying to minimize the impact of this defect in any way possible, and the issue surfaces only when an update takes place :)

 Issue 799009  has been merged into this issue.

lgrey@ This issue is marked as RB-Stable for M64, could you please let us know is there any latest update available on this issue.

Thanks!

Assuming the only problem that Apple has with routing new events to the existing Chrome instance is that our main executable’s inode number has changed:

This morning, I thought about using exchangedata() to write out the updated main executable. That would be:
 - initial: "Google Chrome" is inode number 111111.
 - write executable at new file ".Google Chrome.XXXXXX", its inode number is 222222.
 - exchangedata("Google Chrome", ".Google Chrome.XXXXXX"). "Google Chrome" is still
   inode number 111111, but now has new contents.
 - unlink(".Google Chrome.XXXXXX"), which has the old contents.

That’s fine for HFS+, but exchangedata() is ENOTSUP on APFS. APFS supports renamex_np(), and the RENAME_SWAP flag can be used instead. (HFS+ doesn’t support this.) This is similar to exchangedata(), except the inodes are swapped (along with their numbers).

But I think we can still use renamex_np() to provide a way to swap files without leaving a window where the installation is broken, and while retaining the original inode number when everything’s done. Consider:
 - initial: "Google Chrome" is inode number 111111.
 - write executable at new file ".Google Chrome.XXXXXX", its inode nuber is 222222.
 - renamex_np("Google Chrome", ".Google Chrome.XXXXXX", RENAME_SWAP). "Google Chrome"
   is now inode number 222222 and has new contents. ".Google Chrome.XXXXXX" has old
   contents but the coveted inode number 111111.
 - Rewrite ".Google Chrome.XXXXXX" in place. I’m afraid of doing truncate-and-write.
   I suppose I’m a little less afraid of doing write-and-truncate. But this is still
   the scariest part to me, because it’s “most unknown.” When this is done, both files
   on disk will have new contents.
 - renamex_np("Google Chrome", ".Google Chrome.XXXXXX", RENAME_SWAP) again. "Google
   Chrome" goes back to inode number 111111 and has new contents.
 - unlink(".Google Chrome.XXXXXX")

The scary part is messing with file contents on the inode in use by the running executable. Will that be OK? Will the code signature system hate that? (Greg, what do you think about this?)

The benefit is that with either of these, there’s zero window for the installation to be broken entirely, because "Google Chrome" will always have a complete copy of a main executable, either old or new, and will be atomically switched from one to the other. This is a hard requirement of the auto-update system. In the renamex_np() variant, there is a small window in which the inode number of "Google Chrome" won’t match the running executable’s, but the worst thing that can happen in that case is this bug, which is far from complete brokenness. It’s also an incredibly narrow window.

There are filesystems that support neither exchangedata() nor renamex_np(), and in those cases, we should fall back to a straight rename().

Pulling this all together, with appropraite fallbacks, the logic to move the main executable into place would be:

  write(".Google Chrome.XXXXXX")
  e = renamex_np("Google Chrome", ".Google Chrome.XXXXXX", RENAME_SWAP)
  if (e == 0) {
    // APFS case
    write(".Google Chrome.XXXXXX")
    renamex_np("Google Chrome", ".Google Chrome.XXXXXX", RENAME_SWAP)
  } else if (e == ENOTSUPP) {
    // HFS+ case
    e = exchangedata("Google Chrome", ".Google Chrome.XXXXXX")
    if (e == ENOTSUPP) {
      // Neither APFS nor HFS+. Basically what we do today (rsync does it for us)
      rename("Google Chrome", ".Google Chrome.XXXXXX")
      return
    }
  }
  unlink(".Google Chrome.XXXXXX")

brajkumar@ I need a little time to absorb what mark@ wrote above, but in any case, it wouldn't be something we would merge to stable. Our current mitigation is probably the best we'll do in the immediate future, but I'm leaving the bug open since it's an unsatisfactory solution.

I’ve validated comment 56’s theories. This seems to work cleanly. I’ll try to integrate this into the updater later today.

Here’s something that we should be able to use to update the main executable: https://chromium-review.googlesource.com/c/chromium/src/+/881764/1/chrome/installer/mac/replace_file.cc

Greg, what do you think about making changes to the file contents hanging off of an inode in use as the main executable? Is Security.framework going to disapprove? Or is does that only become a concern with a bit that we’re not opting in to, like kill?

 Issue 806197  has been merged into this issue.

Friendly ping to get an update on this issue as it is marked as stable blocker for M64.

Thanks..!

Comment 57 still stands. The fix from comment 56 is in progress but probably won't be merged back. I would recommend removing the RBS.

Kernel code signing information is attached to the inode which makes that a very brittle fix. Who knows what will go wrong because now after update the Chrome image in memory is always going to have a broken code signature.

Is Sparkle an option?

Moving this from M64 to M65. 

Issue 809018 has been merged into this issue.

 Issue 810251  has been merged into this issue.

Preliminary testing on 10.13.4 beta suggests this may be fixed.

M65 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge  into the release branch ASAP. Thank you.

This will be fixed by the OS vendor. In the meantime, the current mitigation is as risky as we're willing to go, so removing RBS.

Is there a radar filed or is it something Apple is aware of? Sorry if this was discussed earlier, I looked around and didn't see it.

 Issue 812145  has been merged into this issue.

Yes, we filed rdar://35505509 for this issue.

 Issue 815389  has been merged into this issue.

 Issue 816950  has been merged into this issue.

 Issue 817833  has been merged into this issue.

I have a question about this - I use Chrome Canary, as I mentioned back in December, and the fix I commented on Dec 13/15 still appears to be working fine.  Canary gets frequent updates, but I don't update every single time when I have a good working build as occasionally I get a nonfunctional build and have to use Firefox for a day til it's fixed.  However, even when I have a pending update, which is a lot of the time, I'm not having any issue opening links in other applications.  I get the quick bounce on the taskbar and then it opens up as expected.

Is the "pending update" problem limited to Chrome proper?  Or do I have something weird going on where it's working for me but not others?

I'm mainly asking in case I would be able to provide helpful diagnostic information if this is unexpected behavior.  Thanks!

Regarding comment 69 & 70, just to clarify, the progress on this fix has completely halted from the Chromium side until the radar is resolved on Apple's end?

I didn't see it on openradar so am not able to stay informed of progress (if any) on Apple's side.

There is a workaround fix in Chrome 65 and higher, but it will cause the dock icon to bounce because the newly-launched Chrome has to forward the URL to the already-running one.

A better fix is reportedly coming in macOS 10.13.4, so we decided to not implement a more complete workaround within Chrome.

Thanks Robert! I'm currently running 65.0.3325.146 and there is a pending update that has been downloaded (presumably 65.0.3325.162), and the issue has since reoccured. The behavior that you described is not happening, I don't see any bounces in the dock and it behaves just like it used to while there was a pending update waiting.

How can I further troubleshoot this so I can at least take advantage of the temporary workaround fix you described until 10.13.4 is released?

Issue 812487 has been merged into this issue.

As a followup to #80, I am now currently running 65.0.3325.162 and when 65.0.3325.181 has been downloaded in the background. As soon as this finished downloading links immediately stopped working again. The behavior described in #79 has definitely not occurred. Really, really frustrating :(

I am confused, can someone provide more clarification if the behavior in #79 is something I should be seeing on 65.0.3325.181 ?

@sam123... (Comment 82)

As I mentioned in 77, I do have the bouncing dock behavior with functional links on Canary, version 67.0.3372.0 (Official Build) canary (64-bit).  Perhaps you could try Canary as a workaround for time being - it's possible that the workaround fix was only implemented in Canary.  I can't say for certain.

Canary is generally good for a daily browser, but keep a backup browser of some sort around because the occasional build has a major bug of some sort that either causes constant crashes or very weird page displays - it's usually fixed within a day or two.

Again, I'm only suggesting it as a workaround until Apple fixes it, or at least for testing.  Most people that aren't me won't want to risk having an update kill their browser for a couple days.  Once canary is installed, you can set it to the default browser in System Preferences->General.  Good luck!

Thanks for the suggestion on Canary. I have that as well, but I interpreted #79 to suggest the dock icon bounce workaround was implemented in 65+ on the stable channel. I'm not able to switch to Canary as my primary browser, I need the public stable version of Chrome to be just that — stable. 

On the enterprise side, since I cannot discern a workaround from this thread, 2 weeks ago I raised this issue to G Suite support as Chrome is covered under the SLA. I understand your advice is not being dispensed as from Google, but really the opposite should be true; a user should not be switching to Canary for more stability. Canary is described as "bleeding edge". The build "has not been tested or used, it's released as soon as it's built.". Canary is not an appropriate recommendation for use in a production environment, and certainly not appropriate as a Chrome replacement for more stability than Chrome itself.

I am troubled that a fix will not be delivered by Apple by 10.13.4 and this bug will continue to persist indefinitely. Given that Google makes it exceptionally difficult to turn off autoupdates, this single bug has created extraordinary hassle that a stable web browser suddenly cannot open URLs at intervals perceived to the casual user as completely random.

No, I definitely do not represent google in any way, shape or form.  I'm not suggesting that everyone start using Canary at work in their production environment.

It was a suggestion from one user to another to help you personally with opening links in the meantime before google fixes it.  Feel free to not use it, as it was just a suggestion.

Once again, I am not tied to Google in any way.

Was this resolved by Apple in 10.13.4? Or was the dock bouncing workaround implemented in Stable 66.0.3359.117?

Yes, it's resolved in 10.13.4, and the dock bounce workaround has been in stable for some time.

Thanks!

I created a duplicate bug report of this, and it does indeed appear to be fixed on my current versions of macOS (10.13.4) and Chrome (66.0.3359.117, currently prompting me to update to 66.0.3359.139).  Thanks for doing this!

Issue 795738 has been merged into this issue.

Issue 851047 has been merged into this issue.