It can actually be undefined, so test for that before checking
the object type.
This fixes the asyncify build.
Pick-to: 6.4
Change-Id: I5a6a0bc60c153290c35c20242400c59cd1312403
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Also add support to expandable/expanded states to QAccessibleComboBox
in widgets. QtDeclarative will still require updates so that QML combo
boxes report the expanded/collapsed state and react to UIA actions.
Task-number: QTBUG-103591
Pick-to: 6.4 6.3
Change-Id: Iff8ba5e3143778ce17998dbe7f5f76cae658dc19
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QXcbConnection::sync is a full equivalent of calling XSync with false,
they both are sending GetInputFocus request and getting its reply
Pick-to: 6.4
Change-Id: I4f91b9447a02def41a8693a54312856b56e74811
Reviewed-by: Liang Qi <liang.qi@qt.io>
For example, when having virtual monitor which includes two real
monitors, the primary information in xcb_randr_monitor_info_t
is normally false, because user can only set it for output.
Kudos to Jiang Wu for his first patch and details of the issue.
Done-with: Jiang Wu <wujiang@kylinos.cn>
Pick-to: 6.4 6.3
Change-Id: I6af443ff69d347a6d86efc9c8ea7a5d18f4c3e24
Reviewed-by: JiDe Zhang <zhangjide@uniontech.com>
Reviewed-by: Jiang Wu <wujiang@kylinos.cn>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Regression introduced in 9a4c98e55659b32db984612e6247ac193812a502:
m_cursor is not initialized and never set when monitorInfo is not
available in QXcbScreen::setMonitor. This seems to happen when running
in VNC, e.g. on a Raspberry Pi.
This usually results in crashing the application pretty soon.
Using a unique_ptr solves both the initialization and a possible leak
when setMonitor is called multiple times.
[ChangeLog][Linux/XCB] Fixed crash when no monitorInfo is available (e.g. VNC).
Fixes: QTBUG-104443
Pick-to: 6.3 6.4
Change-Id: If13493c177121a1994b5d00dfbd64f1da694df2e
Reviewed-by: Liang Qi <liang.qi@qt.io>
In combination with EGL_EXT_platform_xcb support, this allows xcb_egl
to be used without xlib. Without EGL_EXT_platform_xcb support, this
still reduces amount of code using xlib.
Pick-to: 6.4
Change-Id: I29e2b29f7ef8ea34320887f62697f84232b86fba
Reviewed-by: Liang Qi <liang.qi@qt.io>
In a lambda, capturing of `*this` by reference via `=` is deprecated,
and breaks the build. Capture everything needed instead.
Amends fb981a0954.
Change-Id: I5d3d192e71662b96154cb5979898277bd0720a90
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Recent changes on load speed of individual assets made
AndroidAbstractFileEngine use a cache for basic information in order
to avoid to have to open assets every time a QFileInfo is created,
which was very expensive for older phones.
However, size() method was forgotten and continued to expect that the
asset would be opened first, and therefore QFileInfo().size() would
always return -1.
This change fixes this by caching as well the information about the
size of the asset, and also reverts a part in open() to close() first
in case asset would already be opened, in order to keep previous
behavior (even if this did not cause any known issue).
Fixes: QTBUG-104412
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I992f31b8f9e14dfec44cec78d0c1a2a3e18bdb7f
Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It seems this block of code was originally copied from elsewhere
so the original indention is preserved.
Pick-to: 6.4
Change-Id: I53ab8e58b4304dfc768bd6472255a6c2d0471d5e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The WM_DISPLAYCHANGE message it sent when displays are added, removed,
or update their properties such as the scale/DPI.
We were processing this message as part of QWindowsContext::windowsProc(),
which meant that we would only react to display changes if there was a
QWindow on screen. Just creating a QGuiApplication was insufficient to
pick up changes to screens after startup.
In addition, despite being documented to post messages to child windows,
WM_DISPLAYCHANGE only ends up in top level windows. Presumably it's the
top level window's responsibility to post the message to child windows.
As a result, if a QWindow was a native child window of a foreign window,
such as in audio plugins being hosted in a DAW, we would again fail to
pick up display changes.
We solve both these cases by decoupling the WM_DISPLAYCHANGE handling
from QWindowsContext::windowsProc(), by creating a dedicated window
for listening to WM_DISPLAYCHANGE. This is similar to how we already
handle tray icons, power notifications, clipboard, etc -- the only
difference being that since purely HWND_MESSAGE windows do not
receive WM_DISPLAYCHANGE it's an actual invisible WS_TILED window.
This also lets us remove the workaround for QTBUG-79248, which was
doing screen updates in response to WM_DPICHANGED when detecting
that there were no QWindows.
Task-number: QTBUG-103383
Task-number: QTBUG-79248
Fixes: QTBUG-102343
Pick-to: 6.4
Change-Id: I905d8253069ec339b193edf05c052d21361ca3e9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
also remove duplicated function call to get Qt key for event
Pick-to: 6.3 6.4
Fixes: QTBUG-78826
Change-Id: Ibaf0dd3eb428b65280ed1f840a4849b44f2868e0
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
When QWidget::resize() is called on a maximized or minimized QWidget,
the window state of the widget and the corresponding QWindow is not
updated (i.e. remains maximized or minimized).
This patch updates the window state to Qt:WindowNoState when
setGeometry() is called in QWindowsWindow or QXcbWindow.
A test is added in tst_QWidget.
Fixes: QTBUG-104201
Pick-to: 6.4
Change-Id: I07491fb9293d13509573fc403750da0a50f6a785
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
According to
https://www.freedesktop.org/wiki/Specifications/XSettingsRegistry/.
Added support for Net/CursorBlinkTime Net/DoubleClickTime
Net/DoubleClickDistance Net/DndDragThreshold.
Change-Id: Ief208736ed2938792d935bfd730fefdd745394b6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Windows does not send WM_DPICHANGED to child windows, which means
that the normal DPI change handling code does not run for QWindows
which are embedded in a foreign, non-Qt, window.
Add code which handles WM_DPICHANGED_AFTERPARENT. This event is
sent to all child windows, but not the top-level window. Call
checkForScreenChanged() here, similar to what the WM_DPICHANGED code
does.
This commit does not add code to resize the child window, since
it is uncertain if this is the responsibility of the window which
receives WM_DPICHANGED, or of each child window.
Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Pick-to: 6.4
Task-number: QTBUG-103383
Change-Id: Icf85dd0afa806609dbbe0ffc36efbc5127962c39
Reviewed-by: <stefan.wastl@native-instruments.de>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
- shorten a couple extra long lines
- add space between functions
Pick-to: 6.4
Change-Id: I14ad7448372ba50f4b0299535c4261a5bbf415b7
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The QWSI APIs for reporting added or removed screens is not transactional,
so when several screens change at once Qt will see each screen change as
a separate state.
As a result, Qt, or the application itself, may react to the first of
many screen updates by moving a window to a different screen -- one
which is going to updated (removed) in the next iteration of QWSI
calls.
This caused trouble on macOS, where we use many different signals to
detect that the system has changed the screens, one of them being that
a window has been moved to a different screen.
In the scenario above, we would be in the process of updating screens
in response to the system going to sleep, which means all 3 connected
screens will be disconnected and replaced with one fake screen provided
by the system.
As we delivered the removal of the first QScreen, Qt or the application,
would respond by moving the window to one of the other two screens, which
in turn would recursively trigger another round of screen updates. This
round would then proceed to remove (and delete) all remaining QScreens.
When we then recursed back to the initial round of screen updates
we would continue iterating and operating on screens that had already
been removed, causing a crash.
Since we know that the screens will stabilize eventually, and that
QCocoaScreen has cached all info based on the displayId and NSScreen,
we can safely skip any recursive invocations of updateScreens().
Fixes: QTBUG-102021
Fixes: QTBUG-84741
Pick-to: 5.15 6.2 6.3 6.4
Invaluable-help-by: Bruno Cadoret <bruno.cadoret_1@signify.com>
Change-Id: I9ff96dbcbc6f308ad2729faf2db2de7ef08513c0
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Previously hover effects had to be enabled manually due to not being
enabled in the platform style. This change enables them by default.
Pick-to: 6.4
Fixes: QTBUG-88799
Change-Id: I014e1f5dfcd9b15656f11e12ab75a77d42f4815c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Found by codespell
Pick-to: 6.4
Change-Id: Ie3e301a23830c773a2e9aff487c702a223d246eb
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This change improves the loading speed of files stored in Android assets
folder by caching the information about files already opened.
Prior to the change, when creating a QFile or QFileInfo to an asset
file, the engine would first scan all the file's directory and parent
directories in order to cache all this in FolderIterator::m_assetsCache.
Due to the nature of Android assets, it might be very slow, depending on
the number of images in this tree.
In this patch, individual file accesses will stop using FolderIterator
and will simply open what is asked, caching the information about the
resource in order to avoid to have to call the expensive
AAssetManager_open if the file is accessed again (e.g. by QFileInfo).
Fixes: QTBUG-101161
Change-Id: Iaedf4cdf83d5116053b51895a6795d43bc60f942
Pick-to: 6.4 6.3 6.2 5.15
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
The rhiFlush() implementation currently assumes that
QWindow->devicePixelRatio() is the correct scale factor for
transforming device independent window geometry to source geometry.
However, this assumption does not hold if/when we add support
for drawing to a rounded-up DPR, with a downscale later in
the rhiFlush implementation.
Fix this by adding a sourceDevicePixelRatio argument to rhiFlush(),
which is set to either QWindow::devicePixelRatio() or
QWidget::devicePixelRatio(), depending on from where it is used.
Change deviceRect() and friends in qbackingstoredefualtcompositor.cpp
to be scale*() functions instead which take a scale factor instead
of a QWindow. Update call sites to use srouceDevicePixelRatio
where that makes sense.
Pick-to: 6.4
Change-Id: Idb7b1e2f36816a201e00f0defe100d2dc079cb17
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Example:
Error "BadWindow" (3) is raised by the XCB backend when a mouse event
is processed on a resource that disappears between posting and
processing of the event.
That constellation is harmless and can occur in async environments.
As XCB errors point to coding issues, this patch changes their logging
behavior from qCWarning to qCDebug.
Fixes: QTBUG-56893
Pick-to: 6.4 6.3 5.15
Change-Id: Idee5ee80efaf9cd6686448779f76c68d5e4c9b63
Reviewed-by: Liang Qi <liang.qi@qt.io>
Apple Silicon Macs no longer expose display information through IOKit.
Luckily we can use the 10.15 localizedName property on NSString to
resolve the name.
Pick-to: 6.2 6.3 6.4
Change-Id: Ie75430df1a80808cb7b23d97d1e440d1f3bf75d6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Accessing a display that's offline may cause crashes,
so to be on the safe side we skip update requests in
this situation.
Task-number: QTBUG-102021
Pick-to: 6.2 6.3 6.4 5.15
Change-Id: I6b48b6722bccde628e510c538943d14f2b0271e5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 might not be supported
on some legacy Windows 10 editions (prior Creator Update). In this
case SetProcessDpiAwarenessContext returns ERROR_INVALID_PARAMETER.
Fallback to DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE using old API
SetProcessDpiAwareness in such cases as the most suitable.
Fixes: QTBUG-103733
Pick-to: 6.3 6.4
Change-Id: I39216e63ecfcae96aaa159237a52b0a76bc5d956
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Terminating a thread that we don't have full control over might leave
mutexes or critical sections locked, ending up with an application that
can't allocate memory or open new windows.
Also, if terminating of the thread would fail (which the code tried to
handle), then deleting the QThread anyway would have triggered the
assertion that we don't delete a running thread in ~QThread.
So simplify this code: wait simply returns true if the thread isn't
running anymore, no need for the double-check. Leave the thread running
and leaking if it is stuck somewhere in Windows APIs while executing the
native dialog.
Fixes: QTBUG-103984
Change-Id: I34aa42cbde7c769a58c14bf524781cf3abd13b70
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We were querying the traitCollection property of the application's
keyWindow in order to determine the appearance mode (light/dark) of
the app.
However, the application may not have a keyWindow (visible window)
by the time the we set up the appearance mode, so get that information
from the last window in the application's windows array instead.
Change-Id: If7435d9f565b5c594a26027c971c16a1e3a9af26
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The crash was provoked by QThread::terminate() called
for QWindowsDialogThread from QWindowsDialogHelperBase destructor.
It's still not clear why terminating the thread here causes a crash,
but normally we should avoid terminating a thread anyway.
Current changes make several improvements to avoid terminating the
thread. The main problem was that QWindowsDialogThread::run() was never
returned. That's because QWindowsNativeFileDialogBase::close() was not
called on QWindowsDialogHelperBase destruction. The second problem
was that QWindowsNativeFileDialogBase::close() may still not close
native file dialog because it was not able to find HWND for IFileDialog
instance in some circumstances, so make this by more robust way.
Fixes: QTBUG-93298
Pick-to: 6.3
Change-Id: I55c8cf664ae2cf7c41c8cce43a6bb88a2680bf14
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
When testing, we need to query the state of the Qt application,
so change the scope of qtloader from inside the init function
to global scope.
Additionally, adjust the test script accordingly to query and use this
state to make good decisions on how to terminate.
Change-Id: I6264ba20843716eb87340b160680617b718f6bd9
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Added new function handleError which does the usual work whenever there
there is an error, including logging the error to console. Also make
the app exit when the emscripten module fails to load.
Additionally, make sure we correctly report it as crash
if the module fails to load.
Change-Id: I9d723373a34ccbb146959a2207ebded8bcbd4f18
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Replace it with floor and round. It appears the old behavior
was to work around combining ceil with inaccurate FP, but
it doesn't appear this hacky ceil is needed.
Change-Id: I5c16ec0fa4916e17198a733c46937fde53f2ddb5
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Adding specialHTMLTargets to EXPORTED_RUNTIME_METHODS carries the
obligation to actually use it as well; failing to do so makes Emscripten
stop with a reference error on startup.
However, we can't guarantee that Qt will use it in all cases. The
current usage depends on QGuiApplication being used. Application code
could be using QCoreApplication, or no application object at all.
Detect if specialHTMLTargets is present instead, and then enable the code
paths which uses it if that's the case. This means that apps which want
to use e.g. multiple browser windows can opt into support by making sure
EXPORTED_RUNTIME_METHODS contains specialHTMLTargets.
Change-Id: I81105aa01946602fcf593f170e305d7dc9bad3be
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Problem detected while investigating a crash of a program using
QT, valgrind was used to detect errors and valgrind reported
"Conditional jump or move depends on uninitialised value(s)"
due to m_exclusive being uninitialized.
Not sure to what extent this fix matters in practice, the crash
turned out to be caused by something else outside QT. But anyway
it seems good to initialize m_exclusive like other things, in the
constructor, and it helps avoiding such warnings from valgrind,
that will make it easier to detect other problems using valgrind
or similar tools.
Amends ac8a1787eb where it looks
like initialization of this member was simply forgotten.
Pick-to: 6.3 6.2 5.15
Change-Id: I3d1637a00b7899eded61c2e4f5f9a1c5041e4f45
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Elias Rudberg <mail@eliasrudberg.se>
This way we can handle keyboard shortcuts for actions in that menu as
well in our menuHasKeyEquivalent implementation. This allows the focus
widget to accept the override, and e.g. a QKeySequenceEdit to record
Cmd+Q which with a plain NSMenu will just quit the application.
Pick-to: 6.3 6.2
Fixes: QTBUG-103590
Change-Id: I84597307aef8f0ab65d97d78e5aa15e5cf2e707d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change-Id: I9f95542fd6a0326985744503a71e36448961d6fc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
Always invert scroll deltas. This is what the code did
before, expect for on non-Safari macOS. There is no
need any "smart" code here: correct deltas are provided
by the native API regardless of macOS scroll direction
setting.
Reading webkitDirectionInvertedFromDevice is still useful
for certain use cases, such as 3D scene zooming or spinbox
value change, where upwards motion on the trackpad should
always correspond to "increment" regardless of scroll direction.
Propagate this to Qt using one of the handleWheelEvent()
overloads
Finally, we were sending pixel deltas as angle deltas;
fix by sending pixel deltas as well, but keep existing
angle delta behavior for compatibility.
Change-Id: I7a7104c30da057fefc0377816e551a9e7e2fa0e7
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: David Skoland <david.skoland@qt.io>
We were drawing window decorations at an incorrect location in
cases where the QScreen was not at (0,0) (i.e. at an offset on
the web page). Window content was placed correctly.
Correct canvas geometry can be fond by offsetting window geometry by the
negative screen position. Implement this for drawWindowDecorations(), and
also simplify the existing code in drawWindowContent().
Change-Id: I1347d325a58dae5e2bb950b93902123f64199ee8
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: David Skoland <david.skoland@qt.io>
If we don't do this then applyWindowState() will apply the
original window geometry from QWasmWindow::initialize().
Change-Id: I4a0fb7aa7984ba21c64364e0bf00d70513232d5d
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: David Skoland <david.skoland@qt.io>
Keep the old behavior from 6.0 to 6.2.
Fixes: QTBUG-102637
Pick-to: 6.3
Change-Id: I2e596c7d5161a3dc7a8493358e272a481aee5308
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Lorn Potter
Morten Sørvig
André de la Rocha
Ilya Fedin
Liang Qi
Jiang Wu
Nils Jeisecke
Tor Arne Vestbø
Giuseppe D'Angelo
Louis du Verdier
Yuhang Zhao
Axel Spoerl
JiDe Zhang
Maximilian Goldstein
Kai Köhne
Allan Sandfeld Jensen
Thiago Macieira
Vladimir Belyavsky
Jani Heikkinen
Volker Hilsheimer
Doris Verria
David Skoland
Elias Rudberg