Unless "." (or the empty string) is in $PATH, we're not supposed to find
executables in the current directory. This is how the Unix shells behave
and we match their behavior. It's also the behavior Qt had prior to 5.9
(commit 28666d167aa8e602c0bea25ebc4d51b55005db13). On Windows, searching
the current directory is the norm, so we keep that behavior.
This commit does not add an explicit check for an empty return from
QStandardPaths::findExecutable(). Instead, we allow that empty string to
go all the way to execve(2), which will fail with ENOENT. We could catch
it early, before fork(2), but why add code for the error case?
See https://kde.org/info/security/advisory-20220131-1.txt
Origin: upstream, commits
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=3186ca3e3972cf46
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=408656c6f9de326c
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=ae6590e360fbb04d
and a small part of
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4c0f81490ba0c4ec
Last-Update: 2021-12-09
When stroking a dashed path, an unnecessary amount of processing would
be spent if there is a huge number of dashes visible, e.g. because of
scaling. Since the dashes are too small to be individually visible
anyway, just replace with a semi-transparent solid line for such
cases.
The MariaDB-connector-c version 3.2 and MariaDB server version 10.6
cooperate to avoid re-transferring the query metadata, so the fact that
we were modifying it was causing it to improperly decode the DATETIME
data types into string, as we had asked. We ended up with a 7-byte
string that was actually the date binary-encoded.
When calling setStyleSheet with property qproperty-styleSheet,
QStyleSheetStyle::polish will call QStyleSheetStyle::setProperties,
and then QStyleSheetStyle::setProperties goes on to call setProperty.
Because there is property qproperty-styleSheet, it will update
stylesheet by calling QStyleSheetStyle::polish.
This causes the recursive call to crash.
[PATCH] xcb: add a timeout control when reading INCR property
For the first call of QXcbClipboard::clipboardReadProperty()
inside of clipboardReadIncrementalProperty() in getSelection(),
it will get a XCB_NONE reply before the contents arrived via
property change. Then we give a chance to read more.
Manually tested with following setups:
* examples/widgets/mainwindows/application with gvim(gtk3)
* examples/widgets/widgets/imageviewer with GIMP 2.10.18(based on
gtk2) and GIMP 2.99.6(based on gtk3 via flatpak)
Fixes: QTBUG-56595 Pick-to: 5.12 5.15 6.1 6.2
Done-With: JiDe Zhang <zhangjide@uniontech.com>
Change-Id: Ib45f08464d39ad79137b1da99808c89b7dca2d08 Reviewed-by: JiDe Zhang <zhangjide@uniontech.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Gbp-Pq: Name xcb_add_a_timeout_control_when_reading_INCR_property.diff
MariaDB library version 3.2 no longer returns the server version in the
10.x range but the library version itself, which is lower than 4.x. That
meant we concluded the server did not support prepared statements.
And because of the lack of prepared statements, all QDateTime
conversions failed, because of the timezone. I don't know if this was
intended or what, but it's a side issue.
The fusion style did ignore the QIcon::On icon because it reset
State_On to avoid the visual shift of a pressed button.
But it's not needed to reset this flag - the shift does not happen
because the fusion style does return 0 as offset for
PM_ButtonShiftHorizontal/PM_ButtonShiftVertical so no shifting will
happen.
After dc794f7622bc00f7ca50fab65d6965695d6d2972, side widgets only got
space if they were not fading out, but the logic was not correctly
accounting for side widgets that never fade, such as buttons added via
QLineEdit::addAction.
Fix this to give visible widgets space, unless they are fading out. That
was the intent of the original change. Rename the variable to make its
purpose clearer, and reset it at the end of the fade-out animation.
Add a much-needed test that relies on private APIs to verify that the
effective margins are calculated correctly.
Gbp-Pq: Name fix-placement-of-placeholder-text-in-QLineEdits-with-action-icons.diff
The placeholder text was rendered in the wrong position after clicking
on the clear button in a QLineEdit with right-to-left content. The
button was still taking up space while it was fading out, so the first
paintEvent rendered the placeholder with space reserved for the clear
button. Once the button gets hidden, no new update was issued, so
garbage was left behind.
Fix this by not giving a fading-out clear button any margin space. The
result of this is that the placeholder text is visible underneath the
fading-out clear button. This is preferable to the placeholder text
being first rendered next to the fading-out clear button, and then
popping to the edge when the clear button is hidden (which would have
been the result of issuing a complete update for the line edit at the
end of the fade-out animation).
Gbp-Pq: Name fix-misplacement-of-placeholder-text-in-QLineEdit.diff
When multiple globs match, and the result from magic sniffing is
unrelated to any of those globs, globs have priority and one of them
should be picked up.
* Backport upstream changes to improve support for OpenSSL 3.0.
- Don't hardcode libssl version in Depends, fill it dynamically.
* Replace -ffile-prefix-map in qmodule.pri.
* Backport upstream patch to make QProcess not search for executables in
CWD unless explicitly told so (CVE-2022-25255).
* Update some Lintian overrides.