Test runner was not properly handling tests which
return the control back to browser event loop.
It was treating such tests as if they exited with
code 0, marking them as succesfull even if they were
eventually failing or hanging.
This commit adds a callback to TestCase so the runner
is notified when a test truly has finished.
As a side effect, two tests need to be disabled for now
as they are failing for wasm, which was not properly
detected previously.
Change-Id: I0eb9383e5bb9cd660431c18747b9e94413629d1e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It's legacy method marked as internal.
There are zero occurrences of "isSimpleText"
anywhere in Qt or Qt Creator other than qstring.*
Change-Id: I4961b7b2539fb6552484e77fbea58ba0e6656921
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
WASM has been added as a definition.
Add it in the comment section as well.
Pick-to: 6.6 6.5
Change-Id: Id86520cad4c12d83234cc71a00cd3e484e2895dc
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
VxWorks elf.h (nor any other header in its SDK) doesn't contain
definition of PN_XNUM, which meaning is the limit of program headers in
ELF structure, related to `e_phnum` field of `Elf{32,64}_Ehdr`
structures. Since these fields have identical type and seemingly
identical meaning, we can safely assume that its maximum value will be
the same on both systems.
Define PN_XNUM if it's not defined with `0xffff` value taken from
Linux and Solaris related headers.
Fixes: QTBUG-118135
Change-Id: I5a0dab1d1d18e165d01e80823a02f7df644fc7e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There's logic in QMessageBox to resolve the default and escape button
if not set by the user. And the user may of course override these.
We now propagate the resulting buttons via the dialog helper, and
pick them up in the macOS native dialog backend. The only common
information we have between the standard buttons and custom buttons
is the button identifier, which for standard buttons is the enum
value, and for custom buttons is an auto generated identifier.
The same identifier is used when reporting the clicked button
from the native dialog helper.
Fixes: QTBUG-118308
Pick-to: 6.6 6.5
Change-Id: I5ca45604b51f0bbf74e56134d7b55bb8911f3563
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QDialogButtonBox has logic to automatically resolve a default button,
in case one is not already set via QPushButton directly, or via e.g.
QMessageBox::setDefaultButton().
Unfortunately, this default button can in some cases be overridden by
the first button in the dialog button box. The reason this happens
is that the first button is the focus proxy of the button box, so
when the button box gains focus, it will transfer it to the first
button. And since QPushButtons inside a QDialog have their autoDefault
property set to true by default, this focus transfer will also reset
the default button to the focused button.
This arbitrarily happens for any role that happens to be earlier in
the QDialogButtonBox::ButtonLayout than the AcceptRole, and can be
very confusing for the user, so we try to avoid the situation by
explicitly setting the automatic default button as the focus
widget of the button box, unless one is set already.
This is also what QMessageBox::setDefaultButton() does internally.
The only case we're not covering is when the user sets a push button
as default via QPushButton::setDefault(), but we conservatively
assume that the user then also calls setFocus() on the button.
Pick-to: 6.5 6.6
Change-Id: Ibdac0a51ba9439321d4fd7a1dac1ed695e11d693
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The native message dialogs are shown in QMessageBox::setVisible,
instead of plumbed via e.g. QWidgetPrivate::show_sys (which is not
virtual). And we try to show the native dialog before we call the
base class QDialog::setVisible(), where we end up sending the show
event.
As the native dialogs might rely on the last minute setup of adding
an OK button or detecting the escape button, we need to do it in
setVisible instead.
We can not switch the order of showing the native dialogs after
calling the base class setVisible (and getting showEvent), as
we need to know whether the native dialog could be shown or not
to decide whether to show the fallback widget dialog.
The part from showEvent that added the detailsButton has been
removed, as we're already doing that in setDetailsText().
Pick-to: 6.5 6.6
Change-Id: I23f1d87d542d9dadfd71924f8119c22720f4b276
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
So far, only accessible interfaces of roles QAccessible::Dialog
and QAccessible::Window were taken into account when trying to
find the top-level window in order to calculate the window-relative
coordinates relative to that one.
However, an app doesn't necessarily need to have any such widget/
window as it's top-level object, but can have any widget there.
Therefore, consider any a11y object that is a direct child of the
application's a11y object a top-level window as well.
For example, in the spinboxes example
(qtbase/examples/widgets/widgets/spinboxes/spinboxes), the top-level
widget is a QGroupBox, which has an accessible role of QAccessible::Client,
which maps to ATSPI_ROLE_FILLER for AT-SPI on Linux.
Since that's the top-level widget, window-relative coordinates
should be calculated relative to it.
(Without this change in place, screen coordinates would be
used for the window-relative coordinates as well, as found by
the script attached to QTBUG-106527.)
Also deduplicate a bit and just have a single loop instead
of the extra check on the interface itself at the beginning.
Fixes: QTBUG-106527
Pick-to: 6.6 6.5
Change-Id: I8d2a00bcc22c71d696e4f48233afddc80e93bc1b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Investigating QCocoaWindow::setVisible idempotence revealed that our
QCocoaEventDispatcherPrivate::beginModalSession() implementation would
happily add the same window multiple times, resulting in trying to
re-start a modal session for the same window when the window was
closed, confusing AppKit's logic for choosing the next key window
when a modal window is closed.
We now bail out if we detect this scenario, even if setVisible has
been fixed. Additional logging has also been added.
Pick-to: 6.6 6.5
Change-Id: I07418c12b421fb0b4ebf875050e32f56fdad6197
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Some of the datatype mappings for Mimer SQL are wrong and some are
missing. Also, fix the datatype documentation for Mimer SQL.
Fixes: QTBUG-111219
Pick-to: 6.6
Change-Id: Ic7edaaca9af9b3b480079b04b05c58ab22f34fa3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Use addIconFiles() instead repeating the addIcon() function with every
size to avoid copy'n'paste errors and make the whole stuff more
readable.
Task-number: QTBUG-118122
Change-Id: I71ab5ca0526024c6f96e20871018b4af43dac3bf
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The first/last/sliced API may be what we suggest users use, but the vast
majority of the installed codebase uses left/mid/right because they've
been available since time immemorial.
An additional benefit of this is to make left() and right() available as
inline methods.
Change-Id: Ifeb6206a9fa04424964bfffd1788383817ed906c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Those ought to have been the original implementation, when they were
added in commit 38096a3d70, for Qt 6.0.
Because these classes are exported, we need to provide the previous only
implementations for MSVC. All other compilers would provide inline or
emit local, out-of-line copies.
Change-Id: Ifeb6206a9fa04424964bfffd178836a2ae56157d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It's by far the most common use, so having to call two things is just
cumbersome.
Change-Id: I79e700614d034281bf55fffd178f454c4e31929e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
- remove unused variable
- port index-based loop to range-based for
- use const method more to avoid implicit detach
Change-Id: I223f6c221d0c6277e94efd2e7b7be0f8d8456c60
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The test that needs this bool is using 2013, so test that year for a
match. (Africa/Tunis toyed with DST in 1990, the year used before, but
thought better of it.) In the process, move the initialization to the
member-initialization of the class and make the member const.
Change-Id: Ib87636cdb0b038fad0cdef9fbe49e96f7bf79d1f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Qt ModuleConfig.cmake files set variables like <package>_INCLUDE_DIRS,
<package>_DEFINITIONS, etc., which can be used by user projects to
acquire the module related information. These variables also accumulate
information from Qt Module dependencies. Since we do not separate the
Private and regular modules in dependency list, the resulting variables
contain values from both. This change puts the information from Private
dependencies to the variables of Private module. The exception is
PRIVATE_INCLUDE_DIRS which will contain include directories from Private
dependencies for non-Private module too.
Fixes: QTBUG-118462
Change-Id: I51e6d63651ed1913005064c90f77eba219cf60ea
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
BlobIoDevice: Supports reading data from a JS Blob,
which can be a File (on disk) or some other object
which can provide data. The native access functions
are async and using this class requires that asyncify
is available.
Uint8ArrayIODevice: Supports reading and writing to
a Uint8Array / ArrayBuffer. Similar to the existing
QByteArray::fromEcmaUint8Array() API, except that it
supports incremental accesss.
Change-Id: Ic5de3534ff75eb6c745287b73b15ccd92d74ac2c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The loop was breaking one button too early.
Pick-to: 6.5 6.6
Change-Id: Ic5027a2e4e35fbd54bf25b310768fd3278d4874b
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
As explain in detail in 1bde203605, AppKit
doesn't treat non-direct transient parents of a window modal window as
being blocked by that modal window, but Qt does. To align with Qt, we
worked around it by returning NO from canBecomeKeyWindow for windows
that were blocked by a modal window.
This however had an unintended side effect for native dialogs, due
to the way we hide these dialogs. When a native dialog is closed,
AppKit will look for another window to make key, and as part of that
it checks canBecomeKeyWindow. The problem is that the modal blocked
status has not been updated in QGuiApplicationPrivate at that point,
so we tell AppKit it can't make the transient parent key.
The modal blocked status is only updated once we hit QWidget::setVisible,
at which point dialogs like QMessageBox and QColorDialog has already
called setNativeDialogVisible(false) in its setVisible() override,
triggering the close logic described above.
To fix this properly we need to have the dialogs call the base class
first when hiding, and then setNativeDialogVisible(), and also have
the macOS native dialog helpers react to hide() by ordering out the
window in case it didn't work at an earlier point. This kind of
change is risky for Qt 6.5/6.6 however, so we opt for a simpler
solution for now.
By limiting the original workaround for non-direct transient parents
not being blocked to just those transient parents, and only for window
modal dialogs, we avoid the issue with failing to transfer key status.
Task-number: QTBUG-104905
Fixes: QTBUG-118320
Pick-to: 6.6 6.5
Change-Id: Iabbca0b74a7db4e9821a9b60730d01fbad1425db
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The implementation of QCocoaWindow::setVisible is not idempotent,
as for modal windows it calls beginSheet/endSheet or starts/ends modal
sessions, which will confuse the AppKit modal session stack.
Once a window has been shown QWindowPrivate::setVisible hides/masks this
issue, by returning early if the visibility has not changed, but during
first show QWindowPrivate::setVisible will update the QWindow state,
before creating the platform window. If the platform window then picks
up the QWindow's visible state during creation, it will result in one
QPlatformWindow::setVisible() call during creation, and another one
via QWindowPrivate::setVisible after the platform window has been
created.
To fix this we can check the existing NSView.hidden state and skip
the setVisible call if it's already up to date. But one complication
is that our QCocoaWindow::setVisible has different behaviors depending
on whether the window has been initialized yet or not, due to how
handleGeometryChange skips sending geometry changes for uninitialized
windows. So we need to also bail out if we're still initializing the
window. This is fine, as we know we'll get a follow up setVisible
call via QWindow, both when QWindow itself creates the platform window
as part of setVisible, as well as when the user does a two step create
and then show.
For good measure we throw in a recursion check as well, in case some
of the logic in QCocoaWindow::setVisible before we update NSView.hidden
recurses back into QCocoaWindow::setVisible.
Pick-to: 6.5 6.6
Change-Id: Ibdcf4859e58d6684aac4490126d35eb12fdd5943
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This reverts commit 6a93ec2435.
Reason for revert: Breaks qtdeclarative build, submodules need
to be clean before we deprecate or remove APIs.
Change-Id: Id0726b9bfad6072065b380b44b6ff6dffda79e45
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The test is testing whether the order of creating a child window
of a modal dialog and showing the parent dialog matters. But to
allow child windows of a modal dialog to become active that child
also needs to be a dialog. That's a limitation on macOS, where
only NSPanel subclasses can override worksWhenModal.
Fix the test, and rewrite it using more modern idioms, avoiding
the need for long waits in the test.
Pick-to: 6.6 6.5
Change-Id: Ifb640d0288a3c7ed37f2c61294e34cd96fba49ca
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Amends 2d59f2e8ca, which only checked
this for custom buttons, but standard buttons can also be customized.
Pick-to: 6.5 6.6
Change-Id: Ie8bafcf5007a0b4789b2d0ee1ddbc660a952fee4
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This reverts commit bb23a05905.
Reason for revert: this change resulted in a flood of build-breaking
warnings in submodules that need to be cleaned up before we try again.
Also, the discussion following this change shows that this needs more
clarification of the implications and options. Until that is concluded,
the status quo is acceptable.
Change-Id: Id8f67ed585517935c31e29d48099b1c84b787b74
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Starting from qt-6.6.0, the childStack size has been too small to run
qmake or qsb in the sandbox, which will cause segfault.
This problem can be fixed by changing the childStack size to SIGSTKSZ.
For security reasons, some Linux distributions, such as gentoo, will
use the sandbox when building applications. Previously, qt-6.5.0 could
be successfully built in the sandbox. The problem started with qt-6.6.0.
See also: https://bugs.gentoo.org/915695
Pick-to: 6.6
Change-Id: I229c25397f557dd2fec3e0ec53ac68fda28bab13
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the application has already attached to the console, the
AttachConsole() API will fail but we can still redirect our
output to the console. The previous code doesn't take this
case into consideration, now it's covered by this patch.
Please refer to the "Remarks" section:
https://learn.microsoft.com/en-us/windows/console/attachconsole
Pick-to: 6.6
Change-Id: I1c5033cc962dcd5a757ff15cc677a51e21330e0b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These special member functions have no purpose.
We never *documented* their semantics. Any code using them is
unconditionally wrong (which semantics was it assuming?), so we can
accept the SIC (type A). If a user needs such a copy, they would have to
reason on the intended semantics (relaxed? acquire/release?) and be
explicit in their code. Especially for assignment, they would need
understand the consequences of the memory ordering that apply on _each_
atomic object involved and not on the assignment operation as a whole
(there are no such semantics).
Testing this change on qtbase has already found bugs.
From a purely technical point of view: we don't guarantee lock-free
atomics nor we require them from the underlying platform. An atomic is
therefore allowed to be implemented as a mutex protecting a value, and
mutexes are not copiable. std::atomic follows the exactly same pattern
(not copiable nor copy-assignable) for exactly the same reasons, and Qt
atomics are implemented on top of std:: ones.
[ChangeLog][QtCore] The copy constructor and assignment operators of
Qt atomic classes (QAtomicInteger, QAtomicPointer) have been removed.
Their usage in user code should be considered a programming error, as no
memory ordering semantics were ever documented for these operations (and
therefore relying on any specific semantic would be relying on
undocumented, unportable behavior). This matches the API of the
std::atomic class in C++. Note that you can still use explicit
load/store operations to transfer a value across two Qt atomic objects,
and therefore use the memory ordering specified for the load/store
operations.
Change-Id: Iab653bad761afb8b3e3b6a967ece7b28713aa944
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- Fix method name, it starts with a small letter
- Improve grammar in one sentence
- Use "INTEGRITY", less ambiguous and that's how their web site spells
it
Change-Id: Icfca9d7ebe64cd2f012456507ebf65c1e62f9e9d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Make the strings in the stringlist-to-be-joined unique, which matches
actual use-cases better than joining a list of identical strings,
especially with QString's implicit sharing, if it's copies of the same
QString, it's sharing the underlying data.
Pick-to: 6.6 6.5 6.2 5.15
Task-number: QTBUG-116859
Change-Id: I1da93885e938045322ba8337df5e4e96985f892f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: Ief76068a37d32759666e3aa2a24f126f18eca88b
Reviewed-by: Hatem ElKharashy <hatem.elkharashy@qt.io>
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
AppKit doesn't do this automatically for us, and since we may have
decided to not draw anything when the view was not exposed, we need
to inform clients that its time to draw something now.
Pick-to: 6.5 6.6
Change-Id: Ib2dd969632898ba5640d6848356acd1b97da652d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
When adding custom buttons to a QMessageBox the return value of exec()
as well as result() is not a StandardButton value, but instead an opaque
value, and the documentation says to use clickedButton() to determine
which button was clicked.
Pick-to: 6.6 6.5
Change-Id: Ib47a218989b4dcb5d51f648bc55bc02399bae602
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Then we can easily test how fromLocal8Bit() and toLocal8Bit() behave
with different code-pages.
Pick-to: 6.6 6.5
Task-number: QTBUG-118318
Task-number: QTBUG-118185
Task-number: QTBUG-105105
Change-Id: Ib1cd3bccd27d598f4c80915557e332befcd96354
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A bug in Xcode 15 adds duplicate flags to the linker. In addition, the
`-warn_duplicate_libraries` is now enabled by default which may result
in several 'duplicate libraries warning', and build failure if
`-Wl,-fatal_warnings` is passed. By adding the newly introduced
flag, `-no_warn_duplicate_libraries`, to the linker we can suppress the
warnings, and possible fatal error caused by this bug.
Change-Id: I65e06ea039a6e98b02ed1f9112c622ecc6a142b5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
There's no plumbing in QMessageDialogOptions for supporting
native dialog buttons with menus, and even if there was such
plumbing, we don't know if our native dialogs could support
them.
As a workaround, detect the situation and automatically fall
back to the non-native dialog, so the user doesn't need to
set Qt::AA_DontUseNativeDialogs explicitly.
Fixes: QTBUG-118419
Change-Id: Iece7012909261b8869ce0ca23e45e8daaf4babc7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
After c80f262258 commit (which fixed
selection for read-only texts), checking if m_handleMode is Hidden was
removed. Because of that hidding cursor handle stopped work correctly.
This commit brings back check if m_handleMode is Hidden.
Also when only one handle is visible, it should be hidden within the
next 5 seconds regardless for keyboard visibility. That is how it is
handled in pure Android apps.
Pick-to: 6.6 6.5
Fixes: QTBUG-117367
Change-Id: I0400f9604234bfad7fe17d74673ae9a93088bab4
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
The 'dependencies.yaml' file contains entries that aligned with the
repository naming but not the Qt projects naming. When parsing
it to collect the dependencies for the standalone repo we should
cut the 'tqtc-' repo prefix to avoid malformed names in
QT_REPO_DEPENDENCIES variable.
Pick-to: 6.5 6.6
Change-Id: If80e61394f245f09b620a9210246053d4e475f86
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Remove qt_poll_msecs() since the "forever" state can be simply expressed
with a QDeadlineTimer::Forever arg, instead of passing a nullptr
timespec, and the negative timeouts treated as "run forever" is also
encapsulated by QDealineTimer.
Use the QDealineTimer(qint64) constructor in the call sites where
the timeout could be negative, so that it creates a Forever timer (the
QDeadlineTimer(chrono::duration) constructor uses
setRemainingTime(duration) which handles negative timeouts by creating
expired timers).
Remove qt_gettime() (and do_gettime()).
Drive-by changes:
- Fix a narrowing conversion warning, qt_make_pollfd() takes an int
- Remove an unused include
Change-Id: I096319af5e191e28c3d39295fb1aafe9d69841e6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We only have two tools that use the Bootstrap lib and neither of them
need nor want the message pattern functionality.
Change-Id: Ifa1111900d6945ea8e05fffd177e191ebb6afc4f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Instead of the exported qFormatLogMessage() that users can use. Because
it's a local symbol (static function), neither dladdr() nor
backtrace_symbols() functions should be able to see them, making their
exclusion from the list a simpler check.
This doesn't apply when the user calls qFormatLogMessage() in their own
handler, unless the compiler either inlines or tail-calls the new,
internal function. The latter case is very likely.
Change-Id: Ifa1111900d6945ea8e05fffd177e187f55512725
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Instead of only printing to stderr or the Windows debug buffer. I guess
this wasn't done before because the code could recurse back and cause
stack overflows. We can do it now without recursion problems.
Change-Id: Ifa1111900d6945ea8e05fffd177e14e2f86ae482
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Instead of duplicating its stderr handling.
Change-Id: Ifa1111900d6945ea8e05fffd177e149dfa9afff9
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
