SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Open a kirigami app with QT_QUICK_CONTROLS_MOBILE=1 (e.g. Kasts, Tokodon) 2. Push a new page to the pageStack, e.g. by clicking on an item OBSERVED RESULT The new page will be pushed onto the stack, but will not be visible. It will only become visible after swiping the original page to the left. This happens with both qqc2-desktop-style and qqc2-breeze-style. It only happens when QT_QUICK_CONTROLS_MOBILE=1. EXPECTED RESULT The view changes to the pushed page, just like it is when QT_QUICK_CONTROLS_MOBILE hasn't been set. SOFTWARE/OS VERSIONS KDE Frameworks Version: compiled from master (with kdesrc-build) Qt Version: 6.6.1 (from arch packages)
I've done some further investigation, and I've now traced it to a few lines of code. With QT_QUICK_CONTROLS_MOBILE=1, m_acceptMouse is set to true on the ColumnView. This in turns sets m_mouseDown = true when the current Page is clicked. This also happens when a delegate or button is clicked which is supposed to insert a new page. While m_mouseDown is true, some code will be skipped in ColumnView::setCurrentIndex() which is responsible for the animation that moves the view to the new page. My guess is that setCurrentIndex is called before the mouse button is released, so it does not execute the animation.
Don't know if it's relevant to this, but when opening the settings in Kasts (which will use the layers) it triggers this warning: file:///home/bart/kde/usr/lib/qml/org/kde/kirigami/PageRow.qml:1013:5: QML RowLayout: StackView has detected conflicting anchors. Transitions may not execute properly.
I got a bit further with debugging this, and it seems that my previous hunch was close. The problem seems to be related to using TapHandler instead of MouseArea. It seems that TapHandler's `onTapped` slot (which pushes a new page) is completely finished before the ColumnView gets to handle the ButtonRelease event. This triggers `setCurrentIndex` while m_mouseDown is still true, so it will not start the animation to slide to the new page. Once the ColumnView gets to process the button release event, it will treat it as a click on the current page instead of the new page, so it will start a new animation to slide to the current page rather than the newly pushed one. In contrast, with MouseArea, the ColumnView first gets to process the ButtonReleases event before MouseArea processes the click. I don't know know the reason of this difference, but could it perhaps be related to this: https://doc.qt.io/qt-6.6/qtquickhandlers-index.html#pointer-grab ? It says that Taphandler gets a first go since it's a child of the item. Next, the item itself (i.e. the delegate) gets a go, which means that it first goes through the childMouseEventFilter which decides whether or not to do anything with the click? So, effectively, it seems like TapHandler will therefore always finish before the filter? NB: As a *workaround*, one could use TapHandler's `onSingleTapped` together with `exclusiveSignals: (TapHandler.SingleTap | TapHandler.DoubleTap)` This ensures that the taphandler will only process the event after the double-click interval has expired, which is apparently long enough for columnview to do its business first.