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

Reported by Jean-Baptiste Lallement on 2011-04-08
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Wishlist
John Lea
Compiz
Wishlist
Unassigned
Unity
Wishlist
Unassigned
compiz (Ubuntu)
Wishlist
Unassigned
unity (Ubuntu)
Wishlist
Unassigned

Bug Description

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)

Jean-Baptiste Lallement (jibel) wrote :
Omer Akram (om26er) wrote :

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

Changed in unity:
status: New → Confirmed
Changed in unity (Ubuntu):
status: New → Confirmed
Changed in compiz (Ubuntu):
status: New → Confirmed
James Haigh (james.r.haigh) wrote :

"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) wrote :

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

James Haigh (james.r.haigh) wrote :

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

James Haigh (james.r.haigh) wrote :

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) wrote :

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

description: updated
Changed in ayatana-design:
assignee: nobody → John Lea (johnlea)
importance: Undecided → Wishlist
status: New → Fix Committed
tags: added: udo
James Haigh (james.r.haigh) wrote :

"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.

John Lea (johnlea) on 2011-09-28
Changed in ayatana-design:
status: Fix Committed → Fix Released
John Lea (johnlea) on 2011-10-18
tags: added: udp
Changed in unity:
milestone: none → backlog
Changed in ayatana-design:
status: Fix Released → Fix Committed
Tim Penhey (thumper) on 2012-09-14
Changed in unity:
milestone: backlog → none
John Lea (johnlea) on 2012-10-09
Changed in unity:
importance: Undecided → Wishlist
Changed in unity (Ubuntu):
importance: Undecided → Wishlist
Changed in compiz:
status: New → Triaged
Changed in unity (Ubuntu):
status: Confirmed → Triaged
Changed in unity:
status: Confirmed → Triaged
John Lea (johnlea) on 2012-10-09
Changed in compiz (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Wishlist
Changed in compiz:
importance: Undecided → Wishlist
summary: - when a modal dialog is placed on another viewport it receives events
- from the viewport with parent window
+ Window management - when a modal dialog is placed on another viewport it
+ receives events from the viewport with parent window
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers