CloseBrowser safely

[salvadordf]

I haven't seen your latest PopupFMX code yet but maybe SendMessage is locking other threads until the message is handled.
Have you tried using other synchronization objects and replacing SendMessage by PostMessage?

PS : I'll try to take a look at your code this weekend.

[salvadordf]

The TThread.Synchronize project freezes when I click on "DecrementBrowser" because the application message pump is blocked in a SendMessage call to a window owned by a CEF thread.

Using SendMessage is also risky because the calling thread is blocked until the target thread handles the message.

Please, use PostMessage and some synchronization objects.

[salvadordf]

Try storing the title with the browser.identifier and then use
PostMessage(FmxHandleToHWND(Self.Handle), BROWSER_TITLE_CHANGE, Browser.identifier, 0);

MsgInterceptBrowserOnTitleChange will search in your browser list comparing Message.wparam and Browser.BrowserId to get the right browser. Then it would read the stored title.

[salvadordf]

It can be done but you have to make sure that the interface reference is decremented after it's used.
If you don't decrement it, the browser is never released and you will see access violations and memory leaks when you close the application.

In general, I would recommend NOT to pass pointers to the internal CEF class data.

In your case, you don't need to pass pointers because you already have all the browsers in TTabsDTBrowsers.FTabs.

It's much safer to pass the browser.identifier in PostMessage. The procedure handling that message can search for the browser in TTabsDTBrowsers.FTabs because the TChromium and TFMXChromium components have a public BrowserId property.

[salvadordf]

It's okay, but what about ICefFrame? If I need to pass ICefFrame..

You can store ICefFrame.GetIdentifier and later search that frame using TChromium.Browser.GetFrameByident.

It's so interesting, why I get the memory leak when I just assign the pointer of ICefBrowser(browser.wrap) in the pointer variable. Does it call _AddRef?

Yes, the Wrap function calls _AddRef. Most of the CEF classes are reference counted.
CEF4Delphi hides many of their peculiarities and you should be able to use them like normal Delphi interfaces.

Functions like "wrap" are used by CEF4Delphi internally to call the CEF C API functions.