The following described behavior was observed on a Win_x86 installation with a en_US UI. Under previous versions of LO, a person could type <alt>+e,i,d in a spreadsheet and that would navigate the menu: Edit -> Fill -> Down. This provided a quick and convenient way to fill cells. With version 4.4.0.3, typing <alt>+e,i,d results in an entirely different behavior which leads to data loss: Typing <alt>+e,i triggers 'Edit -> Edit Mode' which toggles edit mode off (presuming that the current spreadsheet had been saved previously and that edit mode is currently on). At that point, a confirmation dialog pops up asking whether to save or discard the current changes to the document. Typing the final 'd' activates the discard button, causing a permanent loss of unsaved changes. Most people learn and make use of keyboard shortcuts such as this because they are quick. Consequently, a user familiar with the old behavior is not apt to even see the confirmation dialog (before it's too late) because the entire key sequence is typed so quickly. Granted, a user will eventually learn (after loosing valuable work) to avoid typing the troublesome key sequence. But in my opinion, the reassignment of the 'i' shortcut from 'Fill' to 'Edit Mode' was a poor choice, and it should be switched back because: 1) The 'Fill' actions are much more likely to be used with regularity than the 'Edit Mode' toggle. Frequently used actions should be given priority for the assignment of single-letter shortcuts. 2) The 'Edit Mode' toggle already has another shortcut assigned (Ctrl+Shift+M). There's little value gained in assigning it the 'i' shortcut as well. 3) The 'Fill' action opens up an entire submenu which has additional single-letter shortcuts ('d' for down, etc.). Using these single-letter shortcuts on the submenu is impractical if there is no easy way to open the submenu via a single letter.
Hi @tdfb, thanks for reporting. Win7x64 Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Fill hasn't a letter assigned, so I can't reproduce your data loss issue but the behaviour has changed.
(In reply to m.a.riosv from comment #1) > Hi @tdfb, thanks for reporting. > > Win7x64 > Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 > > Fill hasn't a letter assigned, so I can't reproduce your data loss issue but > the behaviour has changed. You are correct -- 'Fill' doesn't currently (4.4.0.3) have a letter assigned. In previous versions, 'Fill' had the letter 'i' assigned. The letter 'i' has now been reassigned (in 4.4.0.3) to 'Edit Mode'. To reproduce the data loss: 1. Create a spreadsheet 2. enter some data 3. save the spreadsheet 4. enter some additional data 5. select a range of cells 5. Type "<alt>+e", "i", "d". In previous versions, users would type this sequence to perform a "Fill Down" operation over the selected range. In the current version, the sequence does something entirely different -- it toggles "Edit Mode" to read-only, a confirmation dialog pops up, and upon typing the final "d", the unsaved changes are discarded, resulting in data loss. My premise is that users will have previously memorized the shortcut sequence for performing a "Fill Down" and won't notice that the sequence is no longer valid until after typing it and loosing their unsaved changes. (As you might guess, I was such a user.) My secondary point was that the current lack of any shortcut letter assigned to "Fill" now makes it more difficult to navigate to its submenu and the shortcut letters found there. Using the "Fill" action is a common spreadsheet task and therefore should be easily accessible.
Hi tdfb, I think a good lesson to take from this, the developers and localizers try to keep consistent shortcuts. But that is hard when menu's change and also (part of the) shortcuts are assigned dynamically by the software. Maybe is specific cases as this one, a proposal could come for setting fixed shortcuts and then hope that these are not changed in later versions?
** 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.0.5 or 5.1.0) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
** 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.5 or 5.3.0 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-20170306
Dear tdfb, 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 https://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
Dear tdfb, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug