Just spent 20 minutes getting very confused as to why I couldn't assign the Navigation controls "Back" and "Forward" to a keyboard shortcut. Had a nice long bug report all typed up for it, but before posting tried different shortcuts... Sure enough, I could assign them to Alt-B and Alt-F, but not Alt-Left and Alt-Right :p A little more experimenting and it seems that no matter what one assigns to these combinations, all that happens is the cursor moves left and right completely normally: their shortcut function isn't activated at all. I haven't upgraded to the 5.x series yet for a number of reasons (including Bug 47764 and Bug 46155) so I'd appreciate if someone else could check that this bug still exists in the newest versions :-) Steps to reproduce: In LibreOffice Writer: 1. Go to the Tools menu > Customize... 2. If not selected, select the Keyboard tab 3. Assign some (any) function to the Alt-Left and Alt-Right key combinations 4. Return to your document 5. Test the Alt-Left and Alt-Right keyboard shortcuts *Result: No effect: shortcut functions not activated*
[Reproducible] with "LibreOffice 3.5.3.1 (RC1) German UI/Locale [Build-ID: 21cb047-d7e6025-9ba54fc-b4a51a8-f42372b] on German WIN7 Home Premium (64bit). I tried to associate a macro to <Alt+leftarrow>, failed. macro is shown in list of shortcuts, but it will not be executed. It's different in Calc, there <Alt+leftarrow> and <Alt+rightarrow> are used, but I can customize, I tried to associate a macro to <Alt+leftarrow>, worked fine.
In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval. Thank you and apologies for the noise
I'm working on this bug. Seems like Alt+<any_arrow_key> does not work.
It depends on the context. If a graphic object or a presentation object is selected, then Alt+Arrow is used for one pixel movement of the object or in point mode for movement of a single point. If the cursor is inside a Writer table, Alt+LeftArrow and Alt+RightArrow is used to manipulate the column width, Alt+UpArrow and Alt+DownArrow for row height. In addition there are some bindings for languages with composed character. In accessibility context Alt+DownArrow and Alt+UpArrow is used to open/close a drop-down-list in a dialog or a combox-box in forms. In Calc Alt+DownArrow and Alt+UpArrow depends on the chosen key bindings in Tools>Options>Calc>Compatibility. So it is not true that "Alt+<any_arrow_key> does not work". So when you alter something please make sure, that the existing bindings still work.
Actually what I meant was that when we assign a new binding to Alt+<any_arrow_key>, the assigned bindings do not work. So more than 1 bindings can be assigned to Alt+<any_arrow_key> ? And when the key combination is pressed, then all the actions are to be performed?
Or, maybe if Alt+<arrow_keys> already have predefined assignments, maybe we could remove these key bindings from being customized by the user?
Just FYI, the expected action is that, if a user assigns a custom action, that one should take precedence. If no action is mapped, whatever writer does by default should be triggered. Calc does it that way too. I'm surprised Writer didn't follow this behavior.
But I do see some element of complexity in handling this, as Regina outlined in Comment 4.
Hello, I won't be able to work on this bug any more. Someone else can take it. I'll share some of my findings: The code for the key combinations in Writer is held in sw/source/core/uibase/docvw/edtwin.cxx, search for the while loop in the KeyInput method. The variable eKeyState does not get set to KS_KeyToView, which results in the key combinations being ineffective. Regards, Rachit Gupta
*** Bug 93402 has been marked as a duplicate of this bug. ***
just to tell that OOo 3.3.0 had the same problem with those "Alt+Left" and "Alt-Right" keyboard shortcuts problem persists in LibO 5.1.0.0 alpha too
Migrating Whiteboard tags to Keywords: (needsDevEval, skillDebug, topicUI) [NinjaEdit]
topicDebug is a Topic.
Remove skillDebug, superceded by topicDebug.
*** Bug 53190 has been marked as a duplicate of this bug. ***
55838 and 49091 are possibly related
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
Dear ryan.jendoubi@gmail.com, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
confirm this bug for LibO 6.0.7.3 Build-ID: 1:6.0.7-0ubuntu0.18.04.10 For Alt - left the ALT key is ignored doing same than without ALT
As one who reported this bug a long time ago to https://bz.apache.org/ooo/show_bug.cgi?id=113502 and later as duplicate bug 53190, I have have been resigned to live without the ability of customizing Alt+(Right,Left) in Writer. I finally decided to tackle this as well as another keyboard customization bug and will be submitting a patch to gerrit soon. The ability to interactively resize writer tables using the keyboard has been around for a long time. This capability is described in the help: https://help.libreoffice.org/6.2/en-US/text/swriter/guide/table_sizing.html The way this capability has been implemented breaks the ability for users to customize table sizing keystrokes to do other things. My patch corrects that by giving priority to keyboard customization if it exists. The keyboard table resizing functionality is pretty nice and I thought there might be a case where even if a user wants to customize the table sizing keystrokes to do other things, they still might want have access to that functionality when needed. My patch provides for that as follows: When Caps Lock is turned on, customized table sizing keystrokes are ignored and instead will produce their default table sizing actions. Turning Caps Lock off restores custom action. Finally it should be noted even if Alt+Right or Alt+Left have NOT been customized and you are NOT in a table, they behave like Right and Left respectively instead of acting like dead keys. My patch does not address this idiosyncrasy.
Vincent Reher committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5aa7b65c882019b74cfab95e5e9c77150b2876b0 Resolve tdf#49091 "UI: Alt-Left, Alt-Right keyboard shortcuts ineffective" It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This seems resolved. Vincent, thanks, when you do it, also close as Fixed. I do it now.