Calc always has a focus box centering on one cell, outlined in black. When selecting a column or row by pressing the row or column selector, the outline moves to the first row in that column or row. Select column B, selector moves to B1. The outlined box is the starting point for paste operations, so its location is important for determining where things are pasted. When pressing the corner selector button to select whole table (top left corner of spreadsheet), selector box stays where it was and does not move. That means despite suggesting that the clipboard data should fill whole table, Calc pastes at whatever random location the cursor was *before* the whole table was selected. That is, if the cursor previously was on G17, after pressing the corner/spreadsheet selector, the table will paste beginning at G17 and not A1. 1. Copy data into clipboard (I was using LO Base table data) 2. Open Calc, click middle of spreadsheet somewhere. 3. Click corner/sheet selector at top left of spreadsheet 4. Paste data. Actual result: the data pasted wherever you previously clicked, not at A1 Expected result: data should paste beginning to A1. Cause of problem is non-obvious, which makes it non-trivial.
Reproducible with Version: 4.4.0.0.alpha0+ Build ID: e2723d00b77dc1044e2ba599ba93517af34e1ea5 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-09-09_23:17:41. When select whole sheet, then previously selected cell is still selected, when select row/colum then first cell is selected. Should be consistent. For example Excel do it as requester wants - when select whole sheet, then focus jumps in cell A1.
Apologies for the compound bug report, but in a related point, if one selects data from somewhere in the sheet (like G1:K8), presses ctrl-c, then clicks the corner selector and pastes the clipboard contents (ctrl-p), Calc immediately freezes and does not recover. LO Version: 4.4.1.2 Build ID: 40m0(Build:2) OpenSuse 13.2. The cursor also does not move to A1 as set forth in the report.
(In reply to Doug from comment #2) > Apologies for the compound bug report, but in a related point, if one > selects data from somewhere in the sheet (like G1:K8), presses ctrl-c, then > clicks the corner selector and pastes the clipboard contents (ctrl-p), Calc > immediately freezes and does not recover. LO Version: 4.4.1.2 Build ID: > 40m0(Build:2) OpenSuse 13.2. The cursor also does not move to A1 as set > forth in the report. Please create new bug report for this issue. Thank you
** 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.2 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-04-16
** 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 Doug, 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
Dear Doug, 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
(In reply to Doug from comment #0) > 3. Click corner/sheet selector at top left of spreadsheet > 4. Paste data. Step 3 is completely unrequired. Having to deal with this is just a waste of time. If you intent to Paste, starting on cell A1, just press [CTRL]+[HOME] and then Paste; no selection of cells is needed.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eb9044babc34572bb670d6a030c64aded9ce8fce tdf#82404 - Move active cell to A1 when whole sheet is selected It will be available in 26.8.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.
@Andreas, I regret that in my comment 10 I only spoke mildly about this change, not speaking as forcefully as I should had. In practical terms, this change has no relevant positive outcome, but indeed has negative effects. If the focus (aka active cell) is located somewhere "in the middle" of the spreadsheet, and you find out that you need to change something on the whole worksheet, and then continue working closer to the same original location, now you have to move back to that location. Before, you could had continue working without having to specifically take note of the active cell. Previously, if the user actually wanted to move to cell A1, a simple ctrl+home was enough, whether the whole worksheet was previously selected or not. Now, after this change, the move to A1 is forced, and the user has to go back to the original location, in case the prior work has to continue over the same area of the worksheet. As I said, this change has no relevant positive effect (as every edition to the entire worksheet was performed exactly the same with or without this patch), but it does have negative ones. IMO, this change should rather be reverted.
I see your observations and conclusions. I have no strong position about this change. I am in favor around 60% since for CTRL+HOME you need to move your hand from the mousee to the keyboard. I checked two competitor products (Sheets and Excel). Both change to cell A1. Should we ask the design team?
I'd rather expect to keep the cell focus on col/row selection than moving to A1 for Select All. My take: NAB/INVALID (if you want to paste at A1 move the focus there first, ie. Ctrl+Home)
205897: Revert "tdf#82404 - Move active cell to A1 when whole sheet is selected" | https://gerrit.libreoffice.org/c/core/+/205897
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fb3c28c1a9f3928c74543a2a83ee3b2bcaa446cc Revert "tdf#82404 - Move active cell to A1 when whole sheet is selected" It will be available in 26.8.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.
I wonder how many people actually want to automatically move the current cell to A1 during routine tasks. Also, Ctrl + Home doesn't always move you to A1. When rows or columns are frozen, it's actually a fantastic shortcut that moves you to the appropriate position. Anyway, thank you for marking this report as "NOT A BUG."
The frozen cells case is managed in: Bug 107994 - UI: Make Ctrl+Home move the cursor to the first non-frozen cell in the sheet