Window management - when a modal dialog is placed on another viewport it receives events from the viewport with parent window

[Jean-Baptiste Lallement]

Binary package hint: unity

TEST CASE:
1. Launch any application with parent and a modal dialog. In this test I chosen gedit. So move to the top left viewport and launch gedit
2. Type some text and close the window to make the confirmation dialog appear
3. Move the confirmation dialog to the right viewport (CTRL+ALT+SHIFT+RIGHT)
4. Go back to the left viewport (CTRL+ALT+LEFT)
5. Ensure that the parent window receives the focus by clicking on it and move it to the bottom viewport (CTRL+ALT+SHIFT+DOWN)
  -> RESULT: The dialog on other viewport moves to the bottom.
6. Move the parent window to the right viewport (CTRL+ALT+SHIFT+RIGHT)
  -> RESULT: The viewport switch to the right, but the dialog is not there anymore because it moved to the left viewport
7. Go back to the parent window, with the dialog on another viewport and press ESC
  -> RESULT: The dialog is closed

Expected:
- The parent window should move instead of the dialog
- The dialog should not receive keyboard events when it is not on the active viewport.

I attached a video to illustrate this issue.

Desired Solution:

- Sheet style dialogues will solve this issue when they land.
- In the meantime moving the parent window to a different workspace should also move the confirmation dialogue (and also vice versa)

[Omer Akram (om26er)]

compiz issue I believe, confirming as I can reproduce this with the given steps.

[James Haigh (james.r.haigh)]

"5. Ensure that the parent window receives the focus by clicking on it..."
Note that the parent window will not become focused. While it is waiting for the dialog to close, it will transfer it's focus to the dialog whenever it receives focus.

Note also that maximised windows don't clearly indicate that they are inactive (See bug #830598), so without knowing that there's a dialog, the parent window if maximised appears unresponsive. Occasionally parent windows and dialogs do get separated due to WM bugs, so it is possible to be unaware of a dialog on a different workspace.

Possible solutions:
* The focused window must _always_ be on the current workspace.
* Dialogs and their parent windows must _always_ be on the same workspace; moving one should also move the other.

[James Haigh (james.r.haigh)]

"* The focused window must _always_ be on the current workspace."
This is to solve bug #773587.

[James Haigh (james.r.haigh)]

s/This is to solve bug #773587./This is actually solving bug #773587./

[James Haigh (james.r.haigh)]

Solutions:
* Fix bug #773587. The focused window must _always_ be on the current workspace.
* Parent windows should be able to have focus, but when focused any click or keystroke will prompt it to transfer focus to the dialog.
* There should perhaps be an option to keep dialogs and their parent windows on the same workspace; moving one should also move the other.

I tend to do everything from the keyboard. The 2nd solution would allow me to move, resize, minimise, etc, the parent window.

I think Ayatana Design should be involved in this.

[John Lea (johnlea)]

Sheet style dialogues should fix this issue, but in the meantime it is a valid bug so confirmed from a design prospective.

[James Haigh (james.r.haigh)]

"Desired Solution:

- Sheet style dialogues will solve this issue when they land.
- In the meantime moving the parent window to a different workspace should also move the confirmation dialogue (and also vice versa)"

John: This should be optional. There is a use case for moving the dialog out of the way. I sometimes find that in order to answer the dialog, I need to look at something obscured by the dialog. Fixing bug #830637 would allow me to temporarily minimise the dialog.

Please could you provide a link relating to sheet-style dialogues.

"* Parent windows should be able to have focus, but when focused any click or keystroke will prompt it to transfer focus to the dialog."

I've split this bit to bug #832301.