Created attachment 1202901 [details]
bug demonstration video
Description of problem:
After gtk3 update, you can no longer watch maximized or fullscreen videos in totem. If you maximize/fullscreen the window, the video gets shifted (in my case, moved to the bottom right). If I unmaximize the window, the video is still shifted and does not reflect the current window borders.
See the video.
I narrowed down the regression to gtk3. It works fine with:
but breaks with:
I'm using a wayland session.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run a video in totem
2. either maximize it or fullscreen it
3. see the video shifted
4. unmaximize the window
5. see the video not respect window borders
So, I further narrowed it down. It works with:
and is broken with:
Proposing as a blocker:
"All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test. "
Watching movies in full screen might be considered a default movie player functionality by some. Please note that the affected gtk3 update is still just in updates-testing atm.
Sounds like a regression from "gtkwindow: Update shadow size on state change", https://git.gnome.org/browse/gtk+/commit/?id=4cb1b9645e84054c059f174240e8e288c4befe05
Could be related to that change, yes, but the change still looks correct to me, I wonder how that affects clutter-gtk though.
It appears that the problem doesn't lie in clutter-gtk at all, this is purely gdk related apparently, the problem is that the impl abs_x,abs_y being out of sync after the patch Kalev mentioned in comment 3, not sure why yet though...
The problem does not occur if I run totem with GDK_BACKEND=x11.
Discussed during the 2016-09-26 blocker review meeting: 
The decision to classify this bug as an AcceptedBlocker was made as watching a full-screen video is considered to be "basic functionality" of totem and so violates the following Final criteria: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test"
The fix for this has been pushed upstream in gtk+ master.
I've backported the fix to gtk3-3.22.0-2.fc25.
Proposing as a freeze exception for the beta release. This has already been accepted as a blocker for the final release and as such should qualify for a FE for beta.
gtk3-3.22.0-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-2787de39a2
Sure, FE for Beta makes sense.
whoops, I meant that to be a *vote*, not an accepted :)
+1 FE, though it can be handled just as well via updates
+1 beta blocker and +1 FE
It's not a beta blocker; it doesn't violate any Beta criteria.
I'm +1 FE on this only because this is functionality someone could reasonably be expected to try out in a Live image. Normally I'd recommend avoiding changing gtk3 during a Freeze.
that's +4 FE, marking accepted.
Verified fixed with gtk3-3.22.0-2.fc25.
gtk3-3.22.0-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.