Bitmaps stored in the list as a result of replacing existing ones should
conform to the same constraints as bitmaps directly added to the list.
These constraints are applied in the shared GetImageListBitmap() function
called both on adding and replacing the images.
This is helpful when trying to understand what is going on, especially
because CFNETWORK_DIAGNOSTICS, which is supposed to do the same thing at
native level, doesn't seem to work (at least under 10.14).
Wee need to assure that bitmap added to the internal collection always
have a mask. If necessary this mask is created from alpha channel values.
Also, for compatibility with wxMSW implementation we need to prevent
the bitmap from having both a mask and alpha channel.
If wxBitmap with mask is added to wxImageList that doesn't support masks
we need to convert a bitmap mask to alpha channel values prior to adding
bitmap to the list to preserve bitmap transparency.
If wxBitmap with mask is added to wxImageList that doesn't support masks
we need to convert a bitmap mask to alpha channel values prior to adding
bitmap to the native list to preserve bitmap transparency.
Closes#19036.
This is shorter and doesn't imply that just the name (and not the full
path) is being returned.
Also rename wxWebResponse::GetFileName() to GetDataFile() for the same
reasons and for consistency. And document this previously undocumented
method.
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.
