`libinput debug-events` should show scrolling and other pointer events so that you can at least see the numbers have changed according to your custom configuration.

== Steps to reproduce ==
1. Download https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Car_crash_1.jpg/193px-Car_crash_1.jpg?download
2. Open the image in Shotwell Viewer: $ shotwell 193px-Car_crash_1.jpg
3. Select File > Save As…
4. Keep/set Format as ”Current”, don’t change any other parameters
5. Enter ”193px-Car_crash_1.png” (without quotes) as the filename, select OK

== What happens ==
The viewer now displays a black screen, with the text ”Photo source file missing:” followed by the (.png-ending) image path entered in the dialog. The file has not been saved.

== What I expect to happen ==
For the (now misnamed) .png-ending file to have been saved, and be opened in the Viewer.

== Other notes ==
* If an image file with the .png ending already exists, and I choose to overwrite it with the JPEG, the black error screen does not appear; instead the previously-existing PNG image file is then opened in the viewer.
* I’m (intentionally) not doing an actual Format change in the first Save As dialog here. If I do select PNG as the format, then saving the file does work as expected (using any filename extension).
* I used .png just as an example here. Using any variant of /jpe?g/i as the extension seems to work as expected (i.e. the file is saved under the new name), whereas anything else (.gif, .foo etc.) results in the same ”file missing” error as above.
* If the original file is a PNG file, saving it with .jpg (or any other extension for that matter) seems to work as expected (i.e the file is saved under the new name, with the now-incorrect extension).

(My original report at Launchpad: https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1710641#. I tweaked some details for the report above, with Shotwell 0.27.4 currently in Bionic.)

Nice. I’d also like to see Massacre Mario, who speeds through killing all the enemies, and Demolition Mario, who breaks every brick on every level.

@kubiko That’s good to hear, gives me confidence in running the snap on my main server again (instead of the VM). Thanks again guys!

@xet7 Alright, here’s hoping those fixes hit the spot! Thanks a lot.

And now, suddenly, it just works again.

root@saegusa:~# snap install wekan
wekan 0.77-29-g9e62584 from 'xet7' installed

root@battra:~# snap install wekan
2018/03/02 16:39:13.986937 cmd.go:212: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
wekan 0.77-29-g9e62584 from 'xet7' installed

Darn it, I was hoping to catch the exact cause. Unless you guys already found and fixed it?

What’s changed on my end since I posted the last comment a week ago is the core snap updating from 4017 to 4110.