summaryrefslogtreecommitdiffstats
path: root/tests/auto/widgets
Commit message (Collapse)AuthorAgeFilesLines
* Fix test to not rely on event processingVolker Hilsheimer2021-10-271-6/+8
| | | | | | | | | | | | | | | | | QTest's simulation of mouse move events currently uses QCursor::setPos and then processes events. This is unreliable across platforms. This test relies on the event processing and either way has inverted logic in the paint event; the painted region needs to at least include the tab's rect, not the other way around. Also, the mouse move wasn't needed here at all, and some styles don't have a different style for pressed tabs anyway. Pick-to: 6.2 Change-Id: Ib8f6f7be017ff87458e96ec419edcd065dd75b15 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Calculate effect bounds when drawing widget graphics effectAntti Määttä2021-10-271-0/+153
| | | | | | | | | | | | | Calculate effect bounds for the updated region when drawing the effect so that the whole affected area gets updated. The effect bounds have already been added to the region so it doesn't need to be handled in the drawing function. Pick-to: 6.2 5.15 Fixes: QTBUG-96240 Change-Id: I0c317311622e6299fb1a3015541408d1d83c93de Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QTabBar: re-layout when tab size hint depends on selected stateVolker Hilsheimer2021-10-261-2/+30
| | | | | | | | | | | | | | | | | QTabBar caches the rects for the tabs to avoid costly recalculation of each tab's size hint. That cache is only updated via layoutTabs if the entire tab bar is resized or modified. However, when a style sheet is set that calculates a different size hint for tabs that are selected, then the tab bar also needs to be laid-out when the current tab changes. To minimize the cost, compare the cached size for the new current tab with its new size hint, and re-layout the tabs when they are different. Fixes: QTBUG-6905 Fixes: QTBUG-8209 Pick-to: 6.2 Change-Id: I110444d18938c2b3446ee58e4a8c6c472b5f12c3 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Don't fire shortcut if the action only lives in an unreachable submenuVolker Hilsheimer2021-10-251-0/+74
| | | | | | | | | | | | | | | | | Menus can be represented by a menu action, and if that menu action has been hidden or disabled, then the submenu is not accessible from the parent menu or menu bar to which it was added. Don't walk the menu action chain further when checking whether the shortcut should trigger. Note that this is unrelated to the menu being visible or not; we obviously want to trigger shortcuts for actions that only live in a menu that has not been shown, otherwise the shortcut would be rather pointless. Pick-to: 6.2 Fixes: QTBUG-25743 Change-Id: I48735e17352989bbc84a72263e4828f519b78095 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QAbstractItemView: auto-scroll with selection rectangleVolker Hilsheimer2021-10-222-0/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some item views, such as QListView in icon mode, implement a selection rectangle with which the user can "lasso" items. So far, dragging that rectangle did not trigger auto scroll, so unless an item near the edge was selected, the user had to stop the lassoing and scroll manually to reach more items. Since QAbtractItemView implements auto scrolling for drag'n'drop, we can use that mechanism also when the selection rectangle is dragged. This requires some modifications: We need to make sure that scrolling the view during a drag-selection generates mouse move events so that the selection is extended and the rectangle is updated in subclasses. And we need to stop using QCursor::pos to get the position of the mouse pointer, as this makes the auto-scrolling untestable. Instead, record the mouse position last seen during a mouseMove or dragMoveEvent in content-coordinates (identical to pressedPosition). As a drive-by, fix some coding-style issues in nearby code. Done-with: Zhang Hao <zhanghao@uniontech.com> Fixes: QTBUG-96124 Change-Id: I426f786e5842ae9f9fb04e9d34dc6d3379a6207f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Centralize maybeLastWindowClosed checking in QWindowTor Arne Vestbø2021-10-201-3/+12
| | | | | | | | | | | | | | | | | Instead of plumbing QWidgetWindow close events via handleCloseEvent, we just implement closeEvent directly. This allows QWindow do save the state of the window/widget before the close event, so that we know whether we should trigger lastWindowClosed handling, even if the window was deleted as a result of the close event. This also relieves QGuiApplication and QApplication from dealing with the close logic in their notify functions, so that these functions can focus on the propagation of events -- not how the event is handled. Change-Id: I8b586b53a53b1df1d8630c1acb635c60f191bb4b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Make QMainWindow::restoreStateSizeChanged test less time sensitiveVolker Hilsheimer2021-10-201-2/+29
| | | | | | | | | | | | | | | | | Amends 32edae5e268b968aff82f0713612eff2feffb4e1, which introduced a timeout after which the restored state is discarded. If this timeout hits during a CI run, then the test is expected to fail. Implement a lambda that watches for the restored state to disappear. This happens primarily when restoring a fullscreen state, where some desktop environments scroll in a new virtual desktop. It should not happen for other data tags. Change-Id: I5ff43a4e1857eca17a5d4fe2b47add1f70636e8d Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Fix restoring main window state for maximized/fullscreen windowsVolker Hilsheimer2021-10-161-0/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On systems that asynchronously resize the window to maximized or full screen state, the window will become visible in its normal geometry before it gets the final size by the windowing system. This might cause multiple resize events, to each of which the widget's layout responds with a call to its setGeometry implementation. The QMainWindowLayout is special in that it will shrink dock widgets if there is not enough space for them, but it doesn't grow them back once there is. With the initial resize event being for a smaller size than what was restored, the state is not restored correctly, but remains in the state that fit into the smallest size with which setGeometry got called. To fix this, we have to keep the restored state around until the window either gets a size that is large enough for it to fit, or until we can be reasonably certain that the windowing system is done resizing the window while transitioning it to the maximized or full screen state. Since across the various platforms and windowing systems there is no reliable way to know when the window reaches its final size, we have to use a timer that we (re)start for each call to setGeometry with a size that's not large enough. Once the timer times out, we have to give up; then the last layout state calculated is the final state. To calculate the size of the layout, introduce a function to the QDockAreaLayout that returns the size required for the current sizes of the docks. Refactor sizeHint and minimumSize (which were identical) into a helper template that takes member-function pointers to call the respective method from the dock area layout's content items. Add a test case for various permutations of the scenario. The timeout of 150ms is based on running this test case repeatedly on various desktop platforms and X11 window managers. Fixes: QTBUG-46620 Change-Id: I489675c2c40d3308ac8194aeb4267172b2fb38be Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* macOS: Correctly record normalGeometry in Cocoa pluginVolker Hilsheimer2021-10-141-61/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cocoa sends QWidget the state-change notification after the window has been resized already, at which point we cannot store the normal geometry anymore. Handle zoom and full screen callbacks prior to the state changing to store the geometry in QCocoaWindow. We do not need to handle minimized state, as the window will still reflect the original geometry. Return the stored value from an override of QPlatformWindow::normalGeometry so that QWidget gets the correct values even though the new state is already active. Fix the tst_QWidget::normalGeometry test to make it pass on all platforms by waiting for the window to actually have transitioned to the new state before comparing geometries. Both macOS and Windows fully pass; on Xcb, deminimizing a window using setWindowState does not work, which is why the test was partially skipped (confirmed by visual testing). Move those problematic, complex test cases to the end so that most cases are covered on Xcb as well. Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Pick-to: 6.2 Change-Id: I518a5db9169b80e8fa25fe4fa2b50bd1ea0e6db3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QWidget: Don't rely on topextra to determine if window is top levelTor Arne Vestbø2021-10-141-0/+1
| | | | | | | | | | Doing so results in bailing out early for a widget that hasn't been shown yet, or otherwise resulted in creating extra and topextra, which means the normalGeometry will not reflect the widget's geometry. Pick-to: 6.2 Change-Id: Ieb85e9a6109ae34fe20d79e3c12f4517f827a590 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Call QWidget close handling in QWidget::close for non-toplevel native widgetsDoris Verria2021-10-141-0/+20
| | | | | | | | | | | | | | Since commit 7ba75d0 we close the QWindow in QWidget::close for native widgets and trigger the closeEvent in QWidgetWindow. However, if the widget's window handle is not a top level window, QWindow::close() will not close the window, failing in this way to deliver the closeEvent and call the close handling in QWidgetPrivate::handleClose. To fix, call handleClose() from QWidget::close for such widgets. Task-number: QTBUG-74606 Pick-to: 6.2 Change-Id: Ied342eced3340aaf19b5443762935b1a5fc5c27b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix references to QGuiApplication::lastWindowClosedTor Arne Vestbø2021-10-133-4/+4
| | | | | | | | | The signal is emitted from QGuiApplication these days. Pick-to: 6.2 Change-Id: I7423cd4808e8df86960f225fd6e4a12a1a4f11f3 Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Take overshoot into account when laying out QAbstractScrollAreaVolker Hilsheimer2021-10-131-0/+39
| | | | | | | | | | | | | | | | | | | | | | QAbstractScrollAreaPrivate::layoutChildren() positions the viewport, but did not take the overshoot from scrolling with a scroller into account. If the scroll area was resized during a scroll, then this resulted in the roll back overcompensating for the overshoot, placing the viewport outside the visible area. Fix this by taking the overshoot into account when positioning the viewport. Add a test case. We have to use QWindow-based mouse event simulation, as the QWidget based move events use QCursor::setPos, which doesn't reliably go through the gesture framework. Done-with: Volker Hilsheimer <volker.hilsheimer@qt.io> Done-with: Zhang Hao <zhanghao@uniontech.com> Fixes: QTBUG-94769 Pick-to: 5.15 6.2 Change-Id: Idf650c91e5a9cffa996e23e743939243b1d4fcc0 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Activate tst_QWidget_window::tst_showWithoutActivating on cocoaVolker Hilsheimer2021-10-121-8/+8
| | | | | | | | | The test passes, the functionality is implemented in QCocoaWindow. Task-number: QTBUG-8857 Pick-to: 6.2 Change-Id: I2f4b3a39cec1aaaf4351753b590f35e280503461 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Select a single range of cells in QTableView, away from merged cellsShawn Rutledge2021-10-121-0/+71
| | | | | | | | | | | | | | | | | | | | | - when there is no intersection between the current selection and the spans collection, get ranges for all cells, just as if no span exists - when there is an intersection between the current selection and the spans collection, get separate ranges for each cell (as before) This fixes the regular case of selecting multiple non-spanned cells after some cells are merged (get a single range for all cells instead of separate range for each cell). However, when selecting together a group of spanned and non-spanned cells, you still get a separate range for each cell. But this is normal behavior in similar applications; for example in LibreOffice, you cannot select and merge spanned and non-spanned cells: an error dialog tells you that it's not allowed. Done-with: Christos Kokkinidis Pick-to: 6.2 Fixes: QTBUG-255 Change-Id: Ic38f9a064a1f499825e7f750668013fc2dc564ba Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QTableWidgetSelectionRange: Make it possible to compare for equalityVolker Hilsheimer2021-10-121-0/+14
| | | | | | | | | Add operators as hidden friends, add test case to make sure that basic value-type operations are possible with this type. Task-number: QTBUG-255 Change-Id: I7fbf453aa16084c0b2a0079487cacb4e092ff664 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Activate tst_QDialog::showAsTool test on macOSVolker Hilsheimer2021-10-111-3/+2
| | | | | | | | | | | The skip-reason only cites Qt/X11. Convert the #ifdef into a platform name check instead. The test also fails with the offscreen plugin, so skip it for that as well. Pick-to: 6.2 Change-Id: I49607b89f4b32359e81e1d9aadff2c3e03035c53 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QDialog: respect WA_ShowWithoutActivatingVolker Hilsheimer2021-10-111-0/+29
| | | | | | | | | | | | | | | | | | QDialog overrides setVisible to set focus on the default push button, or (if there is no such button), make the first autoDefault push button the default button. QDialog also explicitly sends a FocusIn event to the focus widget in the dialog. All this should not be done if the dialog does not become active after getting shown, which will be prevented if the WA_ShowWithoutActivating attribute is set. Add a test case. Fixes: QTBUG-8857 Pick-to: 6.2 Change-Id: If47021a4721a280ba45e95b43d0424cdacd9b4ea Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Reduce the width of a hfw-widget if scrollbar would be flippingVolker Hilsheimer2021-10-111-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | For a widget that implements height-for-width, the vertical scrollbar becoming visible might be just enough to make the scrollbar unnecessary. In that situation, the scrollbar flips on and off continuously. To avoid that situation, make the width of the widget smaller until the height fits without scrollbar, up to the point where we have space for the scrollbar anyway. The calcuation here is assumed to be cheap, but depends on the heightForWidth implementation in the widget. Running the while-loop a few dozen times should have no performance impact during resizing and laying out the scroll area contents. Add a test that confirms that within a brief period of time we only get the one hide-event we expect. Done-with: Zou Ya <zouya@uniontech.com> Fixes: QTBUG-92958 Pick-to: 6.2 5.15 Change-Id: I0faeb5f9b1a226aada958c18333d9c2ac8203dd1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Fix QTabBar's SelectPreviousTab behaviorQiang Li2021-10-091-0/+2
| | | | | | | | | | | | | | When setCurrentIndex is called by removeTab, the old current index might no longer be valid. Only update the lastTab value of the new current tab if the old current index is still valid. As a drive-by, use the validIndex helper function. Fixes: QTBUG-94352 Pick-to: 6.2 Change-Id: I945e2093a90a1fccbba86d32b1113f83fedd41de Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add style hint for preventing spin box selection on up/downVolker Hilsheimer2021-10-081-0/+63
| | | | | | | | | | | | | | | | | | | | | | On a mobile device, selecting text in a line edit brings up the text action popup for select/copy/cut. In a spinbox where the user changes the value using the buttons, this can be very irritating, without providing any usability - the user is unlikely to start typing, at least not without first transferring focus into the lineedit first to bring up the keyboard. This style hint allows styles to override the default behavior of QAbstractSpinBox. Implement the customization for the Android style, and add a test case for QSpinBox. [ChangeLog][QtWidgets][QStyle] A new style hint, SH_SpinBox_SelectOnStep, specifies whether pressing the up/down buttons or keys in a spinbox will automatically select the text. Fixes: QTBUG-93366 Change-Id: If06365a7c62087a2213145e13119f56544ac33b5 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QCocoaWindow: Make window key if the app's modal window is hiddenDoris Verria2021-10-071-0/+21
| | | | | | | | | | | | | | | | | | | | On macOS, when showing a window, we decide if it should be made key and therefore active, if the app has no active modal session or if the window's worksWhenModal returns true. However, the window needs to be made key also when a modal window is present, but not visible. Add this condition when checking if the window needs to be made key. This makes the behavior consistent with what happens when a modal is minimized on macOS. The input focus is passed to the next window, and the window appears active, even if it can not be interacted with. Fixes: QTBUG-85574 Pick-to: 5.15 6.2 Change-Id: I204d4f912128f4a46840789fc2ee08e1b2716bfc Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix closing and showing a window with a native childVolker Hilsheimer2021-10-071-0/+46
| | | | | | | | | | | | | | | | | | | Closing a window with a native child results in the native child's QWidgetWindow being closed. That explicitly calls setVisible(false) on the child, which will still have the ExplicitShowHide attribute set from the initial (explicit) show. Even though we then reset the ExplicitShowHide, the WState_Hidden attribute will still be set, so Qt considers the window to have been hidden, and not show it again when the parent becomes visible. Add a test case. Fixes: QTBUG-96286 Fixes: QTBUG-79012 Fixes: QTBUG-71519 Change-Id: I482e6d5236c959d82ce66798176b259a3176972c Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Clean up tst_qwidgetVolker Hilsheimer2021-10-072-186/+186
| | | | | | | | | | | | | | | | | | | Remove dead code Make logic to position test widgets more consistent across test functions Consistent cursor positioning logic Get rid of unnecessary event processing Reduce calls to qWait with hard coded values Use qWaitFor to establish asynchronous preconditions Ignore expected warning messages Expect-fail (instead of blacklist or skip) some tests that always fail Ignore unpredictable events in childEvents test Split large "render" test in multiple test functions Task-number: QTBUG-52974 Task-number: QTBUG-26424 Change-Id: I206e114c2c1d9801e08600d3341c2738dc881f17 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* QAbstractItemView: Fix IM input starting edit sessionVolker Hilsheimer2021-10-011-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | Item views can open an editor widget on the first key press, and need to take special care not to break input methods. The initial key press starts compositing by the system input method, which is then interrupted by the focus transfer to the editor. To solve this problem, the widget needs to keep focus while the initial composition is ongoing, and only transfer focus to the editor once the composition is either accepted or cancelled by the user. Add a state flag that is set during this initial preedit phase. During this initial composition, the item view will receive all input method events, and needs to forward these to the open, but not yet focused editor for the user to get the correct visual feedback during the preedit phase. The item view also needs to report to input method queries on behalf of the editor to make sure that the IM UI is correctly positioned without covering the user input. Implement a test that simulates the sequences through synthesized QInputMethodEvents; we can't simulate the entire system input stack. Fixes: QTBUG-54848 Change-Id: Ief3fe349f9d7542949032905c7f9ca2beb197611 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Add testcase for QWidgetRepaintManagerVolker Hilsheimer2021-09-303-0/+261
| | | | | | | | | | | At the current state, Qt::WA_StaticContents is not respected on any platform, and optimizations for opaque widgets is not implemented on Cocoa. Task-number: QTBUG-73117 Change-Id: I48b7b0c4436da5a609fdbe51bb1c9789a2a059bd Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Don't clear focus if setParent doesn't change the parentVolker Hilsheimer2021-09-282-0/+90
| | | | | | | | | | | | | | | | | | | | QWidget::setParent might be called to change the window flags, without changing the parent. For those cases, we don't have to clear the focus. Decouple the newParent state from the wasCreated flag. In most places where newParent was tested, wasCreated was either tested previously and can't be false anyway, or the code executed is irrelevant for widgets that are not yet created (there can't be a paint manager). In the remaining case, test wasCreated explicitly to maintain existing logic. Add test for the cases where the previous code broke the focus, both for QWidget and QDialog. Fixes: QTBUG-93005 Pick-to: 6.2 Change-Id: I39dc179c2d348054de3927aa8b69eecef4935511 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Doris Verria <doris.verria@qt.io>
* macOS: Remove special cases in enter/leave event handlingVolker Hilsheimer2021-09-241-4/+0
| | | | | | | | | | The Cocoa QPA plugin no longer tracks popups, but dispatches enter/leave events when popups show and hide. So the special handling in tests and QWidgetWindow can go away now. Change-Id: Ib6ef00689de231996e5e57ecdd8fd0d4c861d68b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: send enter/leave when a window opens/closesVolker Hilsheimer2021-09-241-3/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | Since macOS doesn't give us any event when a modal window opens, we need to do so ourselves explicitly so that the current mouse window gets a leave event when e.g. a popup opens, and an enter event when the popup closes again. The case for modal dialogs is partially handled by QGuiApplication already. Note: We cannot rely on the transientParent of the opening/closing window, as it's nullptr for QMenu windows even if the QMenu has a widget parent. Add a test for enter/leave events when a secondary window opens, covering both the dialog and the popup case. For the dialog case, we sometimes get two Enter events when the dailog closes, which we have to tolerate for now. To make the test pass on b2qt platforms, fix the offscreen plugin to explicitly send enter/leave events in the same way as Cocoa now does. Fixes: QTBUG-78970 Pick-to: 6.2 Change-Id: If45e43e625e8362c3502c740154f6a6a8962b9e9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QWidgetWindow: Stabilize test on XcbVolker Hilsheimer2021-09-201-0/+1
| | | | | | | | | | | | | | | | | Showing, hiding, and showing a window can result in the Xcb QPA plugin warning about qt.qpa.xcb: internal error: void QXcbWindow::setNetWmStateOnUnmappedWindow() called on mapped window The point of the test is to verify that we get a paint event on a window that is shown again after having been hidden, not to verify that async windowing systems can handle a show/hide/show sequence. So wait for the window being exposed before we hide it. Pick-to: 6.2 5.15 Change-Id: If91a9926613645e78e332dacff34bd57e4034b6f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Blacklist flaky testDimitrios Apostolou2021-09-201-0/+3
| | | | | | | Task-number: QTBUG-96270 Pick-to: 6.2 5.15 Change-Id: I3feb604c0c2f394b2915b3d98d3b02f469331a18 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Activate test of enter event delivery on macOSVolker Hilsheimer2021-09-171-3/+0
| | | | | | | | The test passes consistently in local test runs on macOS 10.15. Change-Id: I6f05b27d3cbf930475a435c41db267a00b1726b0 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Remove conditioning on Android embeddedEdward Welbourne2021-09-174-12/+11
| | | | | | | | It is no longer handled separately from Android. This effectively reverts commit 6d50f746fe05a7008b63818e77784dd0c99270a1 Change-Id: Ic2d75b8c5a09895810913311ab2fe3355d4d2983 Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Close QDialog via QWidget::close()Tor Arne Vestbø2021-09-161-2/+4
| | | | | | | | | | | | | | | By going via QWidget::close() we ensure that if there's a QWidgetWindow backing the dialog (which is almost always the case), we will plumb down to QWindow::close(), resulting in QEvent::Close events to the QWindow. Since we don't want QDialog subclasses to receive a call to a closeEvent override that they didn't receive before (and which they might interpret as rejection or cancellation), install a temporary event filter that eats the QCloseEvent resulting from the call to close(). Task-number: QTBUG-53286 Change-Id: Ie8f6f0cb3160acfd5865dc74f0a7b6d87f838724 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Always reset close-status of QWidget when trying to closeTor Arne Vestbø2021-09-151-0/+30
| | | | | | | | | | | | | | | | | Move the status setting and resetting back into handleClose so that we don't end up with it being set if handleClose is never called in response to a close attempt. This can happen when QWindow's platform window has already been destroyed. Since QWindow::close handles that case gracefully and returns true, we can safely call it multiple times. Add test coverage to verify that we get exactly those close event calls that we want. Change-Id: Ica77bf17c26d923c3b79b1e5a688addbc88a6277 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Unskip QToolTip::keyEvent test on macOSTor Arne Vestbø2021-09-091-15/+18
| | | | | | | | | The test was failing because it didn't account for the platform behavior. Task-number: QTBUG-30040 Pick-to: 6.2 Change-Id: I7c523c06f0bfa459c1532cee721718bebc1858c4 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* macOS: Don't show QMessageBox::about(Qt) as modal windowsTor Arne Vestbø2021-09-091-2/+11
| | | | | | | | | | | | | | | | The system behavior is to not show these kinds of dialogs as modal, and we've documented that for QMessageBox. However, calling show() instead of exec() is not enough, as the default constructor of QMessageBox will set the modality of the widget to application-modal. We need to explicitly override this. [ChangLog][macOS] QMessageBox::about(Qt) now shows dialog non-modal, as documented. Pick-to: 6.2 Change-Id: I6bb59efb81feb23122276a9eede71b2f20c9d7c6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Forward touchEvents to children inside QGraphicsProxyWidgetVolker Hilsheimer2021-09-061-68/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies the fix from 1ecf2212fae176b78c9951a37df9e33eb24d4f2d, using QApplication::translateRawTouchEvent to dispatch the touch event received by the QGraphicsProxyWidget to the relevant child widgets under each touch point. In addition, limit the implicit grabbing of each touch point before sending the event to those cases where we have to: touch pads, and if the target widget comes from a closest-widget matching. And don't call the QTouchEvent override of QEvent::setAccepted() on QTouchEvent instances in QGraphicsView classes, as this will override each event point's acceptance state. This way, we can identify which touch points have been accepted after event delivery, any only implicitly grab those points that were. Otherwise, touch points not accepted by a proxied widget hierarchy will still be part of an accepted event, and be grabbed by the viewport of the QGraphicsView. This would then lead to infinite recursion when the QGraphicsProxyWidget passes the TouchUpdate event on to each touch point's grabber. Re-activate the test case, and extend it with more combinations. Refactor touch-event recording to make it easier to test multi-touch scenarios. Task-number: QTBUG-45737 Fixes: QTBUG-67819 Pick-to: 6.2 Change-Id: Id5611f4feecb43b9367d9c2c71ad863b117efbcb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Blacklist flaky QGraphicsWidget test function for macOSVolker Hilsheimer2021-09-061-0/+2
| | | | | | | | Counting repaints is unreliable on macOS. Pick-to: 6.2 Change-Id: Ifa1cf516a2cab94540bea005354d8311a2651d64 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add test-case for QWidget closing exits event loopVolker Hilsheimer2021-09-061-0/+31
| | | | | | | | | Also when closed by destruction, which as of today doesn't call QWidget::close and therefore also not QWindow::close. Pick-to: 6.2 Change-Id: I426255e2274eae9262243c769df2264fbaa915b0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add more QDialog unit test related to closing a dialogVolker Hilsheimer2021-09-051-0/+170
| | | | | | | | | | | | | | | | | QDialog today only hides itself during reject and accept, it doesn't close itself properly. This is problematic, as it doesn't close the QWindow. However, fixing this behavior must not result in duplicate calls to virtual function, or additional calls to virtual functions (such as closeEvent) without explicitly flagging the change in the changelog. Add more tests to document existing behavior so that we can identify such changes and verify the desired side effects. Pick-to: 6.2 Change-Id: I1f30701cd766eb3c7957751b51e8579d4542dd16 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QMessageBox: Reset clickedButton for each invocation of the dialogTor Arne Vestbø2021-09-041-0/+23
| | | | | | | | | | When showing a messagebox that has already been show we don't want to keep around the clicked button of the previous invocation. Pick-to: 6.2 Change-Id: Ib6f6293d40ab338c550ea344094db871ccf45c46 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* QWidget: close the QWindow in QWidget::closeVolker Hilsheimer2021-09-021-0/+66
| | | | | | | | | | | | | | | | | | | | | | | | | We want to close the window, end full screen mode on macOS, and free platform resources. This is all done by QWindow::close. QWindow::close closes the platform window, triggering a closeEvent to QWidgetWindow, which then calls QWidgetPrivate::close_helper. This way, closing a window via QWidget::close, QWindow::close, or interactively by the user are all equivalent. The QCloseEvent generated by the widget needs to be spontaneous for window-system generated events (i.e. the user clicked the close button), and non-spontaneous if the window closes because of a call to QWindow::close. To keep track of whether the event originated in an explicit call to QWindow::close, add a boolean to the QWindowPrivate. Add a test case that verifies that the window resources is destroyed, and that events are delivered as they should. Done-with: Morten Johan Sørvig <morten.sorvig@qt.io> Fixes: QTBUG-46701 Pick-to: 6.2 Change-Id: Iacb6a2c8d5e880b16b0c8f0c9257ed94bed36f5b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix QListView assert when the last row is moved in IconModeChunLin Wang2021-09-011-0/+217
| | | | | | | | | | | | | | | | | | | | | | | | | After the last row is moved, 0 will be returned when obtaining row and column data. At this time, QListView::doitemslayout will not call d->doitemslayout, so the QBspTree data structure will not be cleaned up, leaving a stale tree structure behind. This will trigger an assert during paintEvent handling if QListView is set to IconMode In QListView::ListMode the test for a valid model index doesn't use an assert. Call QListViewPrivate::clear explicitly if the column count is 0 so that the QBspTree and other data structures are cleared. Add a test case that simulates this scenario by implementing a model that returns a 0 column count for an index after the model structure was changed through a move of rows. Done-with: Volker Hilsheimer Fixes: QTBUG-95463 Pick-to: 5.15 6.1 6.2 Change-Id: I36419be5459b8ced930c619f538482ea1db4ad03 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Port to QImage and QPixmap deviceIndependentSize()Morten Sørvig2021-09-011-2/+2
| | | | | | | | | Replace the “size() / devicePixelRatio()” pattern with a call to deviceIndependentSize(). Change-Id: I9d9359e80b9e6643e7395028cd43e3261d449ae7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Revert "Forward touchEvents to children inside QGraphicsProxyWidget"Volker Hilsheimer2021-08-301-2/+1
| | | | | | | | | | | | | | | | | | | | | | This reverts commit 1ecf2212fae176b78c9951a37df9e33eb24d4f2d. The fix is not correct after all. TouchBegin goes to the correct widget with the fix, but following TouchUpdate and TouchEnd events now go to the viewport, as QApplication::translateRawTouchEvent always gives precedence to the widget that Qt recorded to be the touch grabber, which is the viewport. This results in infinite recursion, as the proxy widget trying to send the touch events to the embedded widget (expecting that translateRawTouchEvent will split it up) ends up sending the events back to the viewport. Leave the added test case as QEXPECT_FAIL, reactivate the (never run, hence unnoticed) test that the fix broke. Pick-to: 6.2 6.1 Task-number: QTBUG-45737 Task-number: QTBUG-67819 Change-Id: I4810affb3cd066743ae94ab7beb2f0c06b60d211 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Move QGraphicsProxyWidget test into correct test caseVolker Hilsheimer2021-08-302-310/+315
| | | | | | | | | | | | | | | The test case was previously disabled, so tests were added to the QGraphicsView test instead. With the QGraphicsProxyWidget test active again, move the test cases where they belong. Amends 1ecf2212fae176b78c9951a37df9e33eb24d4f2d, 01aeb5f7e4fd977e9698fffdc7650897664ecb82, and 06235d36ae9d00366215e748d80ff0faed3c2124 Pick-to: 6.2 Change-Id: I208b8a418653cf0640c2e7c9f716fa69538ad7e9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Reactivate QGraphics(Proxy)Widget unit testsVolker Hilsheimer2021-08-305-543/+301
| | | | | | | | | | | | | | | | | | | | | | | | | | They were de-facto disabled in the qmake build system, and didn't make it into the cmake build system either. The dependency to the fusion style is not a build-time dependency since the test uses the QStyleFactory to create the style, and if that fails, tests can be skipped at runtime. As a consequence of not being executed in CI for a long time, many tests failed. Also, many tests were commented out or skipped as broken, ambivalent, or nonsensical. Remove that dead code. The QGraphicsWidget::initialShow test doesn't test anything that initialShow2 doesn't test, but makes incorrect assumptions, so remove it and rename initialShow2 to initialShow. Failing tests frequently left QWidget objects undeleted, causing all subsequent tests to fails as well. Fix that with std::unique_ptr. Some tests are still unstable and fail on some platforms, handle that using QEXPECT_FAIL. The forwardTouchEvent test fails due to a bug in Qt introduced recently. Skipping it for now. Pick-to: 6.2 Change-Id: I405122ea9d4d150bd1d505d40b83fe39604de0f9 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Forward touchEvents to children inside QGraphicsProxyWidgetVolker Hilsheimer2021-08-261-0/+168
| | | | | | | | | | | | | | | | | | | | Just sending the event to the embedded widget is not enough, we have to perform hit-testing for the different touch points, and send the event to the child widget under the point. Fortunately, QApplicationPrivate::translateRawTouchEvent provides the logic that generates multiple events for groups of touch points. Since that helper always sent events spontaneously, add an optional parameter to allow sending of non-spontaneous events. Add a test case that simulates touch events to different widget configurations inside a QGraphicsProxyWidget. Fixes: QTBUG-67819 Task-number: QTBUG-45737 Pick-to: 6.2 6.1 5.15 Change-Id: Iffd5c84c64ee2ceadc7e31863675fdf227582c81 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QGraphicsProxyWidget: forward Window(De)Activate eventsVolker Hilsheimer2021-08-241-0/+55
| | | | | | | | | | | | | | | | | | The nested widget might be a QGraphicsView as well (documented to be supported), and QGraphicsScene maintains it's own activation status by counting Window(De)Activate events. We need to make sure that the embedded widget is informed about its activation status so that deeper nested children can receive focus. Forward WindowActivate/Deactivate events to the nested widget, which will pass it on to all its children. Add test case, which without this fix fails when verifying the inner scene's isActive state, or later when testing that focusInEvent is delivered to the embedded widget. Fixes: QTBUG-94091 Pick-to: 5.15 6.1 6.2 Change-Id: I4e0ecef50685ed081d15c7f76b6c1a4a40ed2682 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-28 23:05:28 +0000