summaryrefslogtreecommitdiff
path: root/src/tests/stacking
Commit message (Collapse)AuthorAgeFilesLines
* tests: Avoid CSD window in testCarlos Garnacho2023-04-251-1/+1
| | | | | | | | This ATM triggers missed .commit events for the window in question, to be addressed in Xwayland. Since the test does not seem to specifically rely on this window being CSD, make it a regular window instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2975>
* tests/stacking: Change primary monitor handlingSebastian Wick2023-02-074-4/+5
| | | | | | | | | | The first monitor in stacking tests is the primary monitor but that doesn't have to stay this way forever. Instead of special casing the name "primary" to refer to whatever monitor happens to be the primary monitor, we add an `assert_primary_monitor` command to verify that the monitor that should be the primary monitor actually is. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
* tests/stacking: Add a multi-monitor stacking testSebastian Wick2023-02-071-0/+49
| | | | | | | | | | | New add_monitor command for adding secondary monitors. Support setting the workspaces-only-on-primary preference. The stacking test tests the focus and stacking for multiple monitors with workspaces-only-on-primary=true. The default_focus changes previously broke this. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
* tests/stacking: Test stacking order with raise-on-click = falseSebastian Wick2023-02-071-0/+31
| | | | | | | | Makes sure the focus changes but the stacking stays the same. Also checks that the stacking and focus on a workspace stays the same when changing between them. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
* tests/stacking: Add support for moving the cursor and clickingSebastian Wick2023-02-071-0/+33
| | | | | | Also test that clicking on a window will focus and raise it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
* default-plugin: Handle unmanaging windows in switch_workspaceSebastian Wick2023-02-011-0/+11
| | | | | | | Also add a regression metatest. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2559 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2782>
* tests: Ensure that restore-size resizes the client before maximize/unmaximizeCarlos Garnacho2022-12-011-1/+2
| | | | | | | | | | The test does simply "wait" which apparently is not enough to ensure the client window did resize to the expected dimensions. Use "wait_reconfigure" and assert that the size after resize is the expected, before going further at testing its behavior after maximize/unmaximize; it might end up with the unexpected size after the whole operation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
* tests/stacking: Alt+Tab focus+stacking test for globally active inputSebastian Wick2022-09-201-0/+20
| | | | | | | | | | Gnome-shell uses meta_display_focus_default_window() when shell elements loose focus which is the case with Alt+Tab window switching. Globally active input clients don't immediately gain focus though so if meta_display_focus_default_window focuses a wrong window stacking and focus don't behave as expected. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
* tests/stacking: Test always-on-top stacking and focusSebastian Wick2022-09-201-0/+51
| | | | | | | | Adds the command make_above to set and unset always-on-top behavior of a window and tests stacking and focus when activating other windows and switching workspaces. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
* tests/stacking: Add workspace management commandsSebastian Wick2022-09-202-0/+71
| | | | | | | | New commands to set the number of workspaces, activate a workspace, with and without focus, move windows to specific workspaces, and check the stacking on a specific workspace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
* tests: Test hotplugs when having unmapped Wayland windowJonas Ådahl2022-08-111-0/+20
| | | | | | | | | | | | | | | | | | | | | | | This checks that an unmapped but created Wayland window correctly handle monitor changes. This is specifically added to test an edge case causing a crash with the following backtrace: ``` ... 4) 0x00007ffff78a2a6b in g_assertion_message_expr () 5) 0x00007ffff7defd5b in meta_window_update_for_monitors_changed () at ../src/core/window.c:3745 6) 0x00007ffff7899758 in g_slist_foreach () at ../glib/gslist.c:885 7) 0x00007ffff7dbe562 in meta_display_foreach_window () at ../src/core/display.c:3185 8) 0x00007ffff7dbe5fd in on_monitors_changed_internal () at ../src/core/display.c:3210 9) 0x00007ffff796f4ff in g_closure_invoke () at ../gobject/gclosure.c:830 10) 0x00007ffff7981316 in signal_emit_unlocked_R () at ../gobject/gsignal.c:3740 11) 0x00007ffff7987699 in g_signal_emit_valist () at ../gobject/gsignal.c:3495 12) 0x00007ffff7987bc2 in g_signal_emit () at ../gobject/gsignal.c:3551 13) 0x00007ffff7d89915 in meta_monitor_manager_notify_monitors_changed () at ../src/backends/meta-monitor-manager.c:3517 ... ``` Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
* tests/respect-constraints: Explicitly set monitor sizeJonas Ådahl2022-08-111-0/+2
| | | | | | | The test depends on a certain monitor size; make sure to set that up front. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
* tests: Add test for maintaining constraints after client resizesSebastian Keller2021-11-231-0/+43
| | | | | | | | | | This test ensures that windows that were resized such that they extend beyond the screen will be moved to be fully on the screen (if possible). This has been working on X11 since forever, but on Wayland only since the last commit. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2103>
* tests: Add test for unfullscreening followed by immediate strut changeSebastian Keller2021-11-171-0/+49
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
* tests/stacking: Add test for initially fixed size windowsJonas Ådahl2021-07-051-0/+75
| | | | | | E.g. map a window maximized or fullscreen. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1912>
* tests/stacking: Add test hiding a modal with a not shown parentJonas Ådahl2020-12-181-0/+32
| | | | | | | | | This adds a test case for https://gitlab.gnome.org/GNOME/mutter/-/issues/862 that checks that hiding a dialog where its parent is not yet shown doesn't trigger any asserts or crashes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1643>
* tests/stacking: Add test for when no default focus window can be foundSebastian Keller2020-06-261-0/+29
| | | | | | | | | | | | | | | The previous commit removed checks for intermediate focus states which would make tests randomly fail, because of their time dependence. What can be tested however is that if there is no other window available that would accept the focus, that the focus remains at 'none', after the focused window has been closed. This newly introduced test checks the focus directly after closing the window (and syncing) and after the time it would have taken for the queue to finish. The first check has a similar timing issue as the removed focus checks in the other tests, but the test will never accidentally fail, because regardless of whether the queue has finished or not, the focus is always expected to be 'none'. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1329
* tests/stacking: Don't test for time-dependent intermediate focus stateSebastian Keller2020-06-264-4/+0
| | | | | | | | | | | | | | | | While c3d13203 ensured that the test-client has actually closed the window before testing for the focus change, it also made another timing related issue with the tests more likely to happen. Serveral tests assert that the focus is set to 'none' after the focussed window has been closed when the window below does not accept focus. This however can never be reliably tested, because closing the window triggers timeout based iteration of a queue of default focus candidate windows. This starts after the window has been closed and might finish before the clients have finished synchronizing. This issue is more likely to trigger the shorter the queue is and the more test clients there are that could delay the synchronization. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1329
* tests/stacking: Avoid random failures in focus testsSebastian Keller2020-06-215-5/+15
| | | | | | | | | | | Some tests were not waiting for the test client to actually issue destroy commands before checking their effect on the window focus. Similarly when mutter is supposed to change the focus based on a delay by sending a WM_TAKE_FOCUS to the client, this also could fail without synchronization with the client before checking the result. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1325
* tests/stacking/restore-position: Always use wait_reconfigureJonas Ådahl2020-05-291-4/+4
| | | | | | | | | wait_reconfigure ensures that the whole configure back and forth completes before continuing. Doing this after every state change ensures that we always end up with the expected state, thus fixes flakyness of the restore-position stacking test. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1279
* tests/stacking: Add test checking the initial sizeJonas Ådahl2020-05-071-0/+36
| | | | https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
* tests/stacking: Add test for checking restored positionsJonas Ådahl2020-05-071-0/+73
| | | | | | | Going maximized -> unmaximized should restore the previous position. The same for untiling, or going from tiled, to maximized, to floating. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
* tests/restore-size: Also test that untiling restores correctlyJonas Ådahl2020-05-071-0/+42
| | | | | | | | | Tiling, then untiling should restore to the size prior to tiling. Tiling, maximizing, then unmaximizing should also restore to the size prior to tiling. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
* tests/stacking: Test some maximize fullscreen interactionJonas Ådahl2020-05-071-0/+73
| | | | https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
* tests/stacking: Check that unmaximize to new size worksJonas Ådahl2020-05-071-0/+22
| | | | | | | A client that set a new fallback size while being maximized should not restore to the one prior to being maximized. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
* tests/stacking: Add test to verify we unmaximize correctlyJonas Ådahl2020-05-071-0/+53
| | | | | | | | | The test tests that (for both X11 and Wayland) that: * The client unmaximizes after mapping maximized to a predictable size * That the client unmaximizes to the same size after toggling maximize https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
* window-props: Read WM_TRANSIENT_FOR for override-redirect windowsMarco Trevisan (Treviño)2019-11-071-0/+13
| | | | | | | | | | | | | | As per the Extended Window Manager Hints standard version 1.3 [1] an override-redirect window can set a transient-for window per compositing and app-matching purposes. So just read the WM_TRASIENT_FOR property also for such windows, adapting the error in case they are transient for another O-R window and adding a test to check such case. [1] https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472512128 https://gitlab.gnome.org/GNOME/mutter/merge_requests/920
* window-props: Don't set override redirect windows as top-level parentMarco Trevisan (Treviño)2019-11-071-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Java applications might use override-redirect windows as parent windows for top-level windows, although this is not following the standard [1]. In such case, the first non-override-redirect child window that is created was marked as being on_all_workspaces since the call to should_be_on_all_workspaces() returns TRUE for its parent, and this even though the on_all_workspaces_requested bit is unset. When a further child of this window was added, it was set as not having a workspace and not being on_all_workspaces, since the call to should_be_on_all_workspaces() for its parent would return FALSE (unless if it is in a different monitor, and the multiple-monitors workspaces are disabled). Since per commit 09bab98b we don't recompute the workspace if the on_all_workspaces bit is unset, we could end up in a case where a window can be nor in all the workspaces or in a specific workspace. So let's just ignore the transient_for bit for a window if that points to an override-redirect, using the x11 root window instead. Add a stacking test to verify this scenario (was failing before of this commit). Fixes https://gitlab.gnome.org/GNOME/mutter/issues/885 https://gitlab.gnome.org/GNOME/mutter/merge_requests/895 [1] https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472512128
* window-x11: Use any focusable window as fallback delayed focus windowMarco Trevisan (Treviño)2019-07-084-4/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | As per commit f71151a5 we focus an input window if no take-focus-window accepts it. This might lead to an infinite loop if there are various focusable but non-input windows in the stack. When the current focus window is unmanaging and we're trying to focus a WM_TAKE_FOCUS window, we intent to give the focus to the first focusable input window in the stack. However, if an application (such as the Java ones) only uses non-input WM_TAKE_FOCUS windows, are not requesting these ones to get the focus. This might lead to a state where no window is focused, or a wrong one is. So, instead of only focus the first eventually input window available, try to request to all the take-focus windows that are in the stack between the destroyed one and the first input one to acquire the input focus. Use a queue to keep track of those windows, that is passed around stealing ownership, while we protect for unmanaged queued windows. Also, reduce the default timeout value, as the previous one might lead to an excessive long wait. Added metatests verifying these situations. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660 https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
* window-x11: Accept any focusable window as fallback focusMarco Trevisan (Treviño)2019-07-081-0/+46
| | | | | | | | | | | | | | As per commit f71151a5 we were ignoring WM_TAKE_FOCUS-only windows as focus targets, however this might end-up in an infinite loop if there are multiple non-input windows stacked. So, accept any focusable window as fallback focus target even if it's a take-focus one (that might not reply to the request). Added a stacking test to verify this. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660 https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
* metatest: Dispatch the destruction instead of sleeping after itMarco Trevisan (Treviño)2019-07-081-1/+1
| | | | https://gitlab.gnome.org/GNOME/mutter/merge_requests/669/
* window-x11: Focus the default window with delay while waiting for take-focusMarco Trevisan (Treviño)2019-06-242-3/+49
| | | | | | | | | | | | | | | | When requesting to a take-focus window to acquire the input, the client may or may not respond with a SetInputFocus (this doesn't happen for no-input gtk windows in fact [to be fixed there too]), in such case we were unsetting the focus while waiting the reply. In case the client won't respond, we wait for a small delay (set to 250 ms) for the take-focus window to grab the input focus before setting it to the default window. Added a test for this behavior and for the case in which a window takes the focus meanwhile we're waiting to focus the default window. https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
* tests: Verify focused window in closed-transient testsMarco Trevisan (Treviño)2019-06-242-3/+12
| | | | | | | Ensure that we have a focused window when closing transient windows with no-focus or no-take-focus atoms https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
* tests, stacking: Add tests with no-input and no-take-focus windowsMarco Trevisan (Treviño)2019-06-243-0/+64
| | | | | | | | | | | When a window with no frame, that doesn't accept focus and that has no take-focus atom set is destroyed, we ended up in not changing the current_focus window, causing a crash. Added test cases that verify this situation. Related to https://gitlab.gnome.org/GNOME/mutter/issues/308 https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
* tests: Add "closed-transient" testFlorian Müllner2018-07-301-0/+19
| | | | | | | | | When a transient window is destroyed, the expected behavior is that focus is passed to the ancestor if possible. This was broken for quite a while until the previous commit, so add a test case to make sure it doesn't happen again. https://gitlab.gnome.org/GNOME/mutter/issues/15
* tests: Add the "parent_exported" testOlivier Fourdan2018-07-181-0/+15
| | | | | | | | | | | | | | This test aims at checking that the transient relationship set using the xdg-foreign API is respected by mutter and that no crash occurs, such as the one in issue !174. Note: the crash from issue !174 occurs only if "attach_modal_dialogs" is set, so one has to change that default value to "true" to be able to trigger the crash: gsettings set org.gnome.mutter attach-modal-dialogs true Related: https://gitlab.gnome.org/GNOME/mutter/issues/174
* tests: Add test for testing that setting a parent affects the stackJonas Ådahl2015-12-231-0/+14
| | | | | | | A new test is added that tests that xdg_surface.set_parent (referred to as "transient for" in X11 terminology) affects the stack immediately. https://bugzilla.gnome.org/show_bug.cgi?id=755606
* Add a test for stacking vs. minimizationOwen W. Taylor2014-09-241-0/+18
| | | | | | Test that the guard window is in the right place. https://bugzilla.gnome.org/show_bug.cgi?id=737233
* test-runner: represent the guard window as '|' for assert_stackingOwen W. Taylor2014-09-241-1/+1
| | | | | | | | Allow putting '|' into the list of windows for assert_stacking to represent the position of the guard window. Not present is the same as at the beginning (bottom) of the list. https://bugzilla.gnome.org/show_bug.cgi?id=737233
* Don't restack windows while we are unmanaging themOwen W. Taylor2014-09-161-0/+22
| | | | | | | | | | | | Restacking the frame for a window while unmanaging the window is harmless, but for undecorated (in particular, client-side-decorated) windows, this causes problems because the window is typically destroyed by the client immediately after withredrawing the window. Skip windows flagged as being unmanaged when assembling the new stack and when comparing the old order to the new stack. Add a stacking test for this.
* Add a test framework and stacking testsOwen W. Taylor2014-09-124-0/+86
Add a basic framework for tests of Mutter handling of client behavior; mutter-test-runner is a Mutter-based compositor that forks off instances of mutter-test-client and sends commands to them based on scripts. The scripts also include assertions. mutter-test-runner always runs in nested-Wayland mode since the separate copy of Xwayland is helpful in giving a reliably clean X server to test against. Initially the commands and assertions are designed to test the stacking behavior of Mutter, but the framework should be extensible to test other parts of client behavior like focus. The tests are installed according to: https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests if --enable-installed-tests is passed to configure. You can run them uninstalled with: cd src && make run-tests (Not in 'make check' to avoid breaking 'make distcheck' if Mutter can't be run nested.) https://bugzilla.gnome.org/show_bug.cgi?id=736505
View Lorry Controller Status