"mouse_warping none" causes dmenu to appear on pre-focussed monitor in multi-monitor setup

[resingm]

I'm submitting a…

[x] Bug
[ ] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

Multi-monitor setup.
Monitor A has workspace "1" with windows opened.
Monitor B has workspace "2" with no open windows.
Option mouse_warping none is set.
Focus is on workspace "1".
Focus switches to workspace "2".
Press combination to open dmenu
dmenu appears on the previously focussed workspace "1" instead of the currently focussed workspace "2".

If a window is opened in the focussed workspace, dmenu appears on the correct monitor.
The issue exists only, when an empty workspace is focussed.

Expected Behavior

I would expect dmenu to open on the status bar of the focussed monitor.

Reproduction Instructions

Current setup:
Multi-monitor setup, where monitor A has workspace "1". Monitor B has workspace "2".
Workspace 2 is completely empty, no window is opened.
Workspace 1 has any window opened, let's say a terminal window.

The i3 config has the option mouse_warping none set.

Now, have the focus on the open window in workspace "1". Toggle the focus with your key combination, or with the mouse to workspace "2" on the other monitor.
Now, press the key combination to open dmenu, which usually appears on the status bar on the monitor of the focussed window. The option mouse_warping none causes, that dmenu will appear on the status bar of the previously active monitor.

Environment

Output of i3 --moreversion 2>&-:

i3 version: 
Binary i3 version:  4.18.1 (2020-04-23) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.18.1 (2020-04-23) (pid 882) abort…)
Loaded i3 config: /home/max/.config/i3/config (Last modified: Tue 28 Jul 2020 09:25:51 AM CEST, 392 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

Config file

https://pastebin.com/8x4LR2b1

- Linux Distribution & Version:
Arch Linux, Kernel 5.7.10-arch1-1

- Are you using a compositor (e.g., xcompmgr or compton):
No

[i3bot]

I don’t see a link to logs.i3wm.org. Did you follow https://i3wm.org/docs/debugging.html? (In case you actually provided a link to a logfile, please ignore me.)

[NMertsch]

I have the same problem and it not only affects dmenu.

Environment

• Ubuntu 20.10
• i3 version 4.18 (2020-02-17).
• default config, the only change is mouse_warping none

Original state

• 2 Monitors
  • Monitor A: workspace 1, empty (no windows, only i3bar)
  • Monitor B: workspace 2, occupied (e.g. firefox)
• Focus on a window on workspace 2 (e.g. firefox)
• i3bar shows workspace 2 as active (blue background)
• mouse cursor is on workspace 2 and is not moved

How to reproduce

• Focus workspace 1 (Alt+1)
  • i3bar now shows workspace 1 as active (blue background)
  • expected behavior
• Open dmenu (Alt+d)
  • dmenu opens on Monitor B (workspace 2)
  • unexpected behavior
• From dmenu: launch a program (e.g. firefox)
  • program opens on Monitor A (workspace 1)
  • i3bar still shows workspace 1 as active
  • expected behavior
• Use keyboard to interact with the launched program (e.g. Ctrl+t to open a new tab)
  • the previously active window on workspace 2 reacts to that input
  • the newly launched window does not react
  • i3bar now shows workspace 2 as active
  • unexpected behavior

Further observations

• when an empty workspace is focused (according to i3bar), dmenu opens on the workspace where the mouse cursor is
• new windows are always correctly spawned on the focused workspace
• when a window is spawned on an empty, focused workspace and the mouse cursor was on another workspace when the program was spawned, keyboard input will be reacted to by a windows in the workspace with the mouse cursor. This leads to a switch of focus to that workspace