It looks like invoking the External Protocol dialog calls ContentFaviconDriver::DidStartNavigation, which resets favicon_urls_. Then when the Add to Desktop dialog tries to get the favicon it's stuck waiting for the favicon URL, which won't ever show up.

Not sure what causes it to get unstuck if you summon the External Protocol dialog again (another DidStartNavigation flushes something?) but I don't think it should get into that state in the first place.

Did a bisect and got this range: https://chromium.googlesource.com/chromium/src/+log/fb6b7878b5aead7fc444fb4ab346bbe2d8975fed..1062c3ca9f9d7222665b956d1d9ed80a5e024b64

https://chromium-review.googlesource.com/c/chromium/src/+/700434 looks pretty likely. I'll try to find a cross-platform-friendly repro.

Found one: https://www.mirc.com/mirclink.html. Any of the IRC links will trigger it like the "cortana" link above. The URLs need to be in the main frame, so jsfiddle and the like won't work.

Thanks for the report and investigation, it does look like you found the culprit. I'll take a look.

Here's what seems to happen:
1. FaviconDownloader assumes that an empty favicon list guarantees that DidUpdateFaviconURLs() will be called later on (see [1]).
2. This is reasonable considering the ContentFaviconDriver API documentation in [2].
2. That's however not the case for the scenario that motivates the regressing CL (as mentioned earlier, [3]), provided that the page has already been loaded (which is the case)
3. FaviconDownloader waits forever expecting that DidUpdateFaviconURL() will be called.

[1] https://cs.chromium.org/chromium/src/chrome/browser/extensions/favicon_downloader.cc?l=65&rcl=df5687eeab21e773ecb6234ee6d019d49b9dc328

[2] https://cs.chromium.org/chromium/src/components/favicon/content/content_favicon_driver.h?l=40&rcl=30cf78450be041e3329a4d0f8c8a485724564b84

[3] https://chromium-review.googlesource.com/c/chromium/src/+/700434 

Sent a patch for review, https://chromium-review.googlesource.com/c/chromium/src/+/853867

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

commit 7337e34e0939dea633e9d7f50635cbb9f456b350
Author: Mikel Astiz <mastiz@chromium.org>
Date: Mon Jan 15 16:53:21 2018

Fix "Add to Desktop" dialog for stopped document loads

Prior to this patch, and due to a regression introduced recently in
https://chromium-review.googlesource.com/c/chromium/src/+/700434, the
steps described in the linked bug (or, more broadly, stopped document
loads) cause ContentFaviconDriver to report no favicon candidates, that
is, expose an empty vector in ContentFaviconDriver::favicon_urls().

This is an API violation according to the existing documentation and
a scenario that confuses the only actual caller of favicon_urls(), which
is FaviconDownloader. This class assumes favicon candidates will be
received later on via DidUpdateFaviconURLs(), but that's never the case.
Hence, the class waits forever and the "Add to Desktop" dialog never
gets shown.

We fix the issue by exposing the candidates in favicon_urls() also for
the cases where the list may be partial, restoring the behavior prior
to the offending patch linked above.

Bug:  799587 
Change-Id: I76ca2a3a97044469b56c9521d99f334c9479e2f7
Reviewed-on: https://chromium-review.googlesource.com/853867
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Reviewed-by: Peter Kotwicz <pkotwicz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529299}
[modify] https://crrev.com/7337e34e0939dea633e9d7f50635cbb9f456b350/components/favicon/content/content_favicon_driver.cc
[modify] https://crrev.com/7337e34e0939dea633e9d7f50635cbb9f456b350/components/favicon/content/content_favicon_driver_unittest.cc