This prevents wxWebViewChromium from referencing debug-only functions
that are not defined in the release build of libcef_dll_wrapper.
Unfortunately, CEF build doesn't provide any way to detect if the
wrappers were built in debug or in release mode, so just assume the
latter and add --enable-cef-debug configure option to build with a debug
build of CEF wrapper if necessary.
Ensure that the sample can run using wxWebViewChromium backend out of
the box by setting things up so that it can find the CEF files. Note
that we use symlinks instead of actually copying these files, to avoid
wasting so much disk space (CEF libraries take more than 1GiB).
Just include wxWebViewChromium in the webview library if it's enabled
during the build.
There doesn't seem to be any reason to build a separate library for it,
it's not really different from the other disabled by default wxWebView
backend (Edge).
And now that we don't need to link with an extra library, there is also
no need to have a separate webview_chromium sample, so just add a
possibility to run webview sample itself using Chromium backend by
setting WX_WEBVIEW_BACKEND environment variable.
This can be useful for diagnostic purposes and looks better than "0.0"
in the webview sample.
Notice that currently we return the compile-time version and not the
run-time version that could be retrieved using cef_version_info()
because this is simpler and we shouldn't be ever using a different
version from the one we were compiled with anyhow.
Don't report "IE" backend as being enabled just because it's enabled by
default under MSW.
Also give a warning if any of MSW-specific backends is enabled when not
building wxMSW.
Modify the sample to show the correct value of the user agent when using
WebKit backend as this got broken by calling it inside an event handler
executed later but before the idle event handler could dispatch the
result of JS executed from inside WebKit AddScriptMessageHandler()
implementation, resulting in misinterpreting this result ("{}") as the
user agent string.
The real fix is, of course, to deal with the JS execution results coming
out of order in some way.
It defaults to $root_cache_path/Cache which is fine and our existing
attempt to set it didn't work (and resulted in an error message) anyhow
as it must be under $root_cache_path now.
It is now defined as
@executable_path/../Frameworks/Chromium Embedded Framework.framework/Chromium Embedded Framework
in the framework itself, which means that we don't need to change it at
all for the main application and the wx library it uses.
We still need to change it for the helper application, but the command
doing it must be adjusted.
Avoid crashes if some functions are called before the browser is fully
initialized -- this is relatively likely to happen as the existing code
may not wait for wxEVT_WEBVIEW_CREATED before calling them, as must be
done with wxWebViewChromium.
wxWebViewChromium creation is asynchronous and the object can't be
really used until OnAfterCreated() is called, so expose this in the
public API via a new event sent when the object becomes actually usable.
As a side effect, add a convenient wxWebViewEvent ctor taking wxWebView
as argument and calling SetEventObject() itself, instead of forcing all
code creating wxWebViewEvents to do it.
While the window was somehow resized on its own under Mac (and only
there) after the initial creation, it didn't have the correct size
initially if we didn't give it to it, so provide a Mac-specific
implementation of wxEVT_SIZE handler too, which fixes this and allows to
remove an ugly Mac-specific workaround from the sample.
Instead of just declaring the function inline in the common code, do it
in a header included from both common C++ and Mac Objective C++ sources.
No real changes.
We can't wait for OnBeforeClose() to be called in the dtor there, or,
IOW, we can't count on it being called before the object is destroyed
and hence we can't update the flag in it neither.
Don't do it and just hope that the ClientHandler object always gets
destroyed soon after wxWebViewChromium itself anyhow because it's only
referenced by an autorelease pool.
It's not clear if this really should be doing something as previously
existing code definitely didn't, but it seems like actually storing the
flag should be no worse and at least now it compiles (due to the added
casts to IMP).
Use variables defined in our .props files instead of hard-coded values
and use DPI aware manifest instead of using "compatibility" one with
which the sample didn't work correctly in high DPI.
Use "wxCEF" prefix for this class to avoid any conflicts by using
non-wx-prefixed name.
Also replace wxWebViewChromiumImplData with wxCEF::ImplData as this is
shorter and more consistent with ClientHandler.
Finally stop using anonymous namespace for wxBrowserProcessHandler and
wxCefApp, as we can now put them into the same wxCEF namespace.
Ensure that CefLifeSpanHandler::OnBeforeClose() is called before
returning from wxWebViewChromium dtor, as otherwise we may try to shut
down CEF before the browser object is destroyed.
Under MSW it's enough to destroy the window ourselves to make this
happen, but under GTK/X11 we need to manually pump the messages, as
OnBeforeClose() is only called when the X event notifying about the
actual window destruction arrives.
Also make the code cleaner by using flags in wxWebViewChromiumImplData
instead of reusing m_clientHandler pointer to indicate that DoClose()
was called.
Restart the timer if it's already running but its expiration time is
beyond the specified delay, otherwise we could be waiting for too long.
This commit is best viewed ignoring whitespace-only changes.
