I could not attach the video (too large), so it's here:
http://www.youtube.com/watch?v=YUfK83eY7dI

Oh, and reproduced on two different computers, Thinkpad T500 and Thinkpad X220. Both Fedora 19, roughly same package versions.

This is actually not a bug but intentional see: https://bugzilla.gnome.org/show_bug.cgi?id=693991

Thanks, drago, for the link.

I have seen the same happening yesterday at GUADEC during Jakub Steiner's presentation about Blender. Any time he opened preferences (a new window), the whole blender screen disappeared and he had to manually switch to it again after closing the preferences window. If you don't have many applications running, it's not that hard (a single Alt+Tab), but if you do, it's very uncomfortable (the fullscreen window is at the end of the app list).

I tried other applications, like Firefox. If you have Firefox in full screen (and no other app running) and open its preferences, Firefox disappears and you see just a preferences window on an empty desktop. That's very confusing. If you close the preferences window, Firefox app doesn't return back -- you see an empty desktop. That's even more confusing.

I have talked to Jakub Steiner and Alan Day a bit in person, they seem to believe that fullscreen apps are somewhat different kind of apps that should behave differently than normal windows. I believe there are some use cases which are not taken into account, there's a few of them:

1. I'm watching full-screen video with subtitles and want to translate an unknown word. The moment I open a dictionary, the video disappears and I can't re-write the word into dictionary. I'm forced to switch back to the video, remember the unknown word (it can be a very long one with a difficult spelling) and then put it into the dictionary. Or I have to demaximize the video (and maximize it back again, once I translated the word). So many useless actions that weren't necessary before.

2. I'm playing a fullscreen game and I died. I have to wait several minutes for a new round (e.g. Counter-Strike style game). In GNOME < 3.8, I could have switched to a chat or some other app and still see the game in the background. So I would have chatted for a few minutes and the moment I see I'm alive again, I'd switch to the game window. With GNOME 3.8, I can do that, and I have to periodically (the more often the better, because I don't want to miss the round beginning) switch between the game and the chat/browser/something app.

3. I have an IDE full-screen, because I have a 12" screen and I need to see as many source code lines as possible. I need to switch to a terminal/documentation window very often, to compare some source code samples/diffs/examples or see function documentation. Often I need to see it side by side. In GNOME < 3.8, I could have a full-screen IDE and an overlapping window to switch into in I need it (source code in IDE is usually aligned to the left side, so the overlapping window would be on the right side). In GNOME 3.8, I need to un-fullscreen the IDE any time I need to compare something side by side.

4. I have a full-screen Firefox, because my screen is small, or I don't want to be disturbed by anything else. But sometimes I need to run a calculator/dictionary/chat/something to compute/translate/ask about something. If I run this app, my Firefox window disappears and I don't see the text I wanted to operate on. I need to de-fullscreen Firefox first, every time this happens.

I don't really see this as an improvement. Jakub Steiner proposed that fullscreen apps should not disappear completely, but rather be switched from fullscreen to a standard maximized state. This would really solve some of my use cases. I don't see it completely optimal, because I would still be required to switch to full-screen back again, after I finish translating/comparing/whatever, but yes, it's better than making the windows disappear completely. Personally, the optimal solution for me is the way it worked in the whole history (i.e. treat fullscreen windows the same way as any other windows), and I don't really understand the problem stated in bug 693991. But it seems that I'm the minority here.

If you intend to continue to do some special operations on full-screen windows, I propose this solution (which Jakub Steiner seemed to regard as a reasonable idea, IIUC):

~~~~~~~~~

Make GNOME full-screen applications behave "better", but don't disrupt the third-party applications.

Instead of forcibly disappearing all fullscreen applications, send a special signal. If the application is well integrated into GNOME, it will do the action you wish (e.g. disappear, or switch from full-screen to maximized state). If the application is not integrated into GNOME, it will not do anything, therefore it will continue working as it used to in all the history.

This has the following advantages:
1. It does not confuse users, if the application is "not integrated" a.k.a "broken". For example Firefox or Blender will no longer disappear when you display its preferences. This solution is better for the end user than just stating "you app is broken" (as I've heard today too many times), that's really cheap.

2. For GNOME apps, it behaves the way you want, and can provide the users with the experience that you intend to.

3. Applications, which are not capable of the operations you require (switching from fullscreen, for example), will continue to operate as usual and users won't be confused. This applies to many games.

~~~~~~~~

(In reply to comment #4)
> (the fullscreen window is at the end of the app list).

Maybe we should just stop do that? i.e don't put it at the end of the app list?

There's a number of rough spots we can sandpaper away before I iron out a more detailed proposal for fullscreen:

- Help app authors to set the dialog/transient hints as such, rather than treating them as root windows (the major friction point for the hiding behavior). I can't see how this differs from helping them comply with XDG dirs. Firefox, Blender really don't do the right thing here with their preference dialogs.
- Make sure there is a transition for hiding so it doesn't appear as the app crashed.
- Don't change the order of alt tab for hidden windows.

(In reply to comment #5)
> (In reply to comment #4)
> > (the fullscreen window is at the end of the app list).
> 
> Maybe we should just stop do that? i.e don't put it at the end of the app list?

https://git.gnome.org/browse/mutter/commit/?id=7e61ef09369a6564ad51d9d654db0e3d104fe0fc

(In reply to comment #7)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (the fullscreen window is at the end of the app list).
> > 
> > Maybe we should just stop do that? i.e don't put it at the end of the app list?
> 
> https://git.gnome.org/browse/mutter/commit/?id=7e61ef09369a6564ad51d9d654db0e3d104fe0fc

OK, maybe we should get it into 3.8 as well.

(In reply to comment #8)

> > https://git.gnome.org/browse/mutter/commit/?id=7e61ef09369a6564ad51d9d654db0e3d104fe0fc
> 
> OK, maybe we should get it into 3.8 as well.

sounds like a good idea

(In reply to comment #9)
> (In reply to comment #8)
> 
> > > https://git.gnome.org/browse/mutter/commit/?id=7e61ef09369a6564ad51d9d654db0e3d104fe0fc
> > 
> > OK, maybe we should get it into 3.8 as well.
> 
> sounds like a good idea

Seems like it already is: https://git.gnome.org/browse/mutter/commit/?h=gnome-3-8&id=7e61ef09369a6564ad51d9d654db0e3d104fe0fc

It certainly doesn't work in Fedora 19. Tested with mutter-3.8.4-1.fc19.x86_64.

Does that mean that the patch doesn't work? The patch seems to be included since Februrary, so it should definitely be included in mutter-3.8.4.

(In reply to comment #11)
> It certainly doesn't work in Fedora 19. Tested with mutter-3.8.4-1.fc19.x86_64.
> 
> Does that mean that the patch doesn't work? The patch seems to be included
> since Februrary, so it should definitely be included in mutter-3.8.4.

To clarify, I'm speaking about "Don't change the order of alt tab for hidden windows." part.

But the scope of this bug report is larger. Are there going to be more changes, or just this one?

Yesterday, I wanted to drag and drop a file (subtitles) onto my full-screen movie player window and find out that I can't do that in GNOME anymore. I have to unfullscreen first, drop file, fullscreen again.

(In reply to comment #12)
> (In reply to comment #11)
> > It certainly doesn't work in Fedora 19. Tested with mutter-3.8.4-1.fc19.x86_64.
> > 
> > Does that mean that the patch doesn't work? The patch seems to be included
> > since Februrary, so it should definitely be included in mutter-3.8.4.
> 
> To clarify, I'm speaking about "Don't change the order of alt tab for hidden
> windows." part.

Apparently yes. Jasper?

> But the scope of this bug report is larger. Are there going to be more changes,
> or just this one?

Which kind of other change do you suggest? Fixing the alt-tab order should fix the I cannot find the window anymore.

> Yesterday, I wanted to drag and drop a file (subtitles) onto my full-screen
> movie player window and find out that I can't do that in GNOME anymore. I have
> to unfullscreen first, drop file, fullscreen again.

This is incorrect. You can just drag it to the hot corner (which opens the overview) hold the mouse above the window (which will switch to it) and then drop.

This has the advantage that your source window (where you drag from) can be maximized. You don't have to try to get both windows visible on the desktop.

(In reply to comment #13)
> Which kind of other change do you suggest? Fixing the alt-tab order should fix
> the I cannot find the window anymore.

I would love to have this change reverted completely, but I tried to present a (hopefully) reasonable proposal at the bottom of comment 4.

This would have the benefit of playing nice with derivative desktop environments based on GNOME 3. If you hardcode GNOME 3 workflows into libraries, the alternative DEs (like Cinnamon, which already did) have to fork you, if they want to provide a different experience. They can't just use lots of gnome-shell modifications, but they have to supply their own mutter, etc.

Also, signal based solution would allow gnome-shell extensions to modify the behavior. Originally I wanted to create one, until I learned that it's hardcoded in a C library.


> This is incorrect. You can just drag it to the hot corner (which opens the
> overview) hold the mouse above the window (which will switch to it) and then
> drop.
> 
> This has the advantage that your source window (where you drag from) can be
> maximized. You don't have to try to get both windows visible on the desktop.

Oh, I didn't realize. Thanks a lot.

Sadly, there are probably thousands of users who will never know this. Dragging from one visible app to a second visible app is the most obvious and common way.

(In reply to comment #13)
> Apparently yes. Jasper?

Somebody would have to investigate why it's not doing that. I'm not in a position to do this right now.

We used to use a signal-based approach in gnome-shell completely, but ran into race conditions so we had to put it in the core X path, which means going in mutter.

Also, I will say that even if we don't revert this (I certainly think it should be revisited considering how many people, including me, think their apps just crashed), we should at least not minimize applications that are on non-primary monitors, since don't have a panel to look ugly under.

It would be helpful if William better described what it means to "look ugly". If the top bar covers a part of the fullscreen window, because I have a different window focused (and I need to be able to reach its global menu), I don't see it as "ugly". I consider it obvious and straightforward. Maybe if we defined the problem better, we could find a less invasive solution?

For example, what if there was a sliding animation? If the focus goes from fullscreen app to a windowed app, the top bar would slide down. If the focus goes back to the fullscreen app, the top bar would slide up. Would it help to better explain what is happening? Would it look less ugly, perhaps?

Or could the top bar get 10% transparency in this case (when covering a full-screen app)? It would be obvious that there are some obscured parts, but the bar would be still readable and usable.

These are all wild guesses, based on some my assumptions on what is meant by "looking ugly".

(In reply to comment #14)
> (In reply to comment #13)
> > Which kind of other change do you suggest? Fixing the alt-tab order should fix
> > the I cannot find the window anymore.
> 
> I would love to have this change reverted completely

Then I am the wrong one to talk to. This needs an ack from the designers (Jon suggested the change here), added ui-review keyword to get design attention.

(In reply to comment #15)
> (In reply to comment #13)
> > Apparently yes. Jasper?
> 
> Somebody would have to investigate why it's not doing that. I'm not in a
> position to do this right now.

OK, did it work for you at some point or did you never test it? i.e did we regress afterwards or has it never worked?

(In reply to comment #17)
> OK, did it work for you at some point or did you never test it? i.e did we
> regress afterwards or has it never worked?

It has never worked. I booted a Fedora 19 LiveCD, which contains:
gnome-shell-3.8.3-2.fc19.x86_64
mutter-3.8.3-1.fc19.x86_64
and it doesn't work either. I simply started a few applications, told Totem to run fullscreen and then tried to switch back and forth. Totem is moved to the end of the app list.

IMHO, this completely breaks full-screen mode for any uses other than watching a video. Most applications disappear in full-screen mode each time a dialog is shown, and showing a dialog is quite normal for most applications: GIMP, RawTherapee, Firefox, Image Viewer, ... all of them become unusable in full-screen mode.

I is a bit hard for me to understand that this serious change in GNOME's behaviour took two days since it was proposed until it was pushed; yet almost six months after this problem was reported, this bug is still marked as UNCONFIRMED.

(In reply to comment #19)
>  this bug is still marked as
> UNCONFIRMED.

UNCONFIRMED does not mean anything we don't make use of it. All it means is "the bug is open".

> UNCONFIRMED does not mean anything we don't make use of it. All it means is
"the bug is open".

I'm sorry if I misunderstood the meaning of the UNCONFIRMED status. In any case, six months to revert a simple patch that produced such a major regression seems a lot of time to me.

(In reply to comment #21)
> In any case, six months to revert a simple patch that produced such a major regression
> seems a lot of time to me.

That's because there is no regression here, but an intentional change you happen to disagree with. In case of unwanted changes, a patch can be reverted and everyone is happy. Simply reverting an intentional change is different, as it would bring back the unwanted behavior the change was meant to address (so for other people, the revert would be the regression).

(In reply to comment #22)
> That's because there is no regression here, but an intentional change you
> happen to disagree with. In case of unwanted changes, a patch can be reverted
> and everyone is happy. Simply reverting an intentional change is different, as
> it would bring back the unwanted behavior the change was meant to address (so
> for other people, the revert would be the regression).

Well, perhaps I have not presented the case properly, or perhaps there is something in my configuration that makes it worse; because I cannot understand how can this be "intentional":

1 - Open GIMP.
2 - Press F11 to make it full-screen.
3 - Go to "File" > "New...".
4 - Both the main window and the dialog disappear.
5 - Bring back the application (either using [ALT]+[TAB] or hitting the top left corner).
6 - Press inside the dialog with the mouse.
7 - Both the main window and the dialog disappear again.

In other words: it is completely impossible to create a new file in GIMP while it is in full-screen mode. Could someone please confirm whether this is happening just to me, please? Should I file a bug against GIMP, then?

I think it is also worth mentioning that while a window is hidden, it does not even appear on the desktop chooser; personally, that empty desktop seems very confusing.

GIMP is not really a good candidate for fullscreening. Fullscreen is mainly designed for viewing content (images, movies, web pages), in a no-chrome, no-distraction setting.

(In reply to comment #24)
> GIMP is not really a good candidate for fullscreening. Fullscreen is mainly
> designed for viewing content (images, movies, web pages), in a no-chrome,
> no-distraction setting.

Many thanks for the heads-up!

I will now rush to tell the GIMP people they have been doing it wrong the whole time, and they should disable full-screen completely, because it does not work in GNOME; I am sure all GIMP users will be very grateful to have that feature removed.

Well, enough (bad) humour for today; let's try some content viewing with Shotwell:

1 - Open an image using Shotwell (by double-cliking on a picture file from Nautilus, for example).
2 - Press F11 to enter full-screen mode.
4 - Rigth-click on the image and select "Send to...".
5 - A "Send to" dialog pops-up, and the main window disappears.
6 - PROBLEM #1: User can no longer see the image she is trying to send; all it takes is a minor distraction to have a confused user, in front of a "Send to" dialog, with no visual indication of what she was trying to send.
7 - After sending the image (or cancelling the "Send to" dialog), the main window does not come back.
8 - PROBLEM #2: User has no visual indication that Shotwell is still running; in a desktop environment without minimized windows, this is specially confusing.
9 - Trying to find her lost Shotwell application, user jumps to another workspace (using a keyboard shortcut, for example); still confused, she hits the top-left corner to open the workspace changer.
10 - PROBLEM #3: The hidden full-screen application is not shown on the workspace changer, all she sees is an extra empty workspace; she has to move to that workspace to actually see that Shotwell is still alive.

(In reply to comment #23)
> 1 - Open GIMP.
> 2 - Press F11 to make it full-screen.
> 3 - Go to "File" > "New...".
> 4 - Both the main window and the dialog disappear.
> 5 - Bring back the application (either using [ALT]+[TAB] or hitting the top
> left corner).
> 6 - Press inside the dialog with the mouse.
> 7 - Both the main window and the dialog disappear again.

When I first tried to reproduce this, gnome-shell crashed at step 6. ABRT routes that to this: https://bugzilla.redhat.com/show_bug.cgi?id=995785

When I tried it again, it didn't crash, and I recorded a video:
https://www.youtube.com/watch?v=CBopE5tKJmo


A similar problem can be seen with EOG:
1. open a picture with EOG
2. hit F11 to view it fullscreen (an acceptable use case for pictures and photos, I hope)
3. right click with mouse -> Properties
4. Properties dialog is opened, the underlying picture disappears
5. after you close the dialog, you are not returned to the picture. It's still opened in the background, but you don't know this.
Again, see video:
https://www.youtube.com/watch?v=aiBAgW0xP94


I also experienced a problem with game switching several times. When I had a certain app opened (I think Gajim, maybe it was caused by something else), I was not able to switch back to a game (Bastion running in Steam), because its window disappeared immediately after activating and I was back in Gajim and Bastion was again a hidden window. I can't be sure, but I think without forced window hiding I wouldn't have had this problem.


(In reply to comment #25)
> Many thanks for the heads-up!
> 
> I will now rush to tell the GIMP people they have been doing it wrong the whole
> time, and they should disable full-screen completely, because it does not work
> in GNOME; I am sure all GIMP users will be very grateful to have that feature
> removed.

Well said. It seems GNOME Shell developers have now a very clear idea how fullscreen mode should work and which applications should and should not use it. I don't object to that. But please consider this:
1. You can't expect third-party developers to adjust their applications to behave according to your views when even your own applications don't work correctly.
2. It's very frustrating for users to see this applications broken. Why weren't at least GNOME apps modified before this change was committed? It seems to have been performed in the wrong order - commit the change first, fix the apps later.
3. A lot of developers might not share your views of restricted fullscreen mode. But the user is the one who suffers here. And when half of his applications are broken, the solution is not to replace them all, but to replace the environment. Can't a solution be found that would not break non-adjusted applications? (See one of my comments above for proposed solutions). It would also mean you want to play nice with others, that's highly valued nowadays.

For example, check how Google's Chrome and LibreOffice's Writer tackle the issue: dialogs do not hide the main window.

Could this behaviour (i.e. minimize full screen windows when loosing focus) be at least added as an option for the end user to choose? 

I use emacs in full screen mode. Having it disappear when a e.g. terminal window pops over it adds a few extra key presses on an "write code -> compile -> test" session which could be avoided.

And even if some applications can be changed to work properly, it's just a small part of the solution. Clearly the above scenario can't be fixed by say an emacs enhancement.

Most of what I'm going to say has been said by Jakub already but I'll try to summarize.

Fullscreen is modal. Immersive, focused, a single task for a single screen.

Useful for projected presentations, videos, games.

When the user switches away from that task (on that output) the mode is changed.

Basically there are two things we want to avoid. 1. Showing fullscreen windows under the top bar 2. Showing non-fullscreen, non-maximized, non-modal windows on top of a fullscreen window.

I agree that the way we change the mode now is not ideal.

I agree with Jakub that it does seem better to unfullscreen the application (so that it appears like it did before it was made modal) when switching away from the app.

Some caveats: It may not be desirable to lose a fullscreen presentation/movie on an external screen while changing applications on another monitor. It would be helpful to have a distinction between presentation outputs and outputs that are more like peers to the primary output. Until we get that distinction we may want to consider using a distinction based on: primary/non-primary, presence of struts, presence of other non-maximized or fullscreen windows on output.

Other problems: Many applications are using fullscreen where they should really be using maximized. Many applications are not correctly using the _NET_WM_WINDOW_TYPE and WM_TRANSIENT_FOR.


(In reply to comment #4)
> I have seen the same happening yesterday at GUADEC during Jakub Steiner's
> presentation about Blender. Any time he opened preferences (a new window), the
> whole blender screen disappeared and he had to manually switch to it again
> after closing the preferences window. If you don't have many applications
> running, it's not that hard (a single Alt+Tab), but if you do, it's very
> uncomfortable (the fullscreen window is at the end of the app list).

Blender should correctly set the window type and transient for hints. We can perhaps do more here on the shell side too. It should be clear that these windows are not from another app.

> 1. I'm watching full-screen video with subtitles and want to translate an
> unknown word. The moment I open a dictionary, the video disappears and I can't
> re-write the word into dictionary. I'm forced to switch back to the video,
> remember the unknown word (it can be a very long one with a difficult spelling)
> and then put it into the dictionary. Or I have to demaximize the video (and
> maximize it back again, once I translated the word). So many useless actions
> that weren't necessary before.

If on same display, the video should unfullscreen. You will still be able to see it if you arrange the windows that way.

> 2. I'm playing a fullscreen game and I died. I have to wait several minutes for
> a new round (e.g. Counter-Strike style game). In GNOME < 3.8, I could have
> switched to a chat or some other app and still see the game in the background.
> So I would have chatted for a few minutes and the moment I see I'm alive again,
> I'd switch to the game window. With GNOME 3.8, I can do that, and I have to
> periodically (the more often the better, because I don't want to miss the round
> beginning) switch between the game and the chat/browser/something app.

Same as above. But perhaps could also use an audio cue/notification depending on game instead of or in addition to visual polling.

> 3. I have an IDE full-screen, because I have a 12" screen and I need to see as
> many source code lines as possible. I need to switch to a
> terminal/documentation window very often, to compare some source code
> samples/diffs/examples or see function documentation. Often I need to see it
> side by side. In GNOME < 3.8, I could have a full-screen IDE and an overlapping
> window to switch into in I need it (source code in IDE is usually aligned to
> the left side, so the overlapping window would be on the right side). In GNOME
> 3.8, I need to un-fullscreen the IDE any time I need to compare something side
> by side.

This should use maximize instead. fullscreen is not for multitasking. Half maximize seems well suited also. We should work with the IDE app to fix this.

> 4. I have a full-screen Firefox, because my screen is small, or I don't want to
> be disturbed by anything else. But sometimes I need to run a
> calculator/dictionary/chat/something to compute/translate/ask about something.
> If I run this app, my Firefox window disappears and I don't see the text I
> wanted to operate on. I need to de-fullscreen Firefox first, every time this
> happens.

Same as 3.

(In reply to comment #23)
> 1 - Open GIMP.
> 2 - Press F11 to make it full-screen.
> 3 - Go to "File" > "New...".
> 4 - Both the main window and the dialog disappear.
> 5 - Bring back the application (either using [ALT]+[TAB] or hitting the top
> left corner).
> 6 - Press inside the dialog with the mouse.
> 7 - Both the main window and the dialog disappear again.

Gimp should be using maximized. Should correct mark the dialogs as transient. We should do more to identify that they are not separate apps.


(In reply to comment #25)
> I will now rush to tell the GIMP people they have been doing it wrong the whole
> time, and they should disable full-screen completely, because it does not work
> in GNOME; I am sure all GIMP users will be very grateful to have that feature
> removed.

Not removed - changed. Someone should file a bug to fix those real problems. There should be a maximized mode that is better than the fullscreen one and the dialogs should be fixed.

> Well, enough (bad) humour for today; let's try some content viewing with
> Shotwell:
> 
> 1 - Open an image using Shotwell (by double-cliking on a picture file from
> Nautilus, for example).
> 2 - Press F11 to enter full-screen mode.
> 4 - Rigth-click on the image and select "Send to...".
> 5 - A "Send to" dialog pops-up, and the main window disappears.
> 6 - PROBLEM #1: User can no longer see the image she is trying to send; all it
> takes is a minor distraction to have a confused user, in front of a "Send to"
> dialog, with no visual indication of what she was trying to send.
> 7 - After sending the image (or cancelling the "Send to" dialog), the main
> window does not come back.
> 8 - PROBLEM #2: User has no visual indication that Shotwell is still running;
> in a desktop environment without minimized windows, this is specially
> confusing.
> 9 - Trying to find her lost Shotwell application, user jumps to another
> workspace (using a keyboard shortcut, for example); still confused, she hits
> the top-left corner to open the workspace changer.
> 10 - PROBLEM #3: The hidden full-screen application is not shown on the
> workspace changer, all she sees is an extra empty workspace; she has to move to
> that workspace to actually see that Shotwell is still alive.

"Sent to" should be dialog type, transient for, and modal to the parent window. Very simple fix. File a bug please.

(In reply to comment #29)
> This should use maximize instead. fullscreen is not for multitasking.

I really wish I could sit you down in front of a 12-inch display, fire up a complex editor with lots of panels, and force you to work in it for the whole day. You would have the lovely choice of either sacrificing a substantial portion of your screen to a useless top bar and title bar and thus reducing your already way-too-small work space, or having your IDE disappear every time you switch to any other window. Then you would quickly dismiss that silly notion that fullscreen is not for multitasking that you try to force on everyone.

Or maybe you would not. I guess you would not. But one can hope.

I'm trying to work with Spyder IDE on a 12'' screen at the moment and my current frustration level is 4 stars out of 5. Half of that comes from the small screen, and half of that from GNOME forcing me into a workflow that makes the usable screen even smaller for no real reason.

This behavior breaks certain wine applications (maybe all?) which can't be used in full screen if _any_ other application is running. I assume it's caused by focus working differently. See bug 722743 comment 39 and:

https://www.youtube.com/watch?v=5ezaD4dR2j4

I've seen this problem several times myself, even with non-wine applications (I've seen it with steam games), but I couldn't reproduce it reliably, so I have no video of my own.

Expereience magical moments with firefox in gnome-shell:

1. press f11 (go fullscreen)
2. using the menu click on setup sync... or email link... or Preferences

and Lo and Behold the Magic... [Dramatic suspense music playing]  Firefox Window
disappears!

Gnome-Shell is a magical place :)

-
Fedora 20 x86_64

This is mostly directed at Jon (I know his comments are old but I don't spend much time on bugzilla anymore):

Unfortunately not all games can be easily switched to a non-maximized state and back. This can constitute a video mode switch and can cause unwanted behavior and bog down the system.


As an aside I think another part of the issue is that the fullscreen application does not return to a normal state when the other (interfering) application is closed.





Not sure how serious I am here, just a thought, but even though I hate transparencies for windows it might be a good visual indicator for people if the window became transparent instead of disappearing.

*** Bug 712622 has been marked as a duplicate of this bug. ***

I've closed other bug report, as it's really duplicate, but i want to highlight how it's annoying for me for particularly these use cases as for gamer:

1) Game on background + chats (this is even more important for games like eve online than counter-strike, as described by author)
2) Watch various video streams & discuss them via IM from time to time

I don't really care about the rest of use-cases.

> Fullscreen is modal. Immersive, focused, a single task for a single screen.

> Useful for projected presentations, videos, games.

I just want to say how this assumption is horribly wrong. When it comes to 'multiplayer' environment, things are little bit different.

1) Travelling long distances in safe (or sometimes not so safe) environments in EVE online. You have to click jump button once a while (~1 time each minute, varies on solar system size), you need to see when you have finished warping from one gate and arrived to another to click that button. I used EVE in fullscreen mode and any other kind of windows above it, taking up to 95% of its surface (examples - browser is maxed height, ~50% width centered, IDE is maxed height and 90-95% width, aligned to left, so i can see portion of my ingame 'overview' window to detect when i arrived to gate and assess danger of situation i'm in, thus knowing if i need to switch immediately or can finish that block of code). In general, you can say that this gameplay is bad but it's the way people like it. And you can switch to 'immersive' mode via just one mouse click if you see some situation which needs it (e.g. potential PvP engagement). These switches can occur often in many games
2) Dota 2 under linux still suffers from bug - when you enter matchmaking queue and match is found, sound is not played. Thus you need to keep polling dota's window. Changing window mode is not that easy for such heavy application as this game, and too many actions need to be taken to do it from user side
3) Watching some starcraft 2 tournament on twitch.tv, while discussing some ongoing highlights with friends via any kind of IM. I want to keep it as immersive as possible when i watch it, but i also want to be able to discuss action with other people and be able to spot any potentially interesting action to switch back to stream immediately.

For second one you can blame dota developers, i agree it might be fixed by playing proper sound notification. But 1 and 3 can't be fixed without being able to keep an eye on window, because nobody can assess the situation you're in or pick interesting for you moments on stream to play sound. This change breaks gnome as gaming platform for me, and probably for other people who're trying to use it this way.

Also i do not completely agree with you when you tell that applications should be fixed. I agree that this is better approach overall, but only if you benefit from the change. In this case benefit is extremely doubtful imo, but you have no way to deal with broken (and sometimes not broken) applications. And you do not control these applications, thus there will always be broken ones. Bad argument, but it's still there.

Created attachment 273011 [details] [review]
Mutter setting to change the behavior of fullscreen applications

By default fullscreen applications are minimized on focus loss (since the top bar is drawn on top of it). There are some use-cases where this behaviour is undesirable.

This patch proposes a setting in org.gnome.mutter scheme to specify the behavior of fullscreen apps (whether to minimize it or leave in background).

Unfortunately, fullscreen windows management and tracking are performed by mutter, the patch above (Comment 37) is for mutter.

For the reference, fullscreen tracking was introduced in 5ceffe86 commit of mutter (https://git.gnome.org/browse/mutter/commit/?id=5ceffe86ee82d08e7157bb7ff670e46559fdaf92)

Is there a way to work around this with a Gnome Shell extension maybe?

> Fullscreen is modal. Immersive, focused, a single task for a single screen.

> fullscreen is not for multitasking

Perhaps this is the core of the misunderstanding. I think you are making the equivalence:

"Single task" == "single application"

...or perhaps...

"Multiple applications" =/= "not multitasking"

But I disagree. It is perfectly valid to be working on a single task using multiple applications while remaining focused. For example:

Task = coding. Applications: text editor, terminal. The text editor is fullscreen because 95% of my time is spent there, and I want the focus that comes with fullscreen editing. But when I quickly switch to a terminal to compile, I want to be able to flick my eyes back and forth between what's in the terminal and what's in the editor. Sometimes I may even want the terminal always on top, up in the top-right corner, so I can type *and* get feedback on compilation progress.

My point is, the information presented in both is relevant to the single task I'm performing.  Having even a few seconds of dissonance, or my short-term memory stack pushed down one slot, is a small but noticeable disadvantage to my concentration and workflow. Having the text editor switch from fullscreen to maximised would be bad enough (flickering, high-contrast motion in my peripheral vision is incredibly distracting, plus now I have to remember to hit F11 when I refocus it). Having it disappear altogether is worse (now I have to find it with alt+shift+tab, and hey my terminal's disappeared, what was that symbol I misspelt again...)

Other examples are:

 * running stuff on my Windows machine via Remmina (which works best fullscreen) but wanting to switch back to a Linux application to do something quick
 * taking occasional notes while watching a full-screen video
 * giving a presentation, and launching a terminal to run some code to demonstrate something nifty that an audience member asks about

The alternative is: for every task that involves application X and application Y, write a new application that combines the main features of X and Y, and run that fullscreen. This doesn't really scale, and the combination is usually sub-par compared to the original (eg. pretty much every text editor with a built-in terminal).

any news/updates/designer thoughts on this?

This may be a different bug, but...

Once I alt-tab away from Java or Wine fullscreen windows, I can't alt-tab back to them. They just reappear briefly, then vanish again.

I actually have to go into Activities, drag the fullscreen window to a new workspace, then click on it in order to see it again.

Anyone else seeing this?

(In reply to comment #42)
> This may be a different bug, but...
> 
> Once I alt-tab away from Java or Wine fullscreen windows, I can't alt-tab back
> to them. They just reappear briefly, then vanish again.
> 
> I actually have to go into Activities, drag the fullscreen window to a new
> workspace, then click on it in order to see it again.
> 
> Anyone else seeing this?

Yes, I can confirm this e.g. with NetBeans (and using complete fullscreen, i.e. when the top gnome-shell bar is not visible). I reckon it's yet another side effect of the fullscreen-hiding behavior, i.e. this bug. For wine apps/games I've seen numerous complaints, so it's known, but the fact that it affects also Java apps seems to be a new information.

I find this behavior very frustrating as well. I often want to use the terminal while playing a fullscreen video. This issue is preventing me from doing just that.

There are also other cases where this annoys me. For example, when switching to some other application while playing a game, or when I tried out cool-old-term  in fullscreen earlier today and it kept minimizing because I wanted to use another application on the same workspace.

I've been considering locally patching and building GNOME Shell myself to get rid of this behavior. Does anyone happen to know where in the source code the minimization is done? It would save me some time trying to hunt it down myself.

(In reply to comment #44)
> I've been considering locally patching and building GNOME Shell myself to get
> rid of this behavior. Does anyone happen to know where in the source code the
> minimization is done? It would save me some time trying to hunt it down myself.

I already made a patch and proposed it in Comment 37. It's mutter thing. Feel free to use it.
However no one seems to be interested in it.

Ah, I must have missed that one. Thank you, your patch works as expected.

Joakim, if you intend to keep the patched version up-to-date, what about publishing it in some kind of third-party repo (Ubuntu has PPAs, Fedora has COPRs, I don't know about other distributions) and publishing a link here? I think many people would be interested. I would be definitely interested in the Fedora version of the package.

(In reply to comment #47)
> Joakim, if you intend to keep the patched version up-to-date, what about
> publishing it in some kind of third-party repo (Ubuntu has PPAs, Fedora has
> COPRs, I don't know about other distributions) and publishing a link here? I
> think many people would be interested. I would be definitely interested in the
> Fedora version of the package.

I'll look into creating a PPA for this. It may take some time before I can get to that though. In the mean time, I put the unsigned Debian packages I built for myself on my web server.

I don't recommend installing Debian packages manually like this. But if you're in a hurry and know what you're doing, feel free to use them. Note that you probably need to install all of the packages to make sure you don't have any conflicting versions installed. If you have conflicting versions installed, then mutter is likely to stop working.

http://jocketf.se/files/.mutter/

Why is something overlapping a fullscreen app just now being considered "weird"? That is how it has always worked in every graphical desktop I've ever used for as long as I can remember. Personally I see no weirdness about it, and in fact, that's what I would expect to happen to a fullscreen app that's not in focus. For me, the current auto-hiding behavior is what's surprising and weird. Maybe I'm too used to the way it's always been, but I'm definitely not used to the annoyance of auto-hiding windows that I don't want hidden.

It sounds like you are trying to redefine what most users and developers expect fullscreen to mean. Might I suggest leaving the fullscreen behavior the way it was (i.e. allowing things to overlap a fullscreened app) and creating a new hint for apps that want to opt in to this fullscreen-or-nothing mode? This seems like the prudent way to approach change this rather than repurpose fullscreen mode while breaking tons of apps in the process (including many first party GNOME apps!)

> Fullscreen is mainly designed for viewing content

Content creation is a common use case for fullscreen (e.g. 3D modeling, photo editing, music production, IDEs, etc.) These applications tend to have a lot of stuff to display on limited screen real-estate so people often want as many pixels allocated for that application's contents as possible. Maybe that's the misunderstanding, fullscreen is not always just about "no distraction single-tasking", it can also be about using every pixel on your screen (the full screen). Maximizing still leaves many "wasted" pixels due to the top bar and the oversized (in my opinion) title/header bar.

Finally and most importantly, I really don't see how it's sensible for a subjective cosmetic issue ("it looks weird") to be considered more important than not breaking functionality in many existing applications; not to mention the significant regressions this caused in people's everyday workflows. This was changed a year and a half ago and fullscreen GIMP is still completely broken under GNOME.

This change really should be reverted, at least until these issues get resolved first.

https://git.gnome.org/browse/mutter/commit/?id=5d8ff2e34d36a72df2c14eea1bc4c265c3aab969

Fantastic!

Will this fix be included in 3.14.x series, or will we have to wait for 3.16?

(In reply to comment #51)
> Fantastic!
> 
> Will this fix be included in 3.14.x series, 

Yes.

> or will we have to wait for 3.16?

No.

(In reply to comment #50)
> https://git.gnome.org/browse/mutter/commit/?id=5d8ff2e34d36a72df2c14eea1bc4c265c3aab969

Thank you very much, Jasper.

*** Bug 704565 has been marked as a duplicate of this bug. ***