cefclient aborted popup keeps application from terminating

[rocknowradio]

Describe the bug
If FileDialogHandler::OnFileDialog gets invoked, cefclient does not terminate.

To Reproduce
Steps to reproduce the behavior:

1. Download Sample Application (127.3.5+g114ea2a 127.0.6533.120) Windows x64.
2. Open cefclient using cefclient --url=http://egghunter.in/safepay/file.html --enable-chrome-runtime (--disable-chrome-runtime yields the same result).
3. Click on the Click Here... image. This will invoke a file open dialog (in the background will attempt to also open a new popup, but even without this the result is the same).
4. Close the file dialog (either dismiss or pick a file).
5. Close cefclient.

Expected behavior
cefclient should close normally.

Screenshots
Not needed

Versions (please complete the following information):

• OS: Windows 10 x64
• CEF Version: 127.3.5

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

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

[magreenblatt]

Reproduces for me with M130 on Windows 11. The window closes but processes are still running in Task Manager.

[magreenblatt]

This does not appear to reproduce with the file open dialogs from https://tests/dialogs

[magreenblatt]

in the background will attempt to also open a new popup

Looks like cefclient's popup handling is the issue. The problem is avoided by running with --use-default-popup

It would be useful to test if calling preventDefault() and/or preventImmediatePropagation() in the onclick handler (to avoid the popup) also avoids the problem.

[rocknowradio]

I will debug all of these. I plan to upgrade to CEF 129 and this is on the regression list.

[magreenblatt]

Looks like cefclient's popup handling is the issue.

ClientHandler::OnBeforePopup and RootWindowManager::OnRootWindowCreated are being called for the popup, but no other ClientHandler or RootWindowManager callbacks. We likely need a better way to identify popups that are aborted during creation.

[magreenblatt]

In this case the popup is being aborted in WebContentsImpl::CreateNewWindow because the file chooser is active. This causes RenderFrameHostImpl::CreateNewWindow to ignore the popup after the call to CefBrowserInfoManager::CanCreateWindow.

[magreenblatt]

There are a number of cases where RenderFrameHostImpl::CreateNewWindow may cancel the popup after calling CanCreateWindow. For best results (to catch all cancelations) I think we need to add a callback for those cases.

[magreenblatt]

In this case the popup is being aborted

Console output looks like:

[5696:259:1113/115339.921324:WARNING:browser_info_manager.cc(194)] Pending popup 1 aborted for browser 1
[5696:259:1113/115339.921466:INFO:root_window_manager.cc(300)] Aborting popup 1 of browser 1
[5696:259:1113/115339.928237:INFO:CONSOLE(0)] "window.open blocked due to active file chooser.", source: https://egghunter.in/safepay/file.html (0)

[bjdupuis]

I'm trying to track down a similar thing in our app that only happens when we open a second browser in a popup on Mac OS. The app functions fine until it's time to quit and then hangs at quit time. This happens all the way back down to CEF 127.0.2 beta (switching nothing but the CEF files), and stops the bad behavior at 126.2.4, the final 126 baseline I can find.

cefclient with the OP's URL behaves a bit differently than described here on Mac. The version based on CEF 126.2.4 handles everything fine. cefclient on 127.0.2 crashes on cancelling the file dialog. I've had to release a version of our app on the final 127 release to correct the things that aren't working with the alloy-style/chrome-runtime (spell checker on windows, confirm dialogs) but now this behavior is present in 127. Is it felt that the fix here will similarly address this Mac behavior? Or there new things that must be done at the client level as well?

EDIT: That might not be totally true: version 126.2.4 of cefclient never actually quits.

[magreenblatt]

I'm trying to track down a similar thing in our app that only happens when we open a second browser in a popup on Mac OS. The app functions fine until it's time to quit and then hangs at quit time.

Do you actually mean "hangs" (e.g. unresponsive), or do you mean that it just doesn't exit? If it's not exiting then check why CefQuitMessageLoop is not being called in your case. For example, maybe there's an error in your OnAfterCreated/OnBeforeClose tracking.

This issue addresses aborted popups specifically, which doesn't sound like your issue.

[bjdupuis]

Yes, "hangs" as in unresponsive. Users have to force-quit the app. That behavior happens at 127.0.2 and doesn't at 126.2.4.