gnome-screensaver-command -p triggers keyboard event

Bug #505789 reported by inzpektor on 2010-01-11
52
This bug affects 7 people
Affects Status Importance Assigned to Milestone
gnome-screensaver (Ubuntu)
High
Chris Coulson
Karmic
Critical
Chris Coulson

Bug Description

Binary package hint: gnome-screensaver

When "gnome-screensaver-command -p" is called, it triggers a keyboard-event (something with Alt+...).

This is a problem when called from for example blueproximity where the command is called in the background and the user has an application like oowriter (or some other app with a trigger for the particular keyboard event) focused. In that case it opens the File-menu every 10 seconds, which is, needless to say, annoying.

Way to replicate:

sleep 5 && gnome-screensaver-command -p

Now focus oowriter and 5 seconds later, the File-menu will open.

BTW, this bug is new since I've used this command for at least a year and the problem surfaced after an update on December 29th 2009;

Upgraded the following packages:
gnome-screensaver (2.28.0-0ubuntu3.1) to 2.28.0-0ubuntu3.2

forsakenpariah (forsakenpariah) wrote :

I am able to reproduce this with Open Office Writer, Calc, and Impress (seems to trigger Alt-F), but tried with several other apps with triggers for Alt-F, such as a Firefox, Code::Blocks, gedit, ampng others, and I got nothing. It also seems that if it actually triggered the Alt-F event, it would open the File menu in the same terminal window it was run in. Seems to me to be an Open Office bug. Are there any other apps in which you're able to reproduce this?

I can confirm this behavior with blueproximity, OO and gnome-screensaver.

Running the following batch script in a terminal window, then giving focus to OO Writer clearly shows that the problem is gnome-screensaver-command, not blueproximity:

#!/bin/bash
for (( ; ; ))
do
   gnome-screensaver-command -p
   sleep 5
done

To me it looks like gnome-screensaver-command --poke just sends the Alt key on its own. In OO (as well as any Windows app) this opens the first menu item (or closes the menu if it happens to be open).

This behavior is really annoying since it basically makes OO unuseable when running blueproximity.

See also discussion at bottom of bug #216939.

As a workaround I use the following proximity command in blueproximity: "xdotool key Scroll_Lock && xdotool key Scroll_Lock".

Hopefully gnome-screensaver-command -p isn't issued by other apps I'm running.

Changed in gnome-screensaver (Ubuntu):
status: New → Confirmed
Changed in gnome-screensaver (Ubuntu):
importance: Undecided → High
Chris Coulson (chrisccoulson) wrote :

This is caused by my recent change to fix bug 428884. I'm slightly bewildered why we haven't seen issues like this before, as the method I chose for inhibiting the screensaver is used elsewhere already (eg, Totem uses the same method when not running under GNOME, for example when it runs under XFCE).

Anyway, I'll look for a better method to do this this evening

Changed in gnome-screensaver (Ubuntu Karmic):
assignee: nobody → Chris Coulson (chrisccoulson)
importance: Undecided → High
status: New → In Progress
Changed in gnome-screensaver (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Chris Coulson (chrisccoulson)
tags: added: regression-update
removed: blueproximity gnome-screensaver
Changed in gnome-screensaver (Ubuntu Karmic):
milestone: none → karmic-updates
Chris Coulson (chrisccoulson) wrote :

Bumping the importance of the karmic task, as we're getting some duplicates now and this is a regression in the stable release

Changed in gnome-screensaver (Ubuntu Karmic):
importance: High → Critical
Chris Coulson (chrisccoulson) wrote :

Urgh, my last comment got truncated at the start there.It was meant to read "Bumping the importance of the karmic task, as we're getting some duplicates now and this is a regression in the stable release"

Chris Coulson (chrisccoulson) wrote :

I've pushed a change to bzr which fixes this issue. Unfortunately, it breaks screensaver inhibiting again and will reopen the original bug 428884 due to a xorg regression, so I've not uploaded it yet: http://bugs.freedesktop.org/show_bug.cgi?id=25855.

Once that xorg bug is fixed, then screensaver inhibiting will work properly and this bug will be fixed. If we can't fix the xorg bug in karmic as a SRU, then the only realistic choice here is to back out the original patch and reopen bug 428884 for karmic.

Chris Coulson (chrisccoulson) wrote :

Ok, my messages aren't getting truncated, but my browser does not display them correctly. Sorry for the noise there!

Accepted into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in gnome-screensaver (Ubuntu Karmic):
status: In Progress → Fix Committed
tags: added: verification-needed
Steve Langasek (vorlon) wrote :

As this is a regression introduced in an SRU, the normal 7-day waiting period is waived; can be copied to -updates as soon as it's built.

Please test to confirm that this does correct the regression.

With the new package (2.28.0-0ubuntu3.3) I don't get this bug anymore.

Thanks for the quick fix!

Steve Langasek (vorlon) on 2010-01-12
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-screensaver - 2.28.0-0ubuntu3.3

---------------
gnome-screensaver (2.28.0-0ubuntu3.3) karmic-proposed; urgency=low

  * Back out debian/patches/10_legacy_scrsvr_inhibit.patch for now
    as the patch causes a regression, leading to menus randomly popping
    up in Openoffice (LP: #505789). This re-opens LP #428884.
  * debian/control: Don't build-dep on libxtst-dev. It's not needed without
    the above patch.
 -- Chris Coulson <email address hidden> Mon, 11 Jan 2010 23:16:04 +0000

Changed in gnome-screensaver (Ubuntu Karmic):
status: Fix Committed → Fix Released
Chris Coulson (chrisccoulson) wrote :

Thanks for testing. I've reopened the karmic task on bug 428884 now, which will have to remain open until we think of a less problematic solution

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-screensaver - 2.28.0-1ubuntu5

---------------
gnome-screensaver (2.28.0-1ubuntu5) lucid; urgency=low

  [ Chris Coulson ]
  * debian/patches/10_legacy_scrsvr_inhibit.patch:
    - Re-write to not use XTest to simulate fake key-presses in order
      to reset the IDLETIME counter, as this appears to be problematic.
      Use XResetScreenSaver() to do this instead. Thanks to Reinhard
      Tartler for the hint (LP: #505789)
  * Drop debian/patches/90_autotools.patch - no longer needed
  * Dropped debian/patches/08_gs_dialog_request_to_exit.patch - this is
    fixed by this commit in gtk: 0748cf563d0d0d03001a62589f13be16a8ec06c1,
    so there is no need to carry this patch any more.
  * Drop debian/gconf-defaults:
    - Use upstream default for lock_enabled (locking on screensaver
      activation)
    - user_switch_enabled is already set to the upstream default

  [ Marc Deslauriers ]
  * Added apport hook:
    - debian/source_gnome-screensaver.py
    - debian/gnome-screensaver.install
 -- Chris Coulson <email address hidden> Tue, 19 Jan 2010 17:46:56 +0000

Changed in gnome-screensaver (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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