Created attachment 1210025 [details]
gnome-screenshot can't take correct screenshots on Wayland (at least on multimonitor setups). The outcome only covers a small part of the screen and the rest is missing (see the attachment). It used to work in previous releases, so it's a regression.
Proposing as a Final 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. "
The screenshot tool does not work for multimonitor setups (it worked for me with a single monitor).
But the problem is larger. Screencasts don't work either (ctrl+alt+shift+R), again one of the screens is not present in the video. And because on Wayland only the compositor can capture the screen, and the compositor is broken, it means that *all* tools for capturing screenshots/screencasts are broken (e.g. my favorite EasyScreenCast extension).
The final effect is that there's no way create a screenshot/screencast at all, except for using shaky phone photos. That makes it impossible to provide debugging information or reproducers for many kinds of bugs, which seriously affects the whole QA process.
My monitor setup:
Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 8192 x 8192
XWAYLAND2 connected 1920x1080+0+0 310mm x 170mm
XWAYLAND3 connected 1920x1080+1920+0 510mm x 290mm
On all screenshots/screencasts, only the left monitor is visible (secondary), but not the right one (primary).
This is most likely a mutter issue.
well, I think 'impossible' is overselling it. For most cases it'll be fine: just drag whatever you want to take a screenshot/cast of onto the screen that *does* appear in the screenshot/cast. The only case where it's really going to make things 'impossible' is if you're taking a screenshot/cast of something that specifically involves the dual screens.
(In reply to Adam Williamson from comment #3)
> well, I think 'impossible' is overselling it. For most cases it'll be fine:
> just drag whatever you want to take a screenshot/cast of onto the screen
> that *does* appear in the screenshot/cast. The only case where it's really
> going to make things 'impossible' is if you're taking a screenshot/cast of
> something that specifically involves the dual screens.
Well, in my case it does *not* appear in the screenshot. See the attached picture. I only captures a small part of one screen.
hum, I see...are we sure they're all the same bug, then?
Discussed during the 2016-10-17 blocker review meeting: 
The decision to classify this bug as a "RejectedBlocker" was made as we don't consider this severe enough to warrant blocking on, however it can be considered for Freeze Exception status.
There appears to be a fix for this upstream now:
but I don't know when 3.22.2 is due. Could we perhaps backport it to F25 immediately as a downstream patch?
I reproduced the issue in full extent as Jiri reported (both screens are garbled). This is affected by screens resolution and their placement. For 2 same resolution screens placed directly next to each other, the left is visible in full and the right is not visible at all. However, for a very common case of 1368x768 laptop screen and 1920x1080 external monitor (aligned to the bottom edge), the screenshots are almost empty, there's just a very narrow strip of content from the left monitor, and nothing else. See attachment.
Since we argued that "you can move the thing you want to shoot to the left monitor" when rejecting this, and that does not hold anymore, I'm moving this back to the discussion.
Created attachment 1211667 [details]
another broken screenshot
This was reproduced with this setup:
Screen 0: minimum 320 x 200, current 3288 x 1080, maximum 8192 x 8192
XWAYLAND0 connected 1368x768+0+312 310mm x 170mm
XWAYLAND1 connected 1920x1080+1368+0 510mm x 290mm
Can you try with this mutter build http://koji.fedoraproject.org/koji/buildinfo?buildID=810776 ?
(In reply to Rui Matos from comment #10)
> Can you try with this mutter build
> http://koji.fedoraproject.org/koji/buildinfo?buildID=810776 ?
Works great, thanks.
This is now in Bodhi here:
Update has now been pushed stable, and fix was confirmed by kparal, so closing the bug.