Skip to content

Input focus tests

Sergii Stoian edited this page Oct 23, 2020 · 22 revisions

Test cases

Source - application or window that was active focused before action occurs.

Target - application or window that becomes active or focused.

Window click (PR #82)

Desired behaviour

  • Target application:
    • clicked window titlebar becomes black
    • clicked window ordered front (other app windows should at the old level)
    • main menu appeared
    • input focus stays on focused window (keyboard presses should go to this window)
    • WM’s `scr->focused_window` should point to this window
  • Source application:
    • previously focused window titlebar becomes gray
    • main menu disappeared

Action calls

  1. Click on window decorations (title and resize bars).
    • handleButtonPress() - event.c
      • *desc->handle_mousedown() - event.c
        • titlebarMouseDown() - window.c
          • wSetFocusTo() - actions.c
            • wWindowFocus() - window.c
            • wWindowUnfocus() - window.c
          • wRaiseFrame()
  2. Click inside window (contents managed by the application).
    • handleButtonPress() - event.c
      • *desc->handle_mousedown() - event.c
        • frameMouseDown() - window.c
          • wSetFocusTo() - actions.c
            • wWindowFocus() - window.c
            • wWindowUnfocus() - window.c
          • wRaiseFrame()
  3. Click inside GNUstep window Click inside GNUstep window is not handled by WM. The calls below is event handling of mapped or focused windows generated by GNUstep actions (main menu and hidden panels appearance).
    • handleMapRequest() - event.c
      • wSetFocusTo() - actions.c
        • wWindowFocus() - window.c
        • wWindowUnfocus() - window.c

Bugs

  • [FIXED] If GNUstep app non-key window was clicked inside, previsous key window raises and focus flickers. Possible cause: window click activates application (-activateIgnoringOtherApps:). This leads to ordering front all application windows. It is correct for appicon double-clicking but not for clicking inside window. Solution: [NSWindow makeKeyAndOrderFront:] calls [NSApp unhide:] (-activateIgnoringOtherApps: is called) before key and main window was set. Backport: PR #82 in gnustep/libs-gui

Appicon double-click

Desired behaviour

  • Target application
    • all windows of application ordered to front of other apps’ windows
    • main menu appeared
    • key window becomes focused (WApplication->last_focused)
  • Source application
    • key window titlebar becomes gray
    • main menu disappeared

Action calls

  1. Click on NOT docked app icon
    • processEvent: - XGServerEvent.m
      • handleButtonPress() - event.c
        • appIconMouseDown() - appicon.c
          • iconDblClick() - appicon.c
            • wUnhideApplication() - actions.c
  2. Click on docked app icon
    • processEvent: - XGServerEvent.m
      • handleButtonPress() - event.c
        • iconMouseDown() - dock.c
          • iconDblClick() - dock.c
            • wUnhideApplication() - actions.c

Bugs

  • N/A

Window/panel open

Desired behaviour

Events: application start, windows creation, Open/Save dialogs, alert panels.

  • opened window/panel becomes focused
  • main menu appears

Action calls

  • handleMapRequest() - event.c
    • wManageWindow - window.c
      • wSetFocusTo() - actions.c
        • wWindowFocus() - window.c
        • wWindowUnfocus() - window.c

Bugs

  • N/A

Window/panel close

Desired behaviour

  • While other app window exists
    • next app window becomes focused
  • Last window
    • GNUstep: main menu receives input focus
    • X11: previously focused window of other application becomes focused

Action calls

  1. Closed by WM (titlebbar “Close”/”Kill” button click);
    • handleButtonPress() - event.c
      • buttonMouseDown() - framewin.c
        • windowCloseClick() - window.c
          • wClientSendProtocol() - window.c [sends DELETE_WINDOW atom to client window]
  2. Closed by application (user selects menu item, use keyboard shortcuts, main menu and panels hiding).
    • handleUnmapNotify() - event.c
      • wUnmanageWindow() - window.c

Bugs

  • [FIXED] For X11 applications: previously focused window becomes focused even if other app windows exist. Should focus next application window.
  • [FIXED] GNUstep: if perviously focused windows is other app’s window and available current app’s window is shaded - focus goes to other app’s window.

Appicon right-click menu

Desired behaviour

  • GNUstep appicon
    • main menu appears without focus switch, app activation or unhiding.
  • X11 appicon
    • Short menu (“Launch”, “Bring Here”, “Hide”, “Kill”) appears with app’s name in the title. No focus switch, app activation or unhiding.

Action calls

  1. GNUstep appicon
    • [NSIconWindow rightMouseDown] - NSApplication.m
      • [NSMenu popUpContextMenu:withEvent:forView:]
    • handleMapRequest() - event.c
      • wManageWindow() - window.c
  2. X11 appicon
    • handleButtonPress() - event.c

Bugs

  • [FIXED] Hidden GNUstep application activates with blacked “Hide” menu item. Fixed: wManageWindow() called on MapRequest of transient menu window calls wUnhideApplication(). Since GNUstep app handles this case, wUnhideApplication() call was disabled for GNUstep applications.

Open window via right-click menu of hidden GNUstep app

Desired behaviour

  • window opened focused
  • aplication displays hidden windows, focus stays on window desired for this action

Action calls

Actions from “Appicon right-click menu” plus actions from “Window/panel open”.

Bugs

  • [FIXED] When window/panel ordered front key (focused) window incorrect - window then was key before hide instead newly opened. Fixed: do not call WM’s wUnhideApplication() for GNUstep apps.

Miniaturize/deminiaturize window (with mouse or keyboard).

Desired behaviour

The same as in “Window/panel close” test

Action calls

  • handleButtonPress() - event.c
    • buttonMouseDown() - framewin.c
      • wIconifyWindow() - actions.c
        • wClientSetState() - client.c
        • wSetFocusTo() - actions.c

Bugs

  • [FIXED] For X11 applications: previously focused window becomes focused even if other app windows exist. Should focus next application window.

Hide application (with mouse or keyboard)

Desired behaviour

  • all windows are unmapped
  • previously focused window of other application becomes focused
  • Workspace application should hide all windows except main menu

Action calls

  1. Key press (Cmd-h)
    • handleKeyPress() - event.c
      • [GNUstep] XSendEvent(KeyPressMask)
      • [X11] wHideApplication() - actions.c
  2. Left titlebar button right-click
    • windowIconifyClick() - window.c
      • [GNUstep] wClientSendProtocol(w_global.atom.gnustep.wm_hide_app)
      • [X11] wHideApplication() - actions.c
  3. “Hide” menu item
    • hideApplication: - XGServerWindow.m
      • _sendRoot::::::: - XGServerWindow.m
        • XSendEvent() _WINDOWMAKER_WM_FUNCTION_ATOM, WMFHideApplication
    • handleClientMessage() - event.c
      • wHideApplication() - actions.c

Bugs

  • [FIXED] Workspace should hide all windows exept main menu if no other applications available.
  • [FIXED] For application that has windows on different workspaces:
    • on uhide those windows become visible which belongs to this workspace;
    • on workspace switch unhidden (before) windows should be visible.
  • *[FIXED]*(back-art + Workspace) Workspace becomes unhidden if main menu received WM_TAKE_FOCUS atom. Focus request sent in a response to wSetFocusTo() call where window parameter is NULL.

<<<<<<< HEAD

Application quit

=======

Switch between applications with ‘Cmd-Tab’ key equivalent

Desired behaviour

Identical to “Appicon double-click”

Action calls

Bugs

  • N/A

Application quit

Desired behaviour

  1. Previously active app has opened window
  2. Previously active app has minimized window
  3. Previously active app is menu-only

Action calls

  • handleDestroyNotify() - event.c [?]
    • wApplicationDestroy() - application.c

Bugs

  • [FIXED] GNUstep menu-only application doesn’t receive focus if it’s previous application to just closed one in focus list.
  • [FIXED] If application opened in workspace 1 was activated after switch from workspace 2 (were Workspace was active), closing the application on workspace 1 lead to switching to workspace 2.

Workspace switch

Desired behaviour

Action calls

Bugs

  • [FIXED] X11: if next focused window is on different workspace - switch to it.
  • [FIXED] GNUstep: if next focused window is on different workspace - switch to it.
  • Focused window might stay below other window after switch. Actually this is a GNUstep’s problem. It raises windows on application activation. Test to reproduce:
    • 2 application should be opened and active on different workspace;
    • on switch fading workspace name is not visible because covered by app windows.

Menu items autoenabling

Bugs

  • Workspace menu visible on empty workspace should not have enabled items which correspond to NSFirstResponder. For example, we have File Viewer opened on workspace 1. Next we make switch to empty workspace 2. Menu item “File->New Folder” must be disabled because File Viewer was left on workspace 1 and is out of user’s focus.