Clipboard formats containing plain text are specified to be terminated
by a \0 character in MS's documentation on standard clipboard formats:
https://docs.microsoft.com/en-us/windows/desktop/dataxchg/standard-clipboard-formats
xf_cliprdr_server_format_data_response receives pasted data from the
server to transfer to the client, in a sufficiently raw form that the
\0 terminator is still present, so it has to remove it. It does so by
checking only at the very end of the data. But I've observed that when
pasting out of at least one Windows program (namely Outlook 1903 on
Windows 10), the intended paste data arrives in this function followed
by \0 and then a spurious \n. In that situation the null-terminator
removal will fail to notice the \0, and will leave both bogus
characters on the end of the paste.
Fixed by using memchr to find the _first_ \0 in the paste data, which
should not lose any actually intentional data because it's in
accordance with the spec above.
The file clipboard delegate needs a base URI to operate on for
systems that are not WIN32. Added that to the context and abort
conversion, if that is not set. (currently not fully implemented)
[client/X11/xf_floatbar.c:800] -> [client/X11/xf_floatbar.c:796]: (warning) Either the condition '!floatbar' is redundant or there is possible null pointer dereference: floatbar.
[client/X11/xf_floatbar.c:800] -> [client/X11/xf_floatbar.c:797]: (warning) Either the condition '!floatbar' is redundant or there is possible null pointer dereference: floatbar.
[client/X11/xf_floatbar.c:800] -> [client/X11/xf_floatbar.c:798]: (warning) Either the condition '!floatbar' is redundant or there is possible null pointer dereference: floatbar.
[libfreerdp/codec/dsp.c:1156] -> [libfreerdp/codec/dsp.c:1154]: (warning) Either the condition '!srcFormat' is redundant or there is possible null pointer dereference: srcFormat.
[channels/drdynvc/client/drdynvc_main.c:1453] -> [channels/drdynvc/client/drdynvc_main.c:1450]: (warning) Either the condition '!drdynvc' is redundant or there is possible null pointer dereference: drdynvc.
[channels/audin/client/opensles/audin_opensl_es.c:98] -> [channels/audin/client/opensles/audin_opensl_es.c:94]: (warning) Either the condition '!opensles' is redundant or there is possible null pointer dereference: opensles.
[channels/audin/client/opensles/audin_opensl_es.c:159] -> [channels/audin/client/opensles/audin_opensl_es.c:153]: (warning) Either the condition '!opensles' is redundant or there is possible null pointer dereference: opensles.
Up until now X11 mouse button remapping was only possible for the
default buttons 1 to 3.
With this pull any X11 mouse button can be mapped to any RDP mouse
event and all X11 remappings are respected.
The cause is very simple: we didn't map the xwindow on receiving
WINDOW_SHOW. but doing that causes another problem that you can't
hide a window anymore, and that is because whlie window hiding, the
_NET_WM_STATE and WM_STATE properies of the xwindow may change, in
the function `xf_event_PropertyNotify` we just assume that windows
not maximized, not minimized, yet not showing normally should be
corrected to be shown, we just need to consider the situation that
the window is hidden here.
fix: #5078
The extended information provided by VerifyCertificateEx and
VerifyChangedCertificateEx is now exploited by the new functions
client_cli_verify_certificate_ex and client_cli_verify_changed_certificate_ex.
The old callbacks now print out deprecation warnings to inform the
user and developer about this deprecation.
To fix#4825 GFX functions must now aquire a lock before accessing surfaces.
This prevents simultaneous update of internal data by client and gfx threads.
Also enforce return value checks, where not already done.
Added a library internal function freerdp_settings_set_default_order_support
which initializes the OrderSupport array of settings.
Now clients no longer need to set this up on their own, if they
do not implement their own hardware accelerated order processing.
With #4950 client side pointer implementation was made optional.
This addresses an issue that each client had to call
pointer_cache_register_callbacks on its own.
