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

Bug #1292290 reported by Luke Schlather on 2014-03-14
218
This bug affects 44 people
Affects Status Importance Assigned to Milestone
Xfwm4
Confirmed
Medium
xfwm4 (Ubuntu)
Undecided
Unassigned
Trusty
Undecided
Unassigned
Utopic
Undecided
Unassigned
xubuntu-default-settings (Ubuntu)
Undecided
Unassigned
Trusty
Undecided
Unassigned
Utopic
Undecided
Unassigned

Bug Description

[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.

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

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)

(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.

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.

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).

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

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.

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.

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

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) wrote :

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

Changed in xfce4-settings (Ubuntu):
status: New → Confirmed

See bug 1295551 and bug 1299637 for additional information.

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

Luke Schlather (luke2760) wrote :
Daniel (web-s) wrote :

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

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"/>

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

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) wrote :

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). :(

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.

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

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) wrote :

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) wrote :

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

Wybo Dekker (wybo) wrote :

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!

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

Changed in xfwm4:
importance: Unknown → Medium
status: Unknown → Confirmed

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

affects: xfwm4 → xfce4-settings
Changed in xfce4-settings:
importance: Medium → Unknown
status: Confirmed → Unknown
Changed in xfce4-settings:
importance: Unknown → Medium
status: Unknown → Confirmed

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) on 2014-08-19
Changed in xfce4-settings (Ubuntu):
assignee: nobody → Adarsh Killed (adarsh-killed)
Changed in xfce4-settings (Ubuntu):
assignee: Adarsh Killed (adarsh-killed) → nobody
Adarsh K (adarsh) on 2014-09-15
Changed in xfce4-settings (Ubuntu):
assignee: nobody → Adarsh Killed (adarsh-killed)
status: Confirmed → In Progress
assignee: nobody → Adarsh Killed (adarsh-killed-deactivatedaccount)
Adarsh K (adarsh) wrote :

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

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

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) wrote :

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) wrote :

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) wrote :

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 :)

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

Adarsh K (adarsh) wrote :

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

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

Adarsh K (adarsh) wrote :

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) 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 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.

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

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

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

Changed in xfce4-settings (Ubuntu):
status: In Progress → Confirmed
assignee: Adarsh K (adarsh) → nobody
Launchpad Janitor (janitor) wrote :

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

Changed in xubuntu-default-settings (Ubuntu):
status: New → Fix Released
description: updated
summary: - Window manager keybindings don't work after reboot
+ [SRU] Window manager keybindings don't work after reboot
Sean Davis (bluesabre) on 2015-01-22
Changed in xubuntu-default-settings (Ubuntu Trusty):
status: New → In Progress
Launchpad Janitor (janitor) wrote :

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

Changed in xfce4-settings (Ubuntu Trusty):
status: New → Confirmed
Changed in xfce4-settings (Ubuntu Utopic):
status: New → Confirmed
Changed in xubuntu-default-settings (Ubuntu Utopic):
status: New → Confirmed
Sean Davis (bluesabre) on 2015-01-28
Changed in xubuntu-default-settings (Ubuntu Utopic):
status: Confirmed → In Progress

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!

Changed in xubuntu-default-settings (Ubuntu Utopic):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in xubuntu-default-settings (Ubuntu Trusty):
status: In Progress → Fix Committed
Brian Murray (brian-murray) wrote :

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!

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) wrote :

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

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) wrote :

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!

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

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!

tags: added: verification-failed

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

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

tags: removed: verification-failed

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!

tags: added: verification-failed
tags: removed: verification-failed

Still cannot reproduce.

What keyboard layout do you use?

affects: xfce4-settings → xfwm4
Changed in xfwm4:
importance: Medium → Unknown
status: Confirmed → Unknown
Changed in xfwm4:
importance: Unknown → Medium
status: Unknown → Confirmed

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

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

(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.

affects: xfce4-settings (Ubuntu) → xfwm4 (Ubuntu)

@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.

tags: added: xubuntu
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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