[ Bug #18650 ] Unexpected monitor focus changes

[joten]

Import from berliOS:

Date: 2012-Jul-02 06:31
Submitted By: fuhsjr00
Assigned To: fuhsjr00
Category: None
Priority: 5
Bug Group: None
Resolution: None
Summary: Unexpected monitor focus changes

Original Submission:

There are a few places where monitor focus changes unexpectedly (I believe).

Case 1: When the last window on a view is closed in a multi-monitor
setup, the active monitor is switched to another monitor.

Expected: I think that the behavior should be to stay on the empty view
on that monitor until the user explicitly changes monitor or view.

Case 2: Sometimes switching a view from an empty view to a non-empty
view causes a monitor switch. This one can't be reproduced as reliably
as the previous case.

Reproduce steps (assume 8.2.1 default hotkeys):

1. Setup monitor 2 with at least one empty view and one non-empty view.
2. Setup monitor 1 with a non-empty view.
3. Make the non-empty view active on monitor 1 and the empty view active
   on monitor 2.
4. Make monitor 2 the active monitor.
5. Switch to monitor 1 with the "#," hotkey
6. Cycle through some of the windows on monitor 1 with #Up and #Down. I
   can't recommend a specific pattern.
7. Switch to monitor 2 with the "#." hotkey
8. Switch to the non-empty view with the corresponding # hotkey.

Observe: Sometimes the active monitor will switch back to monitor 1.

Expected: The active monitor should not change, and the window activated
should be the active window for the non-empty view on monitor 2.

Followups

2012-Dec-05 01:40 fuhsjr00
I've submitted the suggested fix for case 1 at r145:dc91cfafb64c. I
think it agrees with the former behavior of bug.n much better.

I can still frequently reproduce case 2.

---

2012-Dec-04 04:07 fuhsjr00
I think this fixes the problem in a way that clashes with the original
flow of the system. I used to be able to change the active window with
the mouse. Now I can't. In fact, bug.n somewhat violently resets the
window.

I think an approach that would work better would be to, on close:

1. Determine the next window that should be active.
2. Activate that window (activate something on the active monitor,
   regardless)
3. Close the window that was to be closed.

This might keep the monitor/window focus from unexpectedly changing
without forcing the user to use the hotkeys to navigate.

---

2012-Dec-01 21:44 joten
This should be solved. If there is still a problem this ticket can be
re-opened.

---

2012-Oct-16 18:12 joten
I changed the behaviour of bug.n. Instead of changing the monitor
accordingly to the active window, the active monitor is maintained and
the active window set accordingly.

---

2012-Oct-14 18:47 joten
I could reproduce case 1.
The problem might be that Windows activates the next window in the stack
and bug.n resets the active monitor accordingly. I will have a look into
it.

I could not reproduce case 2.

---

2012-Oct-13 19:54 joten
I will try to reproduce the problem.

---

2012-Jul-02 06:43 fuhsjr00
Case 1 should be adjusted to indicate that killing a window on one
monitor can, in any case, cause the active monitor to change.

Reproduce steps:

Click on window on monitor 1. Click on window on monitor 2 and close it
via "#c".

Observe: Monitor focus changes back to monitor 1. This happens
regardless of whether the closed window was the last window in the
view.

[joten]

I merged this issue with issue #14, closing this one as duplicate.