chrome: Flaky behavior with external protocol confirmation dialog

[r0mai]

Describe the bug
I'm looking to get external protocols (such as zoommtg:// or spotify://) to work the same way as they do in Chrome. This is the diff I used to test cefsimple using the recommended way via OnProtocolExecution: https://gist.github.com/r0mai/32aa17ed2d8973de4d08d495499c534e

To Reproduce
Steps to reproduce the behavior with the diff above applied:

1. Open this page: https://rawgit.com/r0mai/32a98503ad6937491403e3b2b47b4fe9/raw/00aed6c9af183221fc991252f6be0d9de7a5195d/protocols.html (I used --url)
2. Clicking on Open Spotify <a> button. This is a link to spotify:, which's Spotify custom scheme to open their app. You may need to use a different link if Spotify is not installed.
3. The confirmation dialog may appear. This step is rather flaky. Sometimes the confirmation diaglog doesn't appear at all or disappears after a fraction of a second.
4. Clicking on Open Spotify button in the dialog opens Spotify but also triggers an ERR_UNKNOWN_URL_SCHEME error page

Expected behavior

• The confirmation dialog opens reliably.
• Once the confirmation dialog is accepted or dismissed the page does not navigate away to a ERR_UNKNOWN_URL_SCHEME page.

Versions (please complete the following information):

• OS: Windows 11
• CEF Version: 133.4.0

Additional context
Does the problem reproduce with the cefclient or cefsimple sample application at the same version?

• It does reproduce with cefsimple with the modifications linked above.

Does the problem reproduce with Google Chrome at the same version?

• No it does not.

Add any other context about the problem here.

• I have a local workaround in CEF that circumvents the OnProtocolExecution callback completely and behaves exactly as expected. The workaround is to remove the early return in HandleExternalProtocol() here:

  cef/libcef/browser/chrome/chrome_content_browser_client_cef.cc

  Lines 508 to 511 in 8ddb1bf

  	if (out_factory) {
  	// Let the other HandleExternalProtocol variant handle the request.
  	return false;
  	}

[magreenblatt]

Once the confirmation dialog is accepted or dismissed the page does not navigate away to a ERR_UNKNOWN_URL_SCHEME page.

See #2715

[magreenblatt]

The confirmation dialog is likely canceled due to the error page navigation.

[magreenblatt]

Please test in M135 (builds to be available tomorrow) and report any issues.

[r0mai]

Got around to test it. Seems to work flawlessly. Thank you!