[SRU] Window manager keybindings don't work after reboot

[Luke Schlather]

[Impact]

Some window manager actions are defined twice in the user keyboard shortcuts file (result of mixing the Xubuntu and Xfce keyboard shortcut files from /etc/xdg/ to generate the user specific file).
This breaks the ability to permanently rebind these actions to a different keyboard shortcut.
List of affected actions can be found in comment #31.

[Test Case]

1) Delete the existing ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml.
2) Restart the session or reboot the system.
3) Use Settings -> Window Manager to rebind a key (e.g. rebind super + m to maximize window).
4) Restart the session or reboot the system.

Expected result:
The changed binding is recognized and triggers the assigned action.

Current result:
The changed binding is no longer recognized.

[Regression Potential]

Little to none.
Only an XML file is modified. If the updated XML file has an error, it could possibly cause the Xfce settings daemon to not apply certain keyboard shortcuts properly.

[Squalou-jenkins (squalou-jenkins)]

I'm using Archlinux, which provides version 4.6.2 of Xfwm4,
so I apologize if this is no more relevant.

What happens : I bind the keyboard shortcut "super m" to the maximize function.
It works juste fine.

If I reboot (or leave the session), next time the shortcut won't work.

In the configuration panel, the shortcut appears as if correctly set, but it is not working.

Other shortcut work fine.
I tried another key cmbination : same problem.
I tried the "super m" for another shortcut : it works.

So it narrows the issue to the "maximizeé thing.

Thank you,

regards

[Olivier Fourdan (fourdan)]

Humm, works just fine here.

"Super" is a bit special with some keyboard mappings and is reported as both a modifier and a regular key, I guess this is the source of your problem.

I don't think it's a bug in xfwm4 (as I said, works just fine here, Fedora 13)

[Squalou-jenkins (squalou-jenkins)]

(In reply to comment #1)
> Humm, works just fine here.
>
> "Super" is a bit special with some keyboard mappings and is reported as both a
> modifier and a regular key, I guess this is the source of your problem.
>
> I don't think it's a bug in xfwm4 (as I said, works just fine here, Fedora 13)

Strange.
I've got the "super" key mapped to other shortcut, (super v for vertical maximize e.g. ) : it works fine.
If I use this working hortcut for maximise : this one does not work.

That's why I'd say it points to "maximize" issue.

Next time I login, I'll try Alt instead of Super, I'm pretty sure I already did that but I prefer try again.

[Squalou-jenkins (squalou-jenkins)]

I just tried with "Alt M" shortcut : same result.
After reboot, the shortcut doesn't work anymore, even if it appears as associated in the conf panel.

This confirms that - at least in my case, who knows why - the "maximize" thing get disassociated after reboot, or is not correctl associated at start.

[Olivier Fourdan (fourdan)]

Yet there is nothing particular to the maximize shortcut, it's just one of the shortcuts like the others.

What gives "xfconf-query -c xfce4-keyboard-shortcuts -lv" beffore and after the reboot?

There is also a known issue with shortcuts being lost (see bug 5537).

[Squalou-jenkins (squalou-jenkins)]

Created attachment 3331
xfconf-query -c xfce4-keyboard-shortcuts -lv

[Squalou-jenkins (squalou-jenkins)]

The command gives the exact same result before and after reboot.
(I used diff to be sure)

The "interesting" line might be :
/xfwm4/custom/<Super>m maximize_window_key

Fun thing : I also have this line
/xfwm4/default/<Alt>F10 maximize_window_key

But Alt F10 does not work either.

[Stephen Warren (srwarren)]

Bug 4875 reports basically the exact same issue. It is marked as a duplicated of bug 4695. Should this bug be marked as a duplicate too?

However, bug 4695 is more about the handling of multiple entries in the keyboard shortcut config files with the same logical function not being ideal. This bug and I think 4875 are more about the fact that xfce is creating a keyboard shortcut file with duplicate entries in the first place. Hence, I'm not sure if the duplicate marking is entirely correct.

For additional details, please see:
https://bugs.launchpad.net/xfce4-settings/+bug/992579

There I observe that xfce itself is creating this issue (it creates a config file with both ALT-F7 and ALT-F10 pointing at maximize_window_key; no user editing of the config file or use of xfconf is needed to cause this issue). Quoting from that bug:

Strange. I believe the file /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml is the default content for .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml, and should be copied to it when "Reset to defaults" is executed in the XFCE settings application.

However, /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml does NOT contain entries for both ALT-F7 and ALT-F10 being set to maximize_window_key (it just has an entry for ALT-F10), yet "Reset to defaults" DOES recreate this issue in the user's .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml. It seems like something in the application code rather than the default settings file is causing this problem.

[Geoffm-b (geoffm-b)]

*** Bug 10537 has been marked as a duplicate of this bug. ***

[Geoffm-b (geoffm-b)]

Same problem here, running Xubuntu 13.10.
It's been reported for almost a year, hopefully we can have some follow up?
We have to open the settings to remap the shortcut every time we reboot.
Surely there aren't only 3 people in the world who remap this shortcut?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

See bug 1295551 and bug 1299637 for additional information.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

Luke, please attach your ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml to this report.

[Daniel (web-s)]

Same to me, are there any work-arounds? System is unusable to me without my shortcuts I use all the time.

[Kevin Pankonen (coggy+launchpad)]

You can try removing the duplicate entries. From the attached xfce4-keyboard-shortcuts.xml:

<property name="<Alt>F10" type="string" value="maximize_window_key"/>
<property name="<Super>m" type="string" value="maximize_window_key"/>

[Aleksander V. Dyomin (aleksanderd-e)]

same here :(
most of changed keys are not works, but some works, its so strange...
for example, I set Alt+Left/Alt+Right to change workspace to left/right, and after restart only Alt+Left works but Alt+Right does not...

I searched at ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml and did not found duplicates for Alt+Right, both records are similar

[Aleksander V. Dyomin (aleksanderd-e)]

I found a workaround: clear before reassign!

To make a shortcut to work ok, select an action you want to reassign and click 'Clear' button until it will really empty. Sometime if there is some (hidden?)duplicates, you will still see some shortcut(the same or different), even you clicked 'Clear' button. In this case just click the button again. Since the action shortcut is really empty, just assign your custom one as usual, and it will work ok :)

Good luck!

[Daniel (web-s)]

No workaround did worked for me, either no function, or the xml did reset to default. I tried copying my old xml from a 12.10 xubuntu to the current 14.04, without luck. Eg. trying to set maximize window to Super+q does not work (nor dozen of other shortcuts). :(

[Éric Tremblay (ubuntustudio-n)]

Someone on #xubuntu or #ubuntustudio (can't remember) mentioned a workaround for this:

You simply have to delete the current key mapping twice before setting a new one. Then the new mapping will be stored in the config.

[Éric Tremblay (ubuntustudio-n)]

..oh, i see it's already listed above. Sorry for the duplicate.

[[e-mail] (j-vanderhook)]

I can confirm that clearing the current binding, until it is blank, then re-assigning the keybinding will make it persist after logout / login. On first "clear" for any key-action combo affected by this bug, it actually restores the default / previous binding. On any key-action combo that *does not* have this issue, pressing clear seems to actually clear the binding.

I'll hazard a guess that the window manager was using whatever key combo appears after you press "clear" the first time.

[Kevin Nadaud (kevin-nadaud)]

I have the same problem. But I discover something:

If the shortcut exist before (has been set by defaut), the modification is not taken into account after restarting. The default shortcut work's even if the key cominaison is not the default.
For example: After restarting, to maximise the window, Alt+F10 will work even if you set Ctrl+Alt+M.

If the shortcut doesn't exist by default, the shortcut works before/after restarting.

[hawran (hawran.diskuse)]

Got the same problem, my shortcuts for switching between workspaces (<CTLRL> + <NUMBER>) are not working in 14.04 any longer.
Annoying.

[Wybo Dekker (wybo)]

The problem here is that the original bindings (<ctrl>-F1 for workspace 1 et cetera) are not removed when you set an other binding. And the new binding is added /after/ the default binding. And, apparently, the first binding found gets active.
The solution, as long as this has not been repaired, is to edit ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml and remove the original bindings.
Note that, whenever you make other changes, all original bindings will reappear!

[Teamfortresslife (teamfortresslife)]

Good day.
I've faced some key combination issues.
1. I have Alt+Return for maximize/normalize window.
2. Log into system, try to use it on several windows:
2.1 On xfce4-terminal: Return passes to terminal, no maximizing occur.
2.2 On Thunar window: Instead of maximizing I got directory properties window.
3. Then go to settings -> Window Manager -> Keyboard.
3.1 I got Alt+Return as maximize window.
3.2 Reset this entry, set Alt+Return again.
4. Then go and try maximize windows again:
4.1 Everything works.
4.2 After system restart combination is broken again.

$ xfce4-about --version
xfce4-about 4.11.1 (Xfce 4.10)

$ uname -a
Linux aperture 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04 LTS
Release: 14.04
Codename: trusty

[Cad5047c (cad5047c)]

Created attachment 5526
Window Manager

My version of xfsettingsd is 4.11.2 (xfce 4.10)

I have a bug similar as bug 968: https://bugzilla.xfce.org/show_bug.cgi?id=968

Eg when changing the keyboard settings for the window manager, specifically the maximize_window_key.

Every time I logged in again into the system, the keyboard I set for the maximize_window_key (<Super>Up) wouldn't work anymore.

Another way to reload the settings that would remove the shortcut I set is:

XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon x

After investigating it , I found out that the value="maximize_window_key" was twice in my ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml file:

      <property name="&lt;Alt&gt;F10" type="string" value="maximize_window_key"/>
      <property name="Escape" type="string" value="cancel_key"/>
      <property name="&lt;Alt&gt;F12" type="string" value="above_key"/>
      .......
      .......
      <property name="&lt;Super&gt;Up" type="string" value="maximize_window_key"/>

Thus the Alt F10 was probably overridding my configuration everytime.

My colleague had exactly the same issue with the same key, so I suspect they is a general issue because the XML is not cleaned when loaded.

I solved my issue by using the Clear button on the Window Manager -> Keyboar Tab

[Ang Bongsong (notinsideofhereiamnotinside)]

None of the workarounds posted solve this issue for me (I'm under Xubuntu 14.04). Thankfully I set up a good deal of shortcuts back on 13.10, but there were some I left out which I'd love to get working now (specifically the shortcuts for tiling windows). Hope this bug gets fixed soon.

[Adarsh K (adarsh)]

I am working on this bug please send me the related information about this bug

[Wybo Dekker (wybo)]

On 2014-09-16 11:10, Adarsh K wrote:
> I am working on this bug please send me the related information about
> this bug

This is what I wrote about this bug:

The problem here is that the original bindings (<ctrl>-F1 for workspace 1 et
cetera) are not removed when you set an other binding. And the new binding is
added /after/ the default binding. And, apparently, the first binding found gets
active.
The solution, as long as this has not been repaired, is to edit
~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml and
remove the original bindings.
Note that, whenever you make other changes, all original bindings will reappear!

--
Wybo

[Timmy (brian26198)]

I just recently had this problem. I was trying to clear the default keyboard shortcuts for adding and removing workspaces, which were Alt+Insert and Alt+Delete for me.

Specifically, my problem was that whenever I cleared them, and logged and logged back in they would regenerate themselves. In fact, even if I had set anther keyboard shortcut the original ones would still work even though they wouldn't be shown in the settings manager or the ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml.

To fix it, I opened a terminal and ran xfce4-settings-editor. In this gui, I went to the xfce4-keyboard-shortcuts channel. In there I saw entries for Alt+Insert and Alt+Delete, and these entries showed they were mapped to adding and removing workspaces respectively. I double-clicked on them and changed the mapping so that the value field was the empty string. Then I was able to assign hotkeys and log out and log back in normally and everything worked.

[Evgeniy Fitsner (drfits)]

The root cause of the bug, that you should set and save "override" option to true (by default it's bugly displaying as true but it's not so), and only ater that you can change your hotkeys, because if you don't set this option your changes will be owerriten after reboot.

[Alfredo (alfredo-diaz)]

I've used a xslt to remove al empty properties. It appears to work.

I created a xslt file "remove-empty-properties.xsl" with this content

<xsl:stylesheet xml:space="default" version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="xml" version="1.0" encoding="utf-8" omit-xml-declaration="no" />
  <xsl:template match="node() | @* | text()">
    <xsl:copy>
      <xsl:apply-templates select="node() | @* | text()" />
    </xsl:copy>
  </xsl:template>
  <xsl:template match="property[not(property) and @type='empty']" />
</xsl:stylesheet>

# now, make a backup of your configuration
mv xfce4-keyboard-shortcuts.xml xfce4-keyboard-shortcuts.xml.bak

# after, clean the file with xsltproc. (you can install it with the command "apt-get install xsltproc")
xsltproc -novalid remove-empty-properties.xsl xfce4-keyboard-shortcuts.xml.bak > xfce4-keyboard-shortcuts.xml

It works for me :)

[Evgeniy Fitsner (drfits)]

It sounds awesome , but the most easy way - to change override option to false (double click on override), then change back to true(double click againe) and all will be working fine without any XSLT transformations and other tricks :)

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

Adarsh, are you still working on this bug? If no, please update the bug status.

[Adarsh K (adarsh)]

Ya i am still working but i am unable to detect this bug please help me to find it

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

Adarsh, how can we help you to find the bug? Are you not able to reproduce it anymore?

[Adarsh K (adarsh)]

I got the presence of bug but in that when we rebind super+m key even before rebooting it doesn't work. I mean as given in bug description it is written that after rebind super+ m key it works fine but after rebooting the key binding is no longer recognized, that is not the situation with me what i am getting is immediately after rebind of the key also it doesn't works.

[Adarsh K (adarsh)]

super+m key is not working for any key bindings. The problem is not only with maximizing windows but it is identified for other keybindings also so please correct me if i am wrong Thaddaus

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

I recommend that you read all the bug comments and also look at the reports which are marked as duplicate. Other than that, I am afraid that I cannot help you with resolving this problem (or anything related to broken key bindings).

If you are not able to provide a patch for this bug, please revert the bug status to "confirmed" and remove the assignee.

[Wybo Dekker (wybo)]

On 2014-11-10 20:06, Adarsh K wrote:
> super+m key is not working for any key bindings. The problem is not only
> with maximizing windows but it is identified for other keybindings also
> so please correct me if i am wrong Thaddaus

I think you should have a look at:
.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml

This file defines several shortcuts twice. For example, in my version it
contains two definitions that maximize the current window:

<property name="&lt;Alt&gt;F7" type="string" value="maximize_window_key"/>
<property name="&lt;Alt&gt;F10" type="string" value="maximize_window_key"/>

in that order. It is the second, Alt-F10, that works, but if I look in the
xfce4-settings-manager, that tells me that Alt-F7 should maximize the window.

Of course, such definitions should occur only once.
The attached script looks for multiply defined shortcuts in
.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml.
When I run it on my own xfce4-keyboard-shortcuts.xml I get:

2 move_window_workspace_5_key
2 move_window_up_key
2 move_window_workspace_2_key
2 move_window_workspace_4_key
2 move_window_left_key
2 workspace_12_key
2 move_window_right_key
2 up_workspace_key
2 workspace_11_key
2 move_window_workspace_9_key
2 workspace_10_key
2 maximize_window_key
2 move_window_prev_workspace_key
2 move_window_workspace_8_key
2 move_window_workspace_1_key
2 move_window_next_workspace_key
2 move_window_workspace_3_key
2 move_window_workspace_6_key
2 move_window_workspace_7_key
19 doubles

When I remove the first occurrences of all these double definitions from the
file it looks like my system has become sane: I don't succeed in generating new
double definitions by redefining shortcuts in xfce4-settings-manager and
everything works as expected. So it may well be that these double occurrences
have been generated by older versions of xubuntu.
If this is true, then it may be wise to have xfce4-settings-manager to check for
the occurrence of double definitions and let it remove those.

I suggest that you first clean up your own xfce4-keyboard-shortcuts.xml and see
if that helps.

--
Wybo Dekker

[David C (c64whiz)]

There must be another variation in XFCE that makes the difference. I'm running 14.04.1 w/XFCE 4.10.1 and xfce-settings 4.11.2-1ubuntu2.

I successfully cleared the settings for changing workspaces, multiple times to even clear the default. Then I went back to the general settings page, returned to "Window Manager" and then set the workspaces to Super+1 thru 4. The settings then remained across login/outs and reboots.

HTH.

--C64Whiz

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

There seems to be no actual progress and we are still waiting for a fix.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xubuntu-default-settings - 15.04.2

---------------
xubuntu-default-settings (15.04.2) vivid; urgency=medium

  * Prevent redefinition of maximize window in keyboard shortcuts
    (LP: #1292290)
  * Fix CSD windows with Compton
 -- Sean Davis <email address hidden> Mon, 19 Jan 2015 07:15:12 -0500

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Brian Murray (brian-murray)]

Hello Luke, or anyone else affected,

Accepted xubuntu-default-settings into utopic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xubuntu-default-settings/14.10.12 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Luke, or anyone else affected,

Accepted xubuntu-default-settings into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xubuntu-default-settings/14.04.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

We will have to upload another package for trusty, because the current one in -proposed does not fix the bug completely.

The new package for utopic can be tested. If it fixes the bug for you, please add a comment and the tag verification-done-utopic (please leave the tag verification-needed).

Thanks.

[Brian Murray (brian-murray)]

Why is it that only Trusty requires a reupload? Additionally, the changes are a bit more extensive now, why is that?

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

The following commit was not applied, so we need to reupload a new trusty package:

http://bazaar.launchpad.net/~xubuntu-dev/xubuntu-default-settings/trunk/revision/482

This commit was merged during the utopic development phase and fixes most of the keyboard action mentioned in comment #31.

[Brian Murray (brian-murray)]

Hello Luke, or anyone else affected,

Accepted xubuntu-default-settings into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xubuntu-default-settings/14.04.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

This bug can be triggered if one messes around with the Xfce keyboard shortcuts file and adds 2+ definitions for the same action.
If your distribution provides a custom config file, two different definitions for a specific action might end up in the user config file.

Xubuntu specific bug report:

https://bugs.launchpad.net/ubuntu/+source/xfce4-settings/+bug/1292290

[Ubuntu Foundations Team Bug Bot (crichton)]

As a part of the Stable Release Updates quality process a search for Launchpad bug reports using the version of xubuntu-default-settings from trusty-proposed was performed and bug 1417836 was found. Please investigate this bug report to ensure that a regression will not be created by this SRU. In the event that this is not a regression remove the "verification-failed" tag from this bug report and tag 1417836 "bot-stop-nagging". Thanks!

[Simon Steinbeiß (ochosi)]

*** Bug 10952 has been marked as a duplicate of this bug. ***

[Simon Steinbeiß (ochosi)]

*** Bug 10959 has been marked as a duplicate of this bug. ***

[Ubuntu Foundations Team Bug Bot (crichton)]

As a part of the Stable Release Updates quality process a search for Launchpad bug reports using the version of xubuntu-default-settings from trusty-proposed was performed and bug 1418377 was found. Please investigate this bug report to ensure that a regression will not be created by this SRU. In the event that this is not a regression remove the "verification-failed" tag from this bug report and tag 1418377 "bot-stop-nagging". Thanks!

[Olivier Fourdan (fourdan)]

Still cannot reproduce.

What keyboard layout do you use?

[Teamfortresslife (teamfortresslife)]

I have the same ussie. I'm using Alt + Enter to maximize. It works until reboot. In next run shortcut is erased. Happens only with maximize function as for topicstarter.

It happens in "us" keyboard layout. I have quite standard system with standard package sources. Bug is stable reproducible.

↳ xfwm4 --version
 This is xfwm4 version 4.11.1 (revision 2b800f4) for Xfce 4.10
 Released under the terms of the GNU General Public License.
 Compiled against GTK+-2.24.23, using GTK+-2.24.23.

 Build configuration and supported features:
 - Startup notification support: Yes
 - XSync support: Yes
 - Render support: Yes
 - Xrandr support: Yes
 - Embedded compositor: Yes
 - KDE systray proxy (deprecated): No

↳ lsb_release --all
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty

↳ uname --all
Linux aperture 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[Olivier Fourdan (fourdan)]

Can you please attach the full content of your "~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml" ?

[Olivier Fourdan (fourdan)]

(In reply to Olivier Fourdan from comment #14)
> Can you please attach the full content of your
> "~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml" ?

Even better, Set the shortcut, save "~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml", then reboot, then copy "~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml" again and attach them both (before/after) here.

[Teamfortresslife (teamfortresslife)]

@Olivier Fourdan
It semees issue is fixed. I've looked through config you noted and it has two binding for maximize: `Alt + Enter` and `Alt + F10`. Don't know how it happened, as I do not use any custom utilities rather then Xfce supplies. I've just delete `Alt + F10` binding and everything works fine instantly and after reboot, so now binding is stable.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

Did anyone test the updated package in -proposed?

[Edward Falk (ed.falk)]

I spent a lot of time configuring my system the way I wanted it, and everything was lost on the next reboot. Highly annoying. This is the kind of thing that prevents Linux from being generally accepted for the desktop.

[Edward Falk (ed.falk)]

Note: attaching xfce4-keyboard-shortcuts.xml. Observe that there are two entries for workspace_1_key: "<Primary>F1" which is the system default and "<Primary>1" which is what I changed it to.

(Aside: why doesn't the system respond to both of those shortcuts?)

This is under Ubuntu/xfce4 14.04

[Chris McCormick (chris-mccormick)]

I am experiencing this same issue on Ubuntu 14.04 with xubuntu-desktop installed.

To summarize:

 * I set a new keybinding in Settings -> Window Manager. In my case it was "Alt-F1" to switch to workspace 1.
 * When I log out or reboot the key binding is lost and "Alt-F1" does nothing. Settings -> Window Manager still says it's bound to "Alt-F1" but it does not function.
 * If I re-set the key by double-clicking "Alt-F1" and then pressing "Alt-F1" again it works.
 * In the file `~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml` multiple definitions exist for the same key combination and also for `workspace_1_key`.

I have tried the following fixes:

 * In Settings -> Window Manager "clear" the key first. It shows "Ctrl-F1" (the old value) on the first click and then shows "" - the value I would expect on the second click. I then re-bind the "Alt-F1" key.
 * In Settings -> Settings Manager -> Settings Editor -> xfce4-keyboard-shortcuts I have tried un-clicking and re-clicking "override" two times in a row.

I will report back as to whether these fixes work or not. Obviously this should be fixed in the code though.

[Boris Aranovich (nomaed)]

I can confirm the same on Xubuntu distribution of Ubuntu 14.04.2.
Configured Maximize window to Super+M.
It works fine until reboot. After that it doesn't respond until I open xfwm4-settings and re-configure the shortcut again.
It works then until the next reboot, and then everything has to be repeated.

$ xfconf-query -c xfce4-keyboard-shortcuts -lv | grep maximize_window_key
/xfwm4/custom/<Alt>F10 maximize_window_key
/xfwm4/custom/<Super>Up maximize_window_key
/xfwm4/default/<Alt>F10 maximize_window_key
/xfwm4/default/<Alt>F7 maximize_window_key

Note: After a reboot, before I reconfigure Super+M, the Alt-F10 is maximizing my window. After re-configuration Super+M works but Alt-F10 is ignored. Both lines still appear in the output of xfce4-keyboard-shortcuts

[Boris Aranovich (nomaed)]

Sorry, I meant Super+Up, not Super+M

[Boris Aranovich (nomaed)]

And just checked, same issue with my Show Desktop key, which I reconfigured from Ctrl-Alt-D to Super-D.

$ xfconf-query -c xfce4-keyboard-shortcuts -lv | grep desktop
/xfwm4/custom/<Primary><Alt>d show_desktop_key
/xfwm4/custom/<Super>d show_desktop_key
/xfwm4/default/<Control><Alt>d show_desktop_key
/xfwm4/default/<Primary><Alt>d show_desktop_key

[Henry Law (news-lawshouse)]

I confirm this with Ubuntu 14.04.2 with XFCE provided by the xubuntu package: I delete .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml, log in and set the shortcut; it works. Then if I log out and back in again it doesn't work, despite the shortcut definition being shown by the applet, by xfconf-query and by inspecting the xfce4-keyboard-shortcuts.xml file.

I've tried saving the xfce4-keyboard-shortcuts.xml when the shortcut works, and copying it back in again after the logout/login sequence (when it's stopped working) and it makes no difference; it doesn't look like the problem lies in the shortcuts file itself.

I'd love to contribute to fixing this but I haven't the skill; it's really disruptive.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

IMPORTANT

If you are affected by this bug, please read comment #43 and then follow the instructions from the bug description.

[Henry Law (news-lawshouse)]

I installed xubuntu-default-settings from the "proposed" repo

# dpkg -l | grep xubuntu-default-settings
ii xubuntu-default-settings 14.04.8

Having deleted the xfce4-keyboard-shortcuts.xml file for user "aaa" I logged in as that user and used the settings applet to bind /usr/local/bin/logpid ( a simple utility which writes the current PID to the system log) to Ctrl-PrtSc (which appears in the shortcuts file as <Primary>Print).

Despite the fact that the shortcut is in the file ...

# sudo grep Print /home/aaa/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml
      <property name="&lt;Primary&gt;Print" type="string" value="/usr/local/bin/logpid"/>

... the bound action didn't work at all; nothing was written to the system log (displayed from another terminal). Executing /usr/local/bin/logpid from the command line produced the expected log entry, demonstrating that the utility does work.

So I'm unable to verify that the new version fixes the bug because the expected binding behaviour failed.

[Henry Law (news-lawshouse)]

Sorry, forgot to add OS version:

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

Henry, it is possible that you have found another bug which is specific to the combination Ctrl-PrtSc. According to the bug description of this report, newly assigned keyboard shortcuts work properly until the system is rebooted.

Please verify that the updated package fixes the affected window manager actions mentioned in comment #31.

[Henry Law (news-lawshouse)]

OK, this is the first time I've installed "proposed" code and I didn't get it quite right. I've now taken a much more rigorous approach to it by

- Installing clean 14.04.2 and updating all software (giving "Ubuntu 14.04.3 LTS")
- enabling "proposed" as described in https://wiki.ubuntu.com/Testing/EnableProposed
- updating again
- installing xubuntu-default-settings 14.04.8 using the command

 sudo apt-get install xubuntu-default-settings/trusty-proposed

I then created three test users and bound my "telltale" script /usr/local/bin/logpid to three different key combinations, one in each user: Crtl+Shift+p, Ctrl+PrintScreen and PrintScreen (this last being a remap).

I can confirm that the bindings survived both a logout/login and subsequently a reboot, so I've changed the tag to "verification done".

[Henry Law (news-lawshouse)]

Dohhh ... having created each test user I deleted the xfce4-keyboard-shortcuts.xml file for each before logging in and doing the key binding.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

Your test cases are not helpful for this bug report. They should work fine even without installing xubuntu-default-settings 14.04.8 from -proposed.

Once again, a list of affected window manager actions can be found in comment #31 (navigate to Settings > Window Manager > Keyboard to reassign them).

[Henry Law (news-lawshouse)]

"Your test cases are not helpful for this bug report"; well that's puzzling because they are precisely the test case listed at the top of this very screen.

[Test Case]

1) Delete the existing ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml.
2) Restart the session or reboot the system.
3) Use Settings -> Window Manager to rebind a key (e.g. rebind super + m to maximize window).
4) Restart the session or reboot the system.

Expected result:
The changed binding is recognized and triggers the assigned action.

Current result:
The changed binding is no longer recognized.

Under 14.04.6 the results were exactly as described above: the changed binding was no longer recognised (that is, your statement that "They should work fine even without installing xubuntu-default-settings 14.04.8" is not, for me at any rate, the case). Under 14.04.8 they are recognised, across logins and restarts. I don't have any more to say, except to thank you for the work you did in generating the fix.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

Thanks for your effort. I do not understand how the update fixes your tested keybindings, but I am glad that it does not break anything.

The test case mentioned in the bug description clearly states that you need to change keyboard shortcuts via Settings -> Window Manager (-> Keyboard). Doing so will not allow you to add any custom actions like binding a script.

[Edward Falk (ed.falk)]

The patch from comment #43 seems to have fixed. Thank you.

[drkwv (bl3-drkwv)]

16.04 here. Same problem.

Approach A.
1) I bind 'Pause' button to 'close_window_key' action:
xfconf-query --create --channel xfce4-keyboard-shortcuts --property '/xfwm4/custom/Pause' --type string --set 'close_window_key'
2) It don't work.

Approach B.
1) I do the same thing through the GUI.
2) It works.
3) Until reboot.

Approach C.
1) I reset the ''/xfwm4/custom/Pause' property:
xfconf-query --reset --channel xfce4-keyboard-shortcuts --property '/xfwm4/custom/Pause'
2) I bind 'Pause' button to 'close_window_key' action:
xfconf-query --create --channel xfce4-keyboard-shortcuts --property '/xfwm4/custom/Pause' --type string --set 'close_window_key'
3) It works.
4) Until reboot.

Approach D.
1) I bind 'Pause' button to 'close_window_key' action:
xfconf-query --create --channel xfce4-keyboard-shortcuts --property '/xfwm4/custom/Pause' --type string --set 'close_window_key'
2) It don't work.
3) I delete the default Alt+F4 binding:
xfconf-query --reset --channel xfce4-keyboard-shortcuts --property '/xfwm4/custom/<Alt>F4'
4) It don't work.
5) I reboot.
6) It works.
7) Forever.

[Martin Pitt (pitti)]

The version of xubuntu-default-settings in the proposed pocket of Trusty that was purported to fix this bug report has been removed because the bugs that were to be fixed by the upload were not verified in a timely (105 days) fashion.

[Theo Linkspfeifer (lastonestanding)]

The bug was caused by a faulty configuration file provided by xubuntu-default-settings.

It does not look like xfwm4 needs any patching -> Closing.