summaryrefslogtreecommitdiffstats
path: root/tests/auto/widgets
Commit message (Collapse)AuthorAgeFilesLines
* QtBase: replace windows.h with qt_windows.hYuhang Zhao2021-11-234-6/+4
| | | | | | | | | | We have some special handling in qt_windows.h, use it instead of the original windows.h Change-Id: I12fa45b09d3f2aad355573dce45861d7d28e1d77 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Skip disabled proxy widgets when (back)tabbingAlexander Volkov2021-11-191-0/+52
| | | | | | | Fixes: QTBUG-98137 Pick-to: 6.2 5.15 Change-Id: If52053dce361b130ef7dcfaf747710d8ceb9bbcd Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix assert in QFontComboBox when setting empty fontEskil Abrahamsen Blomfeldt2021-11-181-0/+32
| | | | | | | | | | Don't crash if the font does not have any families set. Pick-to: 6.2 Task-number: QTBUG-97995 Change-Id: I8dc2f2fc00309b6fff6d4a661ec6d659f30808af Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
* QFontComboBox don't response qApp fontDatabaseChanged()Zhang Hao2021-11-161-5/+8
| | | | | | | | | | | | | | | If QFontComboBox is instantiated in the form of new and call QFontDatabase::addApplicationFont, QFontComboBoxPrivate::_q_updateModel() will be called when the program exits, at this time qApp will crash. Fix this by when program exiting, QFontComboBoxPrivate don't need call _q_updateModel(). Fixes: QTBUG-98099 Done-With: Konstantin Ritt <ritt.ks@gmail.com> Pick-to: 5.15 6.2 Change-Id: I3df3d19c3d1971288d60f2eef386262befbf396b Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com> Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* Make sure we paint overlapped children and siblings when moving farVolker Hilsheimer2021-11-151-1/+118
| | | | | | | | | | | | | | | | | | | | In paintAndFlush, QWidgetRepaintManager subtracts opaque children if the target isn't overlapped and isMoved is set to true. So in moveRect, set isMoved to true after the blitting of movable areas, and reset it to false if we have overlapped sibling or child regions. Otherwise, moving so far that sourceRect is invalid (none of the original pixels are visible after the move) we end up in a code path that sets isMoved to true even with overlapping children or siblings, which then breaks paintAndFlush's assumptions. Reuse the test case written by Sergiy Korobov <tiamatenko@gmail.com> in earlier attempts to fix this bug. Fixes: QTBUG-26269 Pick-to: 6.2 Change-Id: If7443863f5eee79a80220cd587522122f42a21e4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Test result of qobject_cast before dereferencingLi Xi2021-11-151-0/+13
| | | | | | | | | | | | | Since QMainWindow::setMenuWidget accepts a QWidget (allowing users to implement their own menu widget), we need to use qobject_cast on the stored widget to see if it is a QMenuBar before calling QMenuBar APIs. This qobject_cast may return nullptr. Pick-to: 6.2 Fixes: QTBUG-98247 Change-Id: Iff1dbd24fa7ca09098fe49c179770356c966251d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QTabBar: Support scrolling with a kinetic wheelVolker Hilsheimer2021-11-151-16/+179
| | | | | | | | | | | | | | | | | | | | | | | QTabBar implements wheelEvent to move the current index up or down. This is useful for clicky mouse wheels, but a bad user experience when using a kinetic wheel or touch pad, as every pixel movement will change the current index. Instead, scroll the entire tab bar when the wheel event comes from a device that supports scroll phases, without changing the current index. As drive-by's, fix the test introduced in aa09bea00ca88c587cfb1f56 to not leak memory or leave a test-specific style set on the QApplication instance, which can break other tests. Also, make relevant layout code in QTabBar respect the usesScrollButtons property, const'ify local variables, and return an accepted QWheelEvent if the event resulted in a change. [ChangeLog][QtWidgets][QTabBar] Scrolling with a kinetic wheel or touch pad scrolls the entire tab bar, without changing the current index. Change-Id: I990e51466dd25c741877bbf0e197449f897a9efb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* macOS: make the slider knob big enough for BigSur and MontereyVolker Hilsheimer2021-11-151-2/+6
| | | | | | | | | | | The slider is very touch friendly from macOS 11 on, and the knob is quite large. Give it some extra pixels, and adjust the test accordingly. Pick-to: 6.2 Task-number: QTBUG-98093 Change-Id: Iedf6db1081cdd4013ca29ce760aea1e0361b1123 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QFileDialog: Fix adding default suffix when file path contains dotAlexander Volkov2021-11-121-0/+16
| | | | | | | | | | Check that a file name, not the full path, contains a dot. Fixes: QTBUG-59401 Pick-to: 5.15 6.2 Change-Id: I193b2ae457a3ac6a460524dbf200786eb3461cef Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QPushButton: emit released signal when mouse dragged out of boundsChunLin Wang2021-11-101-0/+31
| | | | | | | | | | | | After special processing for hover, QPushButton::mouseMoveEvent() needs to call the base class function, like every virtual override should, to continue processing other logic. Amends 3310e13a17d2249a86fa533e350744c5593be54f Fixes: QTBUG-97937 Pick-to: 6.0 6.2 Change-Id: Ic2e111d6c38371e0aa04423f5fb26c52717bf5fb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Don't use QCursor::pos in QTabBar and fix hover handlingVolker Hilsheimer2021-11-051-0/+84
| | | | | | | | | | | | | | | | | | | | | | Relying on QCursor::pos makes tests fragile and prevents multi-seat support. Instead, record the mouse position in the already existing event handling, and use that instead. Styles might use either WA_Hover or enable mouse tracking for the widget to enable hover-effects, so we need to support both. Fix the scenario where a newly inserted tab ends up under the mouse, which was previously not handled correctly (only the case of removing a tab was). Clean up the repaint management when the hovered tab changes; just call update on the old rect, and then later update on the new rect; there's no need to make a copy first, updates are posted and compressed. Add a unit test that makes sure that we paint tabs that should be under the mouse in the hovered state. Since not all styles enable hovering and/or mouse tracking in all cases, use a style sheet for those styles that don't. Change-Id: I7cdbb18e9e04b52651e273680fec87b50cb81e05 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QAIV: Reset double-click flag in mousePressEventVolker Hilsheimer2021-11-051-0/+38
| | | | | | | | | | | | | | | Amends 17c1ebf8bfd254ff75cc55e335d1c1fb01da547f, which introduced logic that recognizes double clicks to avoid duplicate clicked() emits. If a slot connected to doubleClicked opens a dialog, then the release-event will not be seen by the item view, leaving the flag incorrectly set and preventing the next clicked signal. Fixes: QTBUG-97853 Pick-to: 6.2 5.15 Change-Id: Iced83e8c66a763672f522265435dc52a745227e4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Release mouse buttons after double clickVolker Hilsheimer2021-11-031-0/+2
| | | | | | | | | | | Otherwise, the button state maintained by Qt when using the offscreen plugin is not reset, breaking following tests. Pick-to: 6.2 Task-number: QTBUG-97964 Change-Id: Ib37fd038e214863e1e316dc3d41e9d28c157b1f8 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: David Skoland <david.skoland@qt.io>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-30 22:31:22 +0000