You're right. CEF calls the functions to get the custom handlers more than once for most of them. I should've check all of them before stating that CEF only checks them once.
However, I'm still reluctant to accept those code changes because that's an unexpected behavior for the CEF libraries.
The official samples create a
Client class which only implements the handlers that they need :
https://bitbucket.org/chromiumembedded/ ... h#lines-28
https://bitbucket.org/chromiumembedded/ ... h#lines-57
That class returns "this" (equivalent to "self" in Delphi) every time CEF checks if a custom handler is available. The client class is used to create the browser and it's not modified while the browser is alive.
This may seem an unusual reason to accept or decline code changes but my experience fixing CEF4Delphi bugs in the last 2 years made me realize that many issues are caused by Delphi code that do something in a different way than the official CEF applications.
This is an old example : CEF4Delphi used to create all the handlers in TCustomClientHandler just in case an event was assigned after the browser creation. That seemed to work fine but then CEF 3.3239.1700.g385b2d4 was released with a bug in the JS Dialogs handler.
https://www.briskbard.com/forum/viewtopic.php?f=8&t=234
That bug caused many more crashes in CEF4Delphi than other wrappers because we were always creating the JS Dialogs handler.
Some other shutdown crashes and memory leaks were also caused by Delphi code releasing interfaces differently than the official CEF application. TCustomClientHandler, TCefApplication, TChromium and many other classes have been modified several times for that reason.
I'm sorry but I have to suggest you to create a your own custom classes inheriting from TChromium and TCefClientOwn. You would only need to add a new procedure to create the browser using your own client handler.