Bug 684802

Summary: Modal dialog cannot be properly moved
Product: [Fedora] Fedora Reporter: Vít Ondruch <vondruch>
Component: gnome-shellAssignee: Owen Taylor <otaylor>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: beland, clancy.kieran+redhat, cra, cskeogh, maxamillion, otaylor, samkraju, walters
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 20:00:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Initial position of FileRoller window
none
File open dialog none

Description Vít Ondruch 2011-03-14 14:37:29 UTC
Description of problem:
Modal dialog can be moved around the desktop only using the parent window title bar. This is a bit odd behavior. While this behavior may make sense, it is half baked IMO. If this is considered feature, it should be revisited ASAP. The idea behind is not bad, but has apparently some drawbacks.

Steps to Reproduce:
1. Open File Roller and snap it to the left screen edge.
2. Click 'Extract to' will open standard file browse dialog, which is unexpectedly partly out of the screen. Note that the "File Roller" window has smaller extend than the file browse dialog by default.
3. While top of the dialog itself shows "grab" cursor, it cannot be moved.
4. While pressing Alt+F7, the dialog cannot be moved again.
5. However, it can be moved by dragging the parent title.
  
Expected results:
1. If the window show "grab" cursor, it should be movable. It doesn't matter if it is by holding left mouse button or pressing Alt+F7
2. Dialog is unexpected to appear just partly on the screen.
3. When the parent window is maximized, you still cannot move the dialog around, which may be annoying when it covers some information behind.

Comment 1 Owen Taylor 2011-04-24 19:02:15 UTC
Most of these issues have ben addressed in the current builds of Mutter and GNOME Shell (windows are constrained to the screen, grabbing the titlebar of the child starts moving the parent)

In terms of obscuring information in the parent window - that's really an application design issue - in general, application should use modal dialogs very sparingly and not for things that would require the user to collect data from the parent window.

Comment 2 Vít Ondruch 2011-04-26 13:26:44 UTC
Created attachment 494901 [details]
Initial position of FileRoller window

Comment 3 Vít Ondruch 2011-04-26 13:27:28 UTC
Created attachment 494902 [details]
File open dialog

Comment 4 Vít Ondruch 2011-04-26 13:33:34 UTC
Please look at https://bugzilla.redhat.com/attachment.cgi?id=494901 which shows initial position of the File Roller window (bit of extreme but not completely unrealistic). Also note that my laptop screen (right part of screenshot, main screen) has lower height resolution then my external monitor (left part of screenshot).

On the second screenshot (https://bugzilla.redhat.com/attachment.cgi?id=494902) you can see in what position is the File Open dialog opened and half of the dialog is missing.

The issue is that you cannot move the dialog up, since there is somehow strangely computed offset between the parent window and the modal dialog. So the dialog is movable just in horizontal way. This is plain wrong.

Comment 5 Kieran Clancy 2012-02-01 23:41:27 UTC
How is a developer supposed to know that a user won't need information hidden below a modal dialog? For example, in bug 783614 there is the example of the Firefox save dialog -- the problem being that you can't see the window contents to help you write a good filename.

The application developer is just going to blame this on gnome-shell, and vice versa. Perhaps someone will say "you need to choose the filename before you open the dialog". This is not always easy. I often end up having to cancel the file download so I can have a better look at the window and then start the download again.

At the moment, one workaround is to hit the top-left of the screen, hover over the Firefox window (now not obscured by a modal dialog -- this will probably be fixed at some point), and use the scroll wheel to zoom in on the window contents.

You said "in general, application should use modal dialogs very sparingly and not for things that would require the user to collect data from the parent window." Do you think there's a bug in Firefox here? Isn't Firefox using a modal dialog in exactly the kind of case they are designed for?

The problem these gnome-shell modal dialogs try to solve is "user triggers modal dialog, the dialog gets moved somewhere else, then the user is confused about being unable to interact with the parent window." The problem they create is "user triggers modal dialog, then realises they need to refer to something on the parent window, but can't."

Is there really no solution that solves the first problem while not creating the second? What if the modal dialog could be dragged around, but restricted so that it always had to overlap part of the parent window?

Comment 6 Jan Horak 2012-02-28 15:40:15 UTC
*** Bug 783614 has been marked as a duplicate of this bug. ***

Comment 7 Fedora End Of Life 2012-08-07 20:00:50 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping