CEF API in question can be found here:
https://code.google.com/p/phpdesktop/source/browse/phpdesktop-chrome/cef/include
/
Option 1: Expose to javascript
------------------------------
Add new option "on_load_start=path/to/some.js" in settings.json. That js file
contents would be executed using CefFrame.ExecuteJavascript in
CefLoadHandler.OnLoadStart for each browser/frame loading. Two variables
BROWSER_URL and FRAME_URL would be set in that execution context.
Handlers could be implemented by overwriting methods in phpdesktop.CefClient,
eg:
CefClient.OnBeforeBrowse = function(browser, frame) {
...
}
DISADVANTAGE of exposing CefClient handlers API to javascript is that it is
open to deadlocks. Some of the handler callbacks require values to be returned.
So when executing phpdesktop.CefClient callbacks it is required to do it
synchronously by sleeping the Browser process. If cefclient callback tries to
call for eg. phpdesktop.ToggleFullscreen() it would create a deadlock. This
wouldn't be an issue for handlers implemented in the Renderer process. Most of
the handlers are exposed in the Browser process.
Option 2: Expose to PHP
-----------------------
Add new options to settings.json, for example:
"on_load_start=path/to/some.php". The browser process would be forced to sleep
while php script is being executed. If the callback doesn't require returning
data, then php script could be executed asynchronously. Data could be passed to
PHP via GET variables, optionally encoded with base64 or json. Returning data
would be possible by outputting a json encoded data.
DISADVANTAGE of exposing handlers via PHP is that you cannot communicate with
the webpage directly (however a webpage could have a continuous timer that
calls php scripts).
It might be best to expose CefClient handlers to both PHP and Javascript, each
has some pluses and minuses.
Original issue reported on code.google.com by czarek.t...@gmail.com on 23 Sep 2014 at 9:22
Original issue reported on code.google.com by
czarek.t...@gmail.com
on 23 Sep 2014 at 9:22