There doesn't seem to be any reason to have this constant, so don't
define it and just interpret empty value of backend as meaning to choose
the default one in wxWebSession::New().
At least in one place the code is still wrong when sending data as HTTP
headers can contain only ASCII characters, but at least do our best to
interpret the data we receive correctly.
Don't just silently ignore invalid user data value, this is not supposed
to happen.
Also use "userdata" name for the same parameter of all callbacks
consistently.
As this flag is tested in the worker thread only when it owns the mutex,
set it only after acquiring the mutex too to avoid any possibility of a
data race.
Call SetState(State_Active) before signalling the worker thread, as
otherwise it would be possible for it to wake up and set its state to
something else before it was reset to "active" from the main thread.
This fixed another TSAN error.
As in 31a441e814 (Use separate test cases for wxWebRequest auth tests,
2021-01-10), there is no real reason to use sections here as we don't
reuse anything between them and using separate tests makes it easier to
run individual tests and, especially, combinations of them.
This commit is best viewed ignoring whitespace-only changes.
Mutexes must not be destroyed while locked and thread sanitizer
correctly complains about this, so ensure that we do unlock the mutex
before the worked thread terminates and the object is destroyed.
Also use critical section instead of a mutex, as this is more efficient
under MSW.
Main purpose of this commit is to make it clear that this mutex/critical
section is only used together with the data from the same struct.
No real changes.
Don't use system libcurl if --disabled-sys-libs was used, but warn about
it as this could be unexpected.
We could consider including libcurl as submodule, and use the built-in
version as a fallback, but it's a relatively big repository (100MiB+),
so it's not clear if it would be a good idea to do it.
This allows to easily run both auth tests at once without all the other
tests and it's not like we reuse much (or actually anything) by having
them as sections in the same test case anyhow.
This commit is best viewed ignoring whitespace-only changes.
Just sort the features in the same section in alphabetical order to make
it easier to find the given feature in the list (or confirm that it is
not present).
No real changes.
Use tool position as offset from group position and not vice versa, both
because this was already done like this in the other places and because
this makes more sense: the tool is inside the group, so its position is
relative to it.
No real changes.
Don't update wxRibbonToolBar and wxRibbonButtonBar tooltips each time
the mouse was moved, this was inconsistent with the standard tooltips
behaviour and resulted in flicker.
Also don't show tooltips at all over a dropdown, as they partially
covered and, again, such behaviour is very non-standard.
Closes https://github.com/wxWidgets/wxWidgets/pull/2162
This allows to write the code using this class without peppering it with
wxUSE_SECRETSTORE checks that would otherwise be necessary to support
Unix builds on system without libsecret.
No real changes.
No real changes, just try to avoid over long lines.
Also use early returns in case of WinHTTP functions failures everywhere
for consistency.
This commit is best viewed ignoring whitespace-only changes.
This allows to avoid using temporary variables just to be able to pass a
pointer to them to WinHttpSetOption().
No real changes, just a simplification.
This doesn't seem to be needed, our callback has the correct signature.
If it's required for some non-MSVC compilers (e.g. MinGW with old SDK),
it would be better to use the cast only conditionally to at least keep
the MSVC build type-safe.
It seems better to rely on the well-tested WinHTTP URL parsing functions
rather than on our own wxURI. It should also allow to support any new
URI schemas if support for them is ever added to WinHTTP.
No real changes, just avoid using raw numbers, which is not very
readable, notably for HTTP_STATUS_PROXY_AUTH_REQ which is not really a
well-known value.
