Description of problem:
QT applications running in Gnome shell using Wayland cannot be full screened.
Version-Release number of selected component (if applicable):
$ rpm -qa \*gnome-shell\* \*qgnome\* \*falkon\* \*qutebrowser\*
Steps to Reproduce:
1. Run a QT application in Gnome shell using Wayland
2. Press F11 to full screen (or click the full screen button in a youtube video)
The application can no longer be seen. The application behind it is shown.
Should full screen normally.
Just tried VLC, works there. Does not work in Qutebrowser/Falkon, though.
VLC is using XWayland, so it looks like this issue is affecting all QT apps that don't force XWayland under Wayland session.
If you run falkon with forced XWayland, it works in fullscreen just fine. You can do that by setting QT_QPA_PLATFORM=xcb .
So, "QT_QPA_PLATFORM=xcb falkon" works just fine.
I don't think it's blocker worthy, but proposing it as blocker won't hurt anything.
Looks like https://bugreports.qt.io/browse/QTBUG-63748. There is even a PR which was not merged https://codereview.qt-project.org/c/qt/qtwayland/+/199123. I asked in the PR so let's see what is the status and whether we can backport it to Fedora if it gets merged.
Ok, based on the comment it should be already implemented. I will try to look why it doesn't work once I find some time.
Moving to qt5-qtwayland then.
Opened upstream bug: https://bugreports.qt.io/browse/QTBUG-79106
Proposing for a blocker discussion.
I don't think this should be considered as a blocker, this issue affects only applications using qtwebengine and those are only Falkon and Qutebrowser. Those are not even installed by default on Fedora Workstation.
-1 blocker per comment 8. If this affects just 2 applications, this is a very niche problem.
note that calibre (as of 4.0.0) is also using qtwebengine.
I'm -1 blocker, +1 FE
I also don't see this on rawhide...
I agree with Jan here and -1 Blocker.
-1 blocker since it doesn't affect default packages. +1 FE
-1 Blocker, +1 FE
That's -5 blocker, so rejecting as a blocker. +3 FE, but I think I'd want to make the case for -1 FE; this shouldn't really affect anything out of the box, and I'm not sure I'd want to poke the release Qt package during a freeze just to fix this. I think I'd actually be happier with this as a zero-day update than an FE. So I'm gonna say we're at -1/+3 FE and leave that status open for now.
Discussed during the 2019-10-14 blocker review meeting: 
The decision to classify this bug as a "RejectedFreezeException" was made as we don't see any convincing benefit to granting an FE here, the only case it would really help is someone installing a qtwebengine-based app in a Workstation live session, which seems like a pretty unusual scenario. We think it's fine for this to go as a regular update.