When I press the Print Screen button, it will not appear in "Save Screenshot" window.

Bug #927952 reported by Adrián on 2012-02-06
This bug affects 80 people
Affects Status Importance Assigned to Milestone
Ayatana Design
John Lea
Gnome Screenshot
gnome-screenshot (Debian)
gnome-screenshot (Ubuntu)
Sebastien Bacher
Sebastien Bacher

Bug Description

When taking a screenshot with Print Screen or Alt+Print Screen a dialog box asking you what and where to save the file no longer appears. So while you hear a camera sound you have no other confirmation that a screenshot was really taken. Additionally, there is no way of knowing where the screenshot went. I'd imagine this will be particularly problematic for new users of Ubuntu.

ProblemType: BugDistroRelease: Ubuntu 12.04
Package: gnome-screenshot 3.3.2-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-14.23-generic 3.2.3
Uname: Linux 3.2.0-14-generic x86_64
ApportVersion: 1.91-0ubuntu1
Architecture: amd64
Date: Mon Feb 6 23:54:17 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20111129.1)SourcePackage: gnome-screenshot
UpgradeStatus: Upgraded to precise on 2012-01-27 (10 days ago)

Adrián (jaksi) wrote :
Tobias Wolf (towolf) wrote :

GNOME Screenshot 3.3.2 - 6th February 2012

- Make non-interactive mode headless
- Update to the new shell Screenshot API
- Port to GApplication

Here, »headless« means that no dialog is shown anymore. The screenshots are placed in your »Pictures« folder silently.
You can choose another folder via GSettings, but you cannot show the dialog. The only way to get that is to start gnome-screenshot with -i.

Tobias Wolf (towolf) wrote :

BTW, could you take a screenshot of your semi-translucent terminal? How do the fonts look?

Changed in gnome-screenshot (Ubuntu):
status: New → Invalid
Tobias Wolf (towolf) wrote :

To change the destination directory

gsettings set org.gnome.gnome-screenshot auto-save-directory 'file:///home/xyzxyz/Desktop'

Changed in gnome-screenshot (Ubuntu):
status: Invalid → Opinion
Doug McMahon (mc3man) wrote :

I would not expect this to change, gnome changed it, unlikely ubuntu will revert
(similar to when gnome changed the file naming of screens from <whatever>.ext where <whatever> was based on window title & made 'sense', to the current date/time format
Didn't like that but nothing to be done other than redoing the source which wasn't worth it

Tobias Wolf (towolf) wrote :

I think this should be escalated to upstream to challenge the notion that silently putting uninformatively named files into an unseen folder is a good idea. It just creates confusion and unnecessary work.

That this behaviour trips people up is evidenced by 6 dupes within one day

Tobias Wolf (towolf) wrote :

How do I link upstream bugs nowadays?


Alan Bell (alanbell) wrote :

this appears to be the offending commit
can we patch it back in? The dialog with a preview is a lovely feature, way better than silently putting it on the clipboard or silently saving it.

Sam_ (and-sam) wrote :

How is a new user supposed to know
- where the screenshot lands?
- when using common shortcuts it may need an edit of a .desktop file with -i option?
- to install dconf-tools in order to access UI settings?

There is no auto-save-directory selected, alt and alt+print deliberately saves the screenshot in 'pictures' folder, where also unity-greeter takes access. It also ignores the last used directory.

description: updated
Changed in gnome-screenshot (Ubuntu):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
importance: Undecided → Medium
status: Opinion → Triaged
tags: added: regression-release
tags: added: rls-mgr-p-tracking
Sebastien Bacher (seb128) wrote :

Thanks, that need consideration but that's neither a regression not an important bug, the new behaviour is what new devices out there like phones or tablets do

Changed in gnome-screenshot (Ubuntu):
assignee: Canonical Desktop Team (canonical-desktop-team) → nobody
Sebastien Bacher (seb128) wrote :

The new behaviour is a bit disturbing first but is basically:

- is what phones and tablets do nowadays, a sound and visual effect and store to the image directory, so something quite some users should be used to
- the non interactive behaviour is limited to keybinding, if you run gnome-screenshot from i.e unity you will get the ui with the choices and the confirmation dialog
- a change which can get some "getting used to" but that makes sense once you know how the feature work

I don't think we should revert as a knee jerk reaction but rather see for a while how that works

Cc-ing ayatana-design to get their input, that would be interesting to test in user testing sessions

Some possible options:

- revert to the old behaviour
- keep the new one as it is
- keep the new one but add notifications telling you "screenshot stored at ..."

Changed in gnome-screenshot (Ubuntu):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
importance: Medium → Low
Sebastien Bacher (seb128) wrote :

Note that those screenshots should show in the dash home screen "recent files" (if they don't that's a bug we will fix) so should be easy to access this way as well

Laura Czajkowski (czajkowski) wrote :

@seb the main issue I find is that I didn't know where the screen shots had gone, if there was some logic to where they went I would have been fine but they went to a folder I do not use. Where as before I could select their destination. On a phone or a tablet I know exactly where to go as its explicit.

Tobias Wolf (towolf) wrote :

It’s more about the immediate option to rename, the option to copy to clipboard, the option to preview, and the option to drag the thumbnail to another app directly.

I don’t have a smart phone.

Tobias Wolf (towolf) wrote :

Also, I keep camera photos in my Pictures folder, screenshots don’t belong there.

Sam_ (and-sam) wrote :


> those screenshots should show in the dash home screen "recent files" (if they don't that's a bug we will fix)

Just tested on laptop (install since alpha-1), no recent screenshot displayed.
Just tested on desktop-pc (install alpha-2 four days ago), recent screenshot displayed.

Sam_ (and-sam) wrote :

#16 Erratum:
< Just tested on laptop (install since alpha-1), no recent screenshot displayed. >

My bad, apologies, alm was in the way. Recent screenshots are also displayed on laptop.

Sebastien Bacher (seb128) wrote :

if you want the options to rename etc run gnome-screenshot and use the interactive ui?

Tobias Wolf (towolf) wrote :

Sebastien, when there is a need to take a series of screenshots and use them further right away, going through the g-s desktop app would require an order of magnitude more steps. The previous system was really quite efficient.

It’s not even possible to get the old behaviour back through the use of modified keybindings, because with -i you get two windows. The first window is unnecessary, the second OTOH window is helpful.

Sebastien Bacher (seb128) wrote :

What was your workflow? GNOME is adding keybinding to directly copy the screenshot to the clipboard, so if you need that the new way will be less steps than the old one, just a keybinding and paste in your application for example

Tobias Wolf (towolf) wrote :

Seb, do you have a link to Gnome design document handy? Any discussion about this? Mailing list posts?

If we add a keystroke for copy to clipboard we would have:

 • Print : whole screen
 • <Alt>Print : focussed window
 • <xyz>Print : copy to clipboard, but what? window, desktop, area?

The old system was a good solution, I don’t get this. Is it just plain old feature-remov-itis?

Tobias Wolf (towolf) wrote :

I mean

In one direction:

  <PrtScr>, but I don’t care, just save: 1x Enter/click , the window is gone, result like now.

in the other direction:

  click, click, click, scan, scroll, click, window, click, click button.


 <PrtScr>, click, click, file browser, looong list, scan it, open some generic files to find the right picture, copy, paste

Sebastien Bacher (seb128) wrote :

Not sure if GNOME has design documents for such changes

Tobias Wolf (towolf) wrote :

To answer my own question, in gnome-control-center git there are slots for *six* keybindings now!
That doesn’t sound like a very thought-out strategy to map six bindings only to avoid that one little dialog.

And, to wit, we don’t have the new gnome-settings-daemon with media-keys, we’re stuck with the old system.


<?xml version="1.0" encoding="UTF-8" ?>
<KeyListEntries group="system" schema="org.gnome.settings-daemon.plugins.media-keys" _name="Screenshots">

 <KeyListEntry name="screenshot"
                      _description="Take a screenshot"/>

 <KeyListEntry name="window-screenshot"
                      _description="Take a screenshot of a window"/>

 <KeyListEntry name="area-screenshot"
                      _description="Take a screenshot of an area"/>

 <KeyListEntry name="screenshot-clip"
                      _description="Copy a screenshot to clipboard"/>

 <KeyListEntry name="window-screenshot-clip"
                      _description="Copy a screenshot of a window to clipboard"/>

 <KeyListEntry name="area-screenshot-clip"
                      _description="Copy a screenshot of an area to clipboard"/>


Tobias Wolf (towolf) wrote :

I found the FIXED bug where the change was put foward:


It’s not just feature-remov-itis, it’s Morbus McCannia. I must say I disagree diametrically with the optimal workflow suggested there.

Changed in gnome-utils:
importance: Unknown → Medium
status: Unknown → Confirmed
Jhosman Lizarazo (jhosman) wrote :

And what is the solution we must apply to not do it from the terminal?

Sam_ (and-sam) wrote :

@ #26
Workaround with ccsm gnome-compatibility took their decision off my back.

Jhosman Lizarazo (jhosman) wrote :

In fact if I think a solution was obvious, that since the beginning of the problem the screenshots is being performed by pressing PrintScreen or writing to the terminal, but if we capture after a certain time or select a window or some to capture this area can not be done now as it was before, with the program manager screenshots

Marc Deslauriers (mdeslaur) wrote :

I feel this is a security issue.

Having someone hit PrintScreen by mistake and having the contents of whatever they were doing basically silently stored in the pictures folder is quite evil.

We need to either disable the hotkey unless the app is running, or pop up the dialog like we used to.

security vulnerability: no → yes
Marc Deslauriers (mdeslaur) wrote :

By default, on Ubuntu, the Pictures folder is readable by all other users...

+1, we need the screenshot app to pop up and offer the user to save the
shot. It can default to the pictures folder and appropriate filename,
but the user should have choice to cancel or redirect.


John Lea (johnlea) wrote :

+1 as well, making as a design priority.

Changed in ayatana-design:
assignee: nobody → John Lea (johnlea)
importance: Undecided → High
status: New → Triaged
tags: added: udp
Dmitry Shachnev (mitya57) wrote :

I'll suggest adding a gsettings option to make interactive mode default — so we'll be able to adjust default behaviour without applying any patches.

Sebastien Bacher (seb128) wrote :

Ok, seems there is much hate for that tablet like behaviour, I told GNOME that users hate it and will look at reverting it ;-)

Changed in gnome-screenshot (Ubuntu):
status: Triaged → In Progress
Martin Pitt (pitti) wrote :

Indeed this is quite a hideous usability regression on normal desktop systems at least, so +1 for reverting. Thanks Seb.

Changed in gnome-screenshot (Ubuntu Precise):
assignee: Canonical Desktop Team (canonical-desktop-team) → Sebastien Bacher (seb128)
importance: Low → Medium
milestone: none → ubuntu-12.04-beta-1
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-screenshot - 3.3.2-0ubuntu3

gnome-screenshot (3.3.2-0ubuntu3) precise; urgency=low

  * debian/patches/ubuntu_interactive_screenshots.patch:
    - on Unity sessions display a confirmation dialog after taking
      screenshots with the keybindings, the auto saving behaviour is
      confusing our users (lp: #927952)
 -- Sebastien Bacher <email address hidden> Mon, 20 Feb 2012 15:47:18 +0100

Changed in gnome-screenshot (Ubuntu Precise):
status: In Progress → Fix Released
Tobias Wolf (towolf) wrote :

Hi Seb, thank you, but your fix doesn’t help when I don’t use Unity.

Why did you think this only applies to Unity users?

Sebastien Bacher (seb128) wrote :

Tobias, because we keep being asked by GNOME upstream and GNOME user to let their desktop alone and ship it as designed so that's what we try to do, we stick to upstream behaviour for GNOME environments and take design decision for Unity

Tobias Wolf (towolf) wrote :

Oh yes, fair enough. I guess in other situations I was of the same opinion, just not this time. I’m getting schizophrenic here.

David Clayton (dcstar) wrote :

Just WASTED 30 minutes trying to capture a screenshot for another bug on my 12.04 system (Gnome fallback) before finally finding this change.

Talk about making simple things difficult for people - what happens if someone doesn't have sound and they just keep hitting "Print Screen" waiting for something to appear to be "Pasted" as has been the norm for... for.... for... since forever!

David Clayton (dcstar) wrote :

As someone has mentioned in another thread, ONLY having sound feedback as the sole confirmation of the Print Screen function being used is totally discriminatory to any deaf Ubuntu users (let alone those with no working sound on their systems).

This is a totally regressive change and is now beyond the "preferences" of the developers, it clearly breaks the fundamentals of providing a Linux environment able to be used by those not blessed with all the abilities that most take for granted.

There must be some visual feedback because the function is associated with the visual medium (and separating an action in one medium from the feedback in another is such poor programming that I am struggling to find an excuse for such bone-headedness).

Mark Shuttleworth (sabdfl) wrote :

This is a regression, clear guidance was given to have the screenshot
dialog show on PrintScreen.


Sebastien Bacher (seb128) wrote :

The behaviour didn't regress, the desktop team just decided to stop spending time changing GNOME behaviour and to focus on Unity which is our default desktop, we changed the behaviour only for Unity there.

 It's also something most GNOME users asked us to do, let the GNOME session be a real GNOME session and not an Ubuntu one.

@David: you decided to use GNOME fallback you get GNOME fallback, if you are unhappy about GNOME design choices you should open a bug on bugzilla.gnome.org to tell them about it

Then I'm wondering what is the point of still using GNOME as main DE if Ubuntu devs don't like it.
Is it a good approach to patch everything in GNOME to adapt it to the Unity context?
This behaviour imho create big discrepancies between the two projects. GNOME is taking is own road and I believe
in future these projects will divert so much that some simple patches won't be enough. Please fix this kind of issue :)

Sebastien Bacher (seb128) wrote :


> Then I'm wondering what is the point of still using GNOME as main DE if Ubuntu devs don't like it.

We don't, we use Unity as our main DE (even if it's using a lot of GNOME techs)

> Is it a good approach to patch everything in GNOME to adapt it to the Unity context?

No, that's why as said we are reducing our number of patching when we can

> GNOME is taking is own road and I believe in future these projects will divert so much that some simple patches won't be enough

right, which is why Unity is moved from a patched GNOME session and why you can get back GNOME upstream look and feel in Ubuntu (still some work to do but we plan to continue in that direction)

Mark Shuttleworth (sabdfl) wrote :

On 28/03/12 10:23, Lucazade wrote:
> This behaviour imho create big discrepancies between the two projects. GNOME is taking is own road and I believe
> in future these projects will divert so much that some simple patches won't be enough. Please fix this kind of issue :)

That is not an *engineering* challenge :)

thanks Seb and Mark for the answers. really appreciated.
I just hope there will be more collaboration between Unity and GNOME than challenge. Closing my OT :)

vmc (vmclark) wrote :

This now works for me as of todays livecd 64bit iso install:

 gnome-screenshot = 3.3.92-0ubuntu2

Tobias Wolf (towolf) wrote :

Anyone who wants to bring the point of accessibility to upstreams attention, please add it here:


Please note, that in Gnome Shell you get a white flash in addition to the camera shutter sound. Perhaps this doesn’t happen in classic mode. If so please add this.

The issue of discoverability was raised there too, but apparently upstream thinks that before, doing screenshots was work and now there’s less work involved. I cannot follow the logic, but the logic is put forward here:


Tim Penhey (thumper) on 2012-04-22
Changed in ayatana-design:
status: Triaged → Fix Committed
Nick Tait (jnick-tait) on 2012-04-26
Changed in ayatana-design:
status: Fix Committed → Fix Released
tags: added: reviewedbydesignp
removed: udp
jcd (jan-c-dittrich) wrote :

I need to agree with many other commenters here that this is a severe usability problem. (I'm referring to principles at http://www.useit.com/papers/heuristic/heuristic_list.html)

1) It violates standards/contradicts previous experiences.
a) The experiences of ubuntu/gnome users who are used to the dialogue.
b) The experiences of former windows users who are used to the clipboard solution.

 2) and gives not enought feedback to find out where the screenshots have gone.
There is no established standard where screenshots should go. While the discussion at https://bugzilla.gnome.org/show_bug.cgi?id=652487 named it "reasonable" there are some other resonable locations it could go to (e.g. Desktop)
Personally it took me 30min to find out what was going on.

The dialouge was according to the standard and gave visibility to actions and where your data went. The new solution does only tell you that something happened.

affects: gnome-utils → gnome-screenshot
Tester Tester (takida) wrote :

Confirmed on Debian Testing ("Wheezy"), kernel version: 3.2.0-2-amd64.
The bug appared after a recent update.

When pressing "PrintScreen" button no dialog window appears , only clicking sound and a flash. No screenshots can be found in the Bilder/Pictures folder.

It works correctly only when executing a command "gnome-screenshot --interactive"

Tester Tester (takida) wrote :

Ok, I've got the idea from post #4 here, it's not a bug, it's a feature.
It's slightly not usual, may there be an option to make it work like before?

Jamie Strandboge (jdstrand) wrote :

The linux-linaro kernel is community maintained and should be tracked in its own bug and not part of the supported kernel cadence process. If someone would like to provide updates for the linux-linaro kernel, please file a new bug and follow https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures. Thanks.

Jamie Strandboge (jdstrand) wrote :

Oops! This was obviously not meant for this bug. Sorry for the noise.

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
AC (atcapollo) wrote :

Are Gnome actually fixing this upstream, the bug https://bugzilla.gnome.org/show_bug.cgi?id=669629 didn't seem very decisive.

I've just wasted 25mins trying to find where Gnome dumps screenshots to.

bowser (bwbernard-wong1) wrote :

Excuse me? It says "fix released", but where is the fix? I am using 12.04 with Unity, everything is up to date. When I try to take a screenshot with PrtSc I hear a shutter sound and see a flash, but no dialogue box and no screenshot is saved in ~/Pictures. Do I need to tweak some settings?

bowser (bwbernard-wong1) wrote :

Never mind. Turned out the problem was that I have installed shutter, even after removing it the keybinding persists. Here is the solution in case anyone encounters the same problem. http://askubuntu.com/questions/30701/keyboard-shortcuts-not-working-after-removing-shutter/42435#42435

Changed in gnome-screenshot (Debian):
status: Unknown → Confirmed

IMHO this "feature" is idiotic. The time it takes to make and save screenshots is more than double, especially fi capturing areas instead of the whole screen.

Not having a simple way to change this behaviour is even worse!

So if like me you prefer the old way here is a simple fix. Create a file called gnome-screenshot somewhere that is in your path before /usr/bin (~/bin in my case) and put this into it:

exec /usr/bin/gnome-screenshot -i

Then make it executable (chmod 755 gnome-screenshot) and voila!
It works AS IT IS SUPPOSED to.

Angel Guzman Maeso (shakaran) wrote :

Still crashing in Quantal the popup for save the image with Gnome session (without effects) and I can't save the screenshot file:

$gnome-screenshot --delay 3
** Message: Unable to use GNOME Shell's builtin screenshot interface, resorting to fallback X11.

I only can get work and make a screenshot with interactive option:

$ gnome-screenshot --interactive
** Message: Unable to use GNOME Shell's builtin screenshot interface, resorting to fallback X11.

This makes possible make the screenshot but the warning is still showed.

Joachim Schwender (jschwender) wrote :

I have a thin client environment - no way to have graphics hardware acceleration. gnome-screenshot depends on gnome-shell but has no dependency on the package. I cannot install gnome-shell i use the fallback mode. As a work around i have installed the xfce4 screenshot tool and just created a link named /usr/bin/gnome-screenshot pointing to /usr/bin/xfce4-screenshooter. This way i get the xfce4 screenshot dialog by pressing <prtscr>, which is working good for me. With more of these defective gnome and unity developments i will be forced to completely change to xfce sooner or later....

Changed in gnome-screenshot:
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.