After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 631308 - Dialogs attached to parent sometimes extend out of the screen
Dialogs attached to parent sometimes extend out of the screen
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2010-10-04 12:31 UTC by Milan Bouchet-Valat
Modified: 2011-03-22 01:59 UTC
See Also:
GNOME target: 3.0
GNOME version: ---


Attachments
Bug visible with Déjà Dup's preferences file chooser (140.17 KB, image/png)
2010-10-04 12:31 UTC, Milan Bouchet-Valat
  Details
if the attached dialog is not fit on screen, adjust parent's position (2.33 KB, patch)
2010-10-22 07:23 UTC, Maxim Ermilov
none Details | Review
Adjust the position of attached dialogs to fit on-screen (2.06 KB, patch)
2011-03-17 17:03 UTC, Florian Müllner
committed Details | Review

Description Milan Bouchet-Valat 2010-10-04 12:31:44 UTC
Created attachment 171695 [details]
Bug visible with Déjà Dup's preferences file chooser

If a modal dialog is attached to it's parent window and 1) the parent was small enough while 2) the child is high enough, then the bottom of the child dialog gets out of the screen.

This is a behavior I encountered using the Déjà Dup backup tool, which opens a transient file chooser dialog from its preferences dialog (see screenshot): the Choose/Cancel buttons are no longer visible.

I think we need a workaround for this kind of issue: either draw the child as a normal dialog with decorations, or draw it higher, even if the aesthetics are bad.

Another issue is: is this behavior from applications correct? Can we expect apps to have their transient modal dialogs always be relatively small? Should there be guidelines for optimal results, even if we push a workaround for this bug? (A related concern is that children wider than their parent windows don't look as nice as small dialogs with our animation.)
Comment 1 Florian Müllner 2010-10-04 12:44:59 UTC
(In reply to comment #0)
> I think we need a workaround for this kind of issue: either draw the child as a
> normal dialog with decorations, or draw it higher, even if the aesthetics are
> bad.

Another approach would be to move the parent up so that the attached dialog does fit the screen.
Comment 2 Milan Bouchet-Valat 2010-10-04 14:08:40 UTC
BTW, it also happens when extracting an archive using file-roller, depending on the place the main window appeared. This time, the file chooser went out of the screen on the left side.
Comment 3 William Jon McCann 2010-10-09 20:17:33 UTC
Yeah, it kinda stinks.  Basically the file chooser is kinda on crack and shouldn't need essentially the entire screen.  Hopefully we can address that at some point.  But for now perhaps we should try to constrain the dialog to the size of parent.  If the minimum size of the dialog won't permit that than fine.  But in the above screenshot and the vast majority of cases (for non-utility/transient type parent windows) this will work fine.

If we want to get fancy perhaps we could draw a little resize grippy over the lower right corner of the modal and allow it to be resized when necessary.  Though, ideally, this shouldn't be necessary.
Comment 4 Dan Winship 2010-10-09 23:29:49 UTC
if the parent window is not maximized, and is near the bottom of the screen, the dialog might not fit on the screen even if it's "reasonable"-sized. (OS X slides the parent window upward to make the attached dialog fit in this case.)
Comment 5 Maxim Ermilov 2010-10-22 07:23:47 UTC
Created attachment 172976 [details] [review]
if the attached dialog is not fit on screen, adjust parent's position
Comment 6 Tomas Frydrych 2010-10-22 07:58:15 UTC
I don't think moving the parent is the right thing to do here; I for one would be rather annoyed if the wm starts moving around my carefully arranged application windows. If we really think that the WM should be addressing this issue, then it should be done by moving the offending window, not the parent. But I am not convinced this is a WM problem, but then WMs have a history of jumping through hoops because of badly behaved applications.
Comment 7 Jason Clinton 2011-03-08 17:32:40 UTC
Pasting this IRC conversation about this for future reference in case I get time to cook up a patch for this:

<jclinton> I don't see any open mutter bugs about modal dialogs that are bigger than their parents and those getting rendered partially offscreen
<jclinton> is there some design thinking behind how that should work?
<jclinton> should the parent window move so that the attached modal dialog is rendering entirely on-screen
<jclinton> ?
<mccann> there's a bug somewhere
* mccann looks
<jclinton> found it https://bugzilla.gnome.org/show_bug.cgi?id=631308
<bebot> Bug 631308: normal, Normal, ---, mutter-maint, UNCONFIRMED, Dialogs attached to parent sometimes extend out of the screen
<jclinton> mccann: sorry
<mccann> might be in shell though
<jclinton> like the Empathy Help>About dialog is a perfect example
<jclinton> since that window is narrow and nearly always by the end of the screen
<mccann> I would design empathy differently tbh
<mccann> but yeah
<mccann> https://bugzilla.gnome.org/show_bug.cgi?id=631308
<bebot> Bug 631308: normal, Normal, ---, mutter-maint, UNCONFIRMED, Dialogs attached to parent sometimes extend out of the screen
<jclinton> if we moved the parent, people would be pretty angry, I guess
<jclinton> ... unless we moved it back
<jclinton> which sounds like crack
<jclinton> anyway this seems like something which needs a ~10 work-around for 3.0; it's a pretty glaring fail when it happens
<jclinton> ~10 line, that is
<jclinton> mccann: what kind of short-term fix would you be comfortable with, if any?
<mclasen_> I think you want to push in the sheet
<mclasen_> like gtk does for menus and other popups
<jclinton> and let it grow back to requested size if parent is relocated?
<mclasen_> I meant moving, not resizing
<jclinton> oh, hum
<mclasen_> ie shift it left/right to move it on the monitor
<jclinton> ok, but not up/down since that would obscure the attachment effect, right?
<mclasen_> yeah, I guess
<mclasen_> also seems a much less likely case to have it hang out at the bottom
<jclinton> ok, alright if I paste this conversation in the bug?
<mclasen_> sure
Comment 8 Frederic Peters 2011-03-11 08:08:40 UTC
This was pointed as very important by the marketing team in our latest blocker bugs meeting, I am marking it as a blocker for 3.0 so it can be tracked easily.

"from a UX perspective, the file chooser and about dialogs getting partially rendered off-screen when attached is pretty glaring; could be a simple fix, → discussion deferred until Shell team decides if they want to focus on resize or shift (or both.)"
Comment 9 Dan Winship 2011-03-15 21:11:56 UTC
(In reply to comment #7)
> <jclinton> if we moved the parent, people would be pretty angry, I guess
> <jclinton> ... unless we moved it back
> <jclinton> which sounds like crack

That's what OS X does. (Unless you move the window while the dialog is visible, in which case it doesn't move back to its original spot after the dialog goes away.) Also, it animates the window motion.
Comment 10 Florian Müllner 2011-03-17 17:03:32 UTC
Created attachment 183654 [details] [review]
Adjust the position of attached dialogs to fit on-screen

As the position of attached modal dialogs is determined entirely
by the position of the parent window, the dialog may end up
partially off-screen (especially if the dialog is wider than the
parent). In this case, diverge from the calculated position and
try to fit the dialog on-screen.

This is the other approach discussed, e.g. pushing the attached dialog around to fit on-screen. It's quite a lot simpler to do it both vertically and horizontally, so this is what it does - I can look into adjusting the position horizontally only if this is the approach we want.
Comment 11 William Jon McCann 2011-03-19 22:04:40 UTC
As mentioned on IRC.  I think it is a lot easier at this point to use the approach of keeping the modal on screen.  It is less likely to require nice animations for moving windows around.  One thing to check is what happens when moving windows with modals between monitors.
Comment 12 Owen Taylor 2011-03-22 01:45:16 UTC
Review of attachment 183654 [details] [review]:

Patch looks good (and nice and short!), and it doesn't look too weird when the attached dialogs aren't properly attached. Seems good to me.
Comment 13 Florian Müllner 2011-03-22 01:59:20 UTC
Attachment 183654 [details] pushed as 92e317e - Adjust the position of attached dialogs to fit on-screen