Unity Issue Tracker - Fullscreen mode: Maximized Window functionality is broken and any built Player changes to Non-Window mode when Maximizing

Fixed in 2018.4.0f1

Fixed in 2018.4.X, 2019.1.X, 2019.2.X

Votes

64

Found in

2018.3.8f1

2019.1.0b5

2019.2.0a6

Issue ID

1137204

Regression

Yes

Fullscreen mode: Maximized Window functionality is broken and any built Player changes to Non-Window mode when Maximizing

Windows

Mar 15, 2019

How to reproduce:
1. Create a new project and open its Player settings
2. Under the "Resolution" settings change the "Fullscreen Mode" to "Maximized Window" and checkmark the "Resizable Window" option
3. Build the project
4. Run it in fullscreen mode (The Player will be fullscreen in non-window form)
5. Run it again in windowed mode and maximize the window (The Player will still be in fullscreen non-window form)

Expected result: when maximizing the player is still in window mode
Actual result: maximizing the player results in it changing modes to regular fullscreen, making the title bar disappear

Reproduced in: 2019.2.0a8, 2019.2.0a6, 2019.1.0b7, 2019.1.0b5, 2018.3.9f1, 2018.3.8f1
Not reproducible with: 2019.2.0a5, 2019.1.0b4, 2018.3.7f1, 2017.4.23f1 (The 2017.4 versions had a separate D3D11 Fullscreen Mode setting which works as expected when setting it to Exclusive Mode)

Fixed in: 2019.2.0a15, 2019.1.2f1, 2018.4.0f1

Resolution Note (fix version 2018.4.0f1):

The behavior of the Maximize button was changed in order to fix another (more serious) issue: https://issuetracker.unity3d.com/issues/buttons-dont-record-input-when-the-window-is-maximized-and-then-set-to-2560x1080-resolution

Clearly we made a bad call. So, we've implemented a different fix to the aforementioned bug which also maintains the correct maximize window behavior.

A workaround to automatically revert the app out of fullscreen mode can be found here: https://forum.unity.com/threads/unity-2019-1-is-now-available.661885/page-3#post-4491478

Verified fixed in: 2019.2.0a15, 2019.1.2f1, 2018.4.0f1

Comments (34)

digipaul

Apr 27, 2019 21:03

This is marked as resolved in 2019.1, yet it is still happening for me with 2019.1.0f2.
WrexialMT

Apr 26, 2019 21:07

"Fixed in Unity 2019.1" will this be applicable to 2018.3 LTS? It'd be a shame we'll have to stay stuck on 2018.3.7 without this fix.
Huacanacha

Apr 24, 2019 21:06

This may block our releases. It's very poor form to introduce known core UX regressions between major engine versions (seems like it was introduced in a 2018.3 patch but is a regression between 2018.3.0 and 2019.1.0). Also... this issue is NOT MENTIONED in the 2019.1 release notes. Why not? If I had seen this issue we would have delayed upgrading to 2019.1 until it was fixed. As it stands we now have a choice between introducing a UX regression in our application or delaying feature releases.

In my opinion, if Unity wishes to be taken seriously for non-gaming applications 2019.1 should not have been released with this regression. And it definitely should not have been released without disclosing this as a known issue.
TheArcus

Apr 23, 2019 10:11

We are trying to switch to Unity 2018/2019 but we encountered this but. Currently this is blocking us too.

This can still be an opt-out feature but please make this optional.

Testet with 2019.1.0f2
axel1200

Apr 18, 2019 09:58

This issue is blocking me
mikaelwallen

Apr 18, 2019 08:48

We also ran into this now upgrading from 2017.2 to 2018.3.12. It is a showstopper for us and we really hope it will be fixed soon.
EthanFischerICS

Apr 16, 2019 15:57

Also reproduced in 2019.1.0f2
AAvenel

Apr 16, 2019 14:09

Reproduced in 2019.1.0f2
petersvp

Apr 13, 2019 00:10

THis is seriously hindering my weorkflow since most of my tools are actually Windowed Mode apps for design purposes made within unity and now I am forced to alt+tab from my tools instead of using my taskbar
QuincyC

Apr 12, 2019 20:50

Reproducible in 2018.3.12f1