It is apparently not safe to call gtk_events_pending() from the idle
callback, as it can result in GLib failing to properly dereference some
GSource objects.
This leads to increasingly large amounts of CPU time being spent in GLib
processing internal lists of these GSource objects. So avoid calling
gtk_events_pending(), as it is not strictly necessary because our idle
source will remain installed if wxIdleEvent::RequestMore() is used, and
if no events have arrived the idle callback will be invoked again.
Closes#23364.
See #23368.
This replaces the previously implemented wxWebViewWindowInfo.
It explicitly breaks the previous API to enable WebKitGTK
integration and to make the usage in application code less error prone.
A new event wxEVT_WEBVIEW_NEWWINDOW_FEATURES is added to allow
access to the window features and the child web view.
This function must be called to be able to re-create the EGL drawing
surface after the window layout have changed, such as after a reparent
of the canvas or of it's grandparents.
Make it suitable for use in this case by re-creating the surface if
there already was one and document this function to make it part of the
public API.
Closes#23366.
- Update parsing IPvX addresses to follow RFC and add many more tests.
- Rework authority parsing for RFC edge cases.
- Fix a couple of other extreme edge cases.
Closes#23360.
Remove _() around string which it doesn't make sense to translate in the
sockets sample.
This doesn't actually change anything as this sample doesn't use
translations in any case, but still show a good example.
Closes#23362.
Version 2.40 deprecates a few functions used in wxWebViewWebKit
implementation, resulting in new warnings breaking CI builds.
Avoid these warnings by suppressing them for now before the real
solution, involving using the new functions if they're available, can be
implemented.
See #23367.
Tab traversal from a wxPropertyGrid didn't work across wxPanel
instances or when the property grid was followed by a static control
such as wxStaticText due to implementing it "manually".
Fix this by using Navigate() to implement this instead, and just keep a
SetFocus() hack which is still needed for wxGTK.
Fixes#23354.
Closes#23358.
Since 8.0~repack-3 version of the Debian Wine package, installing wine64
doesn't create wine64 symlink any more and wine package needs to be
installed to do it, apparently due to the changes done to fix
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029536
This resulted in the tests not running any more because we used wine64
for running them. Just use "wine" now and install wine package, as it
should still run 64-bit binaries just fine.
In 40ff38b63b wxWebView::GetNativeConfiguration() was
added which isn't suitable if multiple wxWebViewEdge instances are created with
different options (as they must share the same options). To prevent such errors
the previous method is replaced by the new class wxWebViewConfiguration which
can be shared between various wxWebView instances.
This explicitly breaks API to improve usage.
In the future the new class could also enable a good way to wrap various
common options/configurations available via native API.
We could return a wrong value from this function if two threads called
it simultaneously, as gmtoffset value could be returned without DST
adjustment in one of them. And just accessing it from two different
threads without synchronization was a data race on its own.
Fix both problems by using an atomic int for it and taking care to only
set it to the correct value.
Using sleep was not only fragile but also resulted in tons of TSAN
errors, so replace it by the similar approach to the one which was
already used to wait for the threads to start up.
This is horribly inefficient but we don't care about this in the test
and, at least, this does ensure that the threads exit before it ends.
This function could be called on an already deleted object, which could
result in a crash, and always resulted in a TSAN error.
Fix this by calling it before releasing the internal lock, which
prevents this from happening, but will result in a deadlock if this
function is overridden to do something requiring any lock held by the
thread.
This is not ideal, but still seems to be like a lesser evil.
Don't use sleep in this test as the thread may terminate before it
returns, possibly resulting in crashes that the existing comment warned
about, and definitely resulting in TSAN errors.
Also ensure that the thread doesn't terminate instead of just hoping
that it doesn't do it because it doesn't have time to run 30 iterations
of its entry function by passing the special value of 0 to ctor, which
explicitly prevents the thread from terminating on its own.
Contrary to what an existing unit test claimed to do, it did not test
deleting a joinable thread that had already terminated because it
actually hasn't had the time to terminate yet in the existing test (but
this will be changed soon). And calling Delete() on a thread which
really did already terminate resulted in error messages because it tried
to wait on an already invalid thread handle and ended up by returning
wxTHREAD_KILLED which was wrong (killing a dead thread failed too) and
was different from wxTHREAD_NO_ERROR expected by the test.
Fix this by not closing the thread handle when the thread terminates in
order to allow waiting for it again later, if necessary. This shouldn't
be a big deal because in normal circumstances the thread object will be
destroyed very soon, closing the handle anyhow. But the comment about
"not needing the handle any more" was wrong, as we may need it to get
the thread exit code again in the future.
This function was somehow being called too late, at least according to
TSAN, and resulted in a data race on the global wxAllThreadInfos vector
because the main thread could destroy it before the worker thread
exited, apparently.
It's not really clear how it happened but it seems that the dtor of a
local object in PthreadStart was called at unexpected moment, so don't
rely on RAII scope guard and just call ThreadCleanUp() manually right
before exiting the thread in Exit().
This mechanism is still fragile, not to say broken, e.g. we don't seem
to clean up thread-specific info at all if the thread is killed, but at
least we don't get TSAN data race warnings whenever a detached thread is
destroyed now.
We still need to use custom colours even if we don't have any user-set
colours when using dark mode, otherwise the colours reverted to the
normal ones for light mode (and hence wrong in the dark one) on DPI
change.
Closes#23322.
