qt/qtdeclarative.git/src/quicktemplates/qquickpopup_p_p.h, branch dev

Drawer: stop using QQuickVelocityCalculator

2026-06-30T04:46:18+00:00

QQuickPopupPrivate::handleRelease() now receives the QEventPoint rather
than a flattened (position, timestamp) pair. QEventPoint already carries
scenePosition() and timestamp(), and additionally velocity() — the
smoothed release velocity computed during event delivery. We still
calculate velocity of the whole press-to-release interval though, in
case some users unintentionally slow down or reverse movement at the end
of the drag.  If we want to change the "feel", we would have to change
the tests too.

Drawer was the only override of this virtual, so the change is atomic.
The Control-hierarchy handleRelease() (used by SwipeDelegate et al.) is
unchanged; QQuickVelocityCalculator remains for those until they migrate.

Change-Id: I8cb81af30d8d9e8ee90d050f290743ef42b6979f
Reviewed-by: Richard Moe Gustavsen

Run popup window tests on Linux/xcb

2026-06-19T21:03:20+00:00

Since the popup window project took longer than expected, we decided to
first make sure that our tests run on Windows and macOS.

But we should enable the tests on more platforms.
Lets make sure that we can run them on xcb first. That will allow us to
add more platforms, like wayland, in the future, and hopefully remove
the #if statement completely one day.

Also, QQuickPopupWindow::windowChanged() didn't update the
transientParent. This must have been an oversight.

Some tests had to be slightly modified, in order to pass on X11.
One of the unique features of the platform is that the xserver usually
communicate with the window manager, which is delegated the task of
deciding a window's geometry based on a client's request. This
additional layer of asynchronous indirection seems to cause tests that
are believed to be reliable on Windows/macOS fail on Linux/X11.
The solution here is to use TRY_VERIFY/TRY_COMPARE in more places.
In additon, we have to use QWindow::mapFromGlobal()
QWindow::mapToGlobal() instead of naively assuming normal arithmetic
will work. The mapping functions use xcb_translate_coordinates(), which
is necessary to avoid issues that can show up when mapping between
coordiate systems on X11.

Finally, we also fix the issue that can happen when binding visible to
true, aka:
```
Window {
    width: 500
    height: 500
    visible: true
    Popup {
        x: 100
        y: 100
        visible: true
        width: 400
        height: 400
    }
}
```
In the above snippet, on X11, and sometimes Windows, the popup window
would not be positioned relative to it's parent, but instead the screen.
This was because the client would send a request to create both the
Window and the Popup's window at the same time.

To make the Popup's window position itself correctly, we have to wait
for the Window to exist before we can correctly calculate the popup's
geoemtry to add to the configure event that we send to the server.
This can be easily done by waiting for its Expose event.

For some reason, the tst_QQuickPopup::popupWindowPositioning test fails
in CI on the Ubuntu:Gnome image. This is in the final part where it
checks if a popup's position is updated if the transient parent window
is moved. I've not been able to figure out why it fails on this
platform yet, and when testing it on an Ubuntu installation outside our
CI, the same test passess. I'd like to get back to this later if
possible.

Pick-to: 6.12
Change-Id: Ieef1fadaa365641059e0913be02eebd9bc107398
Reviewed-by: Mitch Curtis

Fix popup positioning on wayland

2026-03-25T10:52:02+00:00

The wayland compositor positions popups windows relative to their
transient parent. It may flip the popup's position depending on
the extended window flag, and parent control's geometry.

On other platforms, we usually do this repositioning ourselves in the
QQuickPopupPositioner. This is not possible on wayland, since popups
don't know their position on the screen. This is by design, since
popups on wayland should be positioned by the server, not the client.

Also, client side window decorations are a tricky subject on wayland
too. Both the Windows and FluentWinUI3 styles use negative insets to
shift the background a bit outside the bounds of the popup to draw a
drop-shadow. We implemented this, by making negative insets enlarge the
popup window, and then move the content inside the popup by the same
amount.

For now, the simplest work-around is to just disable this drop-shadow
rendering on Linux/Wayland.

Pick-to: 6.11
Done-with: David Redondo 
Change-Id: I8b9718a2a4363ddff4f3269b2d6ebfe4272b650a
Reviewed-by: Mitch Curtis

Add window flag setter to the qquickpopup and use it in dialogs

2026-02-18T12:08:14+00:00

The window flags used for quick dialogs were ignored, so I added a
window flag setter to QQuickPopup and used it to apply the custom
window flags.

Fixes: QTBUG-136650
Pick-to: 6.8 6.10 6.11
Change-Id: I754edc5b5db0fee3fac006c5b00f9dd760b5bd7a
Reviewed-by: Oliver Eftevaag

Reset last active focus item in the overlay for multiple popup case

2026-02-13T12:36:02+00:00

The last active focus item saved in the overlay would reset whenever the
pop-up is closed. This causes a problem in a case where we have multiple
popups, specifically where the first popup is in exit transition and the
second popup is in enter transition. The first pop-up during its exit
transition resets the last active focus item in the overlay when it's
closed, causing any other pop-ups opened after that not to set focus
back to this item when they are closed, leading to focus loss.

To prevent this, the pop-up has been modified to maintain the last
active focus item on its own, apart from whatever the overlay maintains.
This provides an option for the pop-up that is getting closed to reset
the focus item within the overlay. The logic has been handled in the
pop-up as follows when it's being closed,

Check for popups in the stack that:

    1. Are not in an exit transition.
    2. Contain a saved last active focus item (from the window).

If found, update the overlay's focus reference to this item and prevent
a reset. This ensures focus returns to the correct item once the pop-up
item is closed.

Amends 4db78fc04d7f83330990a17f2c58392de6412fb5,
56a726451f3026a5dbd61a3e5fb5fae69e032212

Fixes: QTBUG-139255
Pick-to: 6.11 6.10
Change-Id: Ic92a318ad61cc354d42ee8c655fac9c784530eca
Reviewed-by: Oliver Eftevaag 
Reviewed-by: Frederic Lefebvre

Revert "Fix flakiness in tst_QQuickContextMenu::textEditingContextMenuSelectAll"

2026-02-04T23:59:40+00:00

This reverts commit fc849fb9cfff3dbf7c954f95057935dc2f8b64f8.

This didn't fully fix the flakiness, which should now be fixed by using
QQuickControlsTestUtils::clickMenuItem.

Task-number: QTBUG-143701
Change-Id: I773e87181e9039f7a44b6527ad60940bdcdb1ab4
Reviewed-by: Oliver Eftevaag

Fix flakiness in tst_QQuickContextMenu::textEditingContextMenuSelectAll

2026-02-03T02:18:21+00:00

FluentWinUI3 animates its height in its enter transition. This causes
issues in textEditingContextMenuSelectAll on Ubuntu (X11), because the
native resize events caused by the menu's height changes arrive too
late, causing clicks to miss the menu item and instead close the menu
(which clickButton now warns about).

There doesn't appear to be a way to reliably detect and hence wait for
these events, and we can't disable the enter transition because the
menu doesn't exist until the right click event, by which point the
transition has also already started. So, add an environtment
variable to allow the test to disable them before they start.

Task-number: QTBUG-143701
Change-Id: Id2b1e2f23da2dd5fb6039ce25f946b8cc677088f
Reviewed-by: Oliver Eftevaag

Set explicit default security level of all files with default security

2025-09-17T13:31:14+00:00

The files (folders) already processed are listed in each issue in epic
QTBUG-134547

These files were processed half a year ago. In order to make it clear
that all of these files are already processed, mark them with an
explicit default security header.

For the record, this was generated with this script:

find -E . -regex ".*\.(cpp|h|hpp|mm|qml|js)$" | xargs python3 ~/bin/add-cra-header.py

in the folders listed in each subtask of QTBUG-134547

(add-cra-header.py only exist at my desktop, but it simply adds the
default security header if it doesn't already have any existing security
header)

QUIP: 23
Fixes: QTBUG-134547
Pick-to: 6.10 6.9 6.8
Change-Id: Ieb8c78ea6561fdbdd27c7b13185ece853eedf80f
Reviewed-by: Oliver Eftevaag

Propagate modality to the non-native quick dialogs

2025-07-09T20:31:35+00:00

The non-native quick dialogs don't block input to the windows even after
setting the modality as ApplicationModal/WindowModal. This is because
non-native platform dialogs (QuickPlaform*Dialogs) didn't set modal to
its respective window (QQuickPopupWindow).

This patch fixes that issue by setting the modality to the non-native
platform dialogs.

Task-number: QTBUG-127605
Pick-to: 6.10 6.9 6.8
Change-Id: Idb3374e881766ae92adc0360c9b9af5c498dd6df
Reviewed-by: Oliver Eftevaag

qquickpopup: Clear stale last active focus

2025-05-08T18:46:45+00:00

Non-modal popups were saving lastActiveFocusItem but only clearing it
if *they* had focus when closing. If focus moved away while open, the
stale focus stuck around and got restored on the next close.

Introduce a savedLastActiveFocusItem flag in QQuickPopupPrivate. Set it
when we record lastActiveFocusItem in prepareEnterTransition(), and in
finalizeExitTransition() only clear the overlay's saved focus if this
popup actually set it.

For stackingOrderPopups, add an additional check which avoids setting
active focus to a popup which has already gained it during open. This
allows lastActiveFocusItem logic to take place instead. This scenario
happens with menu popups using exit transition (e.g. Material style).

Pick-to: 6.9
Change-Id: I81caf1b5e647b3794ac8d03888534501c771ae07
Reviewed-by: Tor Arne Vestbø