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 697680 - Can't see content behind modal dialog
Can't see content behind modal dialog
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.8.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 684849 722839 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-04-10 02:12 UTC by Sam Bull
Modified: 2021-07-05 14:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sam Bull 2013-04-10 02:12:11 UTC
The new design for modal dialogs are to attach them to their parent window. This seems to have been done to fix the common experience of losing the modal dialog in the window stack. This however has caused a new common problem, when the user tries to move the modal dialog to peek at something in the parent window (perhaps to work out what to name a file etc).

A solution that solves both issues, is to snap modal dialogs. That is, dragging the modal window moves the modal window, allowing you to peek behind it. When you let go, it springs back to its attached position.

Discussion about this: http://www.mail-archive.com/gnome-shell-list@gnome.org/msg07348.html
Comment 1 Gabriel 2013-04-10 06:03:52 UTC
That sounds like a good solution and it is unique (not windows nor
mac).

+1

Gabriel
Comment 2 Allan Day 2013-04-10 08:24:17 UTC
Hey Sam, this is an interesting idea. Thanks for the suggestion.

I'm not entirely sure about it though. Couldn't it be a bit annoying? Being able to see the content below but not interact with it seems like it could just lead to frustration....
Comment 3 Milan Bouchet-Valat 2013-04-10 08:32:19 UTC
If that's not too hard to do implementation-wise, it could be a good idea. I don't see how it could hurt the user experience - it actually makes it more fun!
Comment 4 Sam Bull 2013-04-10 11:32:13 UTC
Well, if the window snaps back to it's position immediately, the user is never given the chance to click on the content behind the window, thus it would not appear any more interact-able than the current implementation.

The issue is the case mentioned at the beginning of that thread:
"I'm attaching a very annoying case that I encounter frequently. When I open a PDF and want to save it on the disk, the modal file dialog asks for the name of the file. The thing is that modal window can not be moved e.g. I can't look at the title of the PDF or whatever to get a clue for naming the file."

This is an issue I recognise, and have many times in the past been slightly frustrated with. I click the save button, it asks for a document name, and my mind goes blank. Because I can't see anything behind the modal dialog, I end up having to cancel the interaction, decide on a name and memorise it for a couple of seconds, and bring up the save dialog again.

This solves the issue, by allowing you to peek behind the content. Because this can only be done by dragging the window, there is no opportunity to try and interact with the parent window, until you stop dragging. At which point the modal dialog snaps back into place before the user has a chance to do anything else.
Comment 5 awilliam 2013-04-10 11:39:20 UTC
I +1 the frustration of Save-As dialog that obscures information [why can't the @&*^@&*@*( Save-As suggest a @&*@&* filename, especially when it is referring to a downloaded file,etc...  but that is an application specific issue].  The current behavior makes sens to me, and this seems like a reasonable compromise;  not ideal since I can't hightlight-copy anything, but at least I can see it.
Comment 6 Florian Müllner 2015-03-05 10:08:15 UTC
*** Bug 722839 has been marked as a duplicate of this bug. ***
Comment 7 Florian Müllner 2015-03-05 10:08:25 UTC
*** Bug 684849 has been marked as a duplicate of this bug. ***
Comment 8 GNOME Infrastructure Team 2021-07-05 14:33:32 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.