Disclosure Statement: This site contains affiliate links, which means that I may receive a commission if you make a purchase using these links. As an eBay Partner, I earn from qualifying purchases.

TChromium and the state of the browser(s) - InCreation and InDestruction

Post Reply
martin_fr
Posts: 30
Joined: Wed Jan 27, 2021 5:56 pm

TChromium and the state of the browser(s) - InCreation and InDestruction

Post by martin_fr »

Follow up on my big post: https://www.briskbard.com/forum/viewtopic.php?f=8&t=1702

While there are technical implications, this starts as a design decision:
What help and protection should CEF4Delphi offer/add on top of just translating data and passing calls to CEF.

Part 1
(IIRC) Cef4Delphi already has some support for marking a browser as "in destruction".
But it does not have knowledge of a Browser "in creation". (I.e. until AddBrowser is called).

Yet user code can receive events, during which they might want to act on the browser. Further more users might want to call "CloseBrowser" at any time after they called "CreateBrowser".
Currently they must wait for the correct event, and keep track of all state related changes themself, since TChromium does not.
IMHO this state keeping is not only common, but in most case mandatory. So it might be desirable to be added to TChromium.
(TEmbeddedChromium has that, but only works for one single browser, and not in MultiBrowserMode).

Part 2
How far should CEF4Delphi protect from calls that are not valid for the current state. And should it defer them, until the needed state is reached.
(This depends on part 1 / the state must be known)

My understanding is (but I could not find explicit statement in the CEF documentation), that a browser can be used, once it had its "OnAfterCreated" event (to which the browser is passed as parameter).

From testing and cef code review, that is actually not fully true.
When creating a browser using CreateBrowserHostSync (MultiThread = False), the browser can be accessed for a subset of actions only (e.g. set/change URL). But it can not yet be Closed. CEF will crash, if the browser is closed before CreateBrowserHostSync returns.
This is of course CEF behaviour that the user needs to simply be aware off. Not a fault of CEF4Delphi.
But if state keeping (part 1) were to be added, Cef4Delphi might be able to add protection.

Part 3
This is Cef4Delphi behaviour, that IMHO is not consistent. So the question is should it be improved. (It's not wrong, just not consistent.

Consider the following cases.

1) MultiThreaded = False / MultiBrowser = False
2) MultiThreaded = False / MultiBrowser = True
3) MultiThreaded = True / MultiBrowser = either

A user will call "CreateBrowser" and then receive an "OnBrowserCreated" event. (which will be in the browser/main process; and "UI" thread)

I could not find any info in the CEF doc, in which order the following 2 points in the user code are executed:
- return from "CreateBrowser"
- "OnBrowserCreated" event
And I believe that the answer is and should be, they can occur in any order, and any code must assume that the order is random.

Given the order that currently happen on Windows, and which is a valid order (i.e. it is one possible order for which code must work), the user code will get the following results when calling "Chromium.IsInitialized" during the "OnBrowserCreated" event.

1) IsInitialized = False
2) IsInitialized = True
3) IsInitialized = True

IMHO 1 and 2 are not consistent.
Also IMHO, in the "OnBrowserCreated" event it should always be true? Or it should only be true, if "CloseBrowser" can be called (which is not the case in the 2nd scenario)

--------------
Looking at commit history, before MultiBrowser mode was added, using CreateBrowserHostSync would always defer AddBrowser (and IsInitialized) until CreateBrowserHostSync returned. (Maybe this was, because of the CloseBrowser issue, I do not know)
But MultiBrowser was allowed to override this behaviour.

In the end, it is an observation that I made. Maybe there are reasons why behaviour was chosen the way it is. But those reasons are not apparent to me.
User avatar
salvadordf
Posts: 4016
Joined: Thu Feb 02, 2017 12:24 pm
Location: Spain
Contact:

Re: TChromium and the state of the browser(s) - InCreation and InDestruction

Post by salvadordf »

I'm sorry for this long delay but I'm busy these days.

I haven't forgotten your questions and I'll try to answer them as soon as I can but before that I'll finish writing the new documentation with all the details about Linux and MacOS.
Post Reply