Steps to reproduce: 1. Create three lines of data and create an auto-filter, eg 1 FRUIT 2 Apple 3 Banana 4 Apple 2. Filter out the centre line using the auto-filter FRUIT=Apple 3. Use the mouse click and drag to select a block of cells covering the two remaining cells (ie 2A and 4A, both Apple). This also selects the hidden cell 3A (Banana). 4. Press CTRL-B and both visible cells are set BOLD 5. Press CTRL-B again Current behavior: Nothing happens, and if you look the hidden cells are NOT BOLD Expected behavior: The first CTRL-B should set both visible and hidden cells to BOLD. The second CTRL-B should set both visible and hidden cells to NOT BOLD. (This is what happens if you simply hide a row, rather than using an autofilter) Operating System: Windows 7 Version: unspecified
Hi Toby, thanks for reporting. I think it is the intended behaviour, otherwise there is no way to select in what to change e.g. the format only in some selected rows or copy only those selected rows. On the other hand apply a filter it is not the same as hide/show rows/columns although it seems. Changed status to RESOLVED NOTABUG, please if you are not agree reopen it.
Dear mariosv, ok, I accept that the hidden cells shouldn't be selected. However there's still a bug: On the first CTRL-B, the visible cells are set BOLD. On the second CTRL-B, the visible cells should be set NOT BOLD, however nothing happens and they remain BOLD. Toby
You are right Toby, a second Ctrl+B without touch the selection does nothing. Reproducible: Win7x64Ultimate Version 4.0.6.2 (Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24) Version: 4.1.4.0.0+Build ID: d6ee64b75581cbeb92534271ee6f4e87f07aa5c
** 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 (4.4.1 or later) 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: 2015-04-18
Retested on v4.4.2.2 / win7pro - no change
** 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.1.5 or 5.2.1 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-20160920
v5.2.1.2 - no change on Win7 pro EDITED Steps to reproduce: 1. Create the following lines of data and create an auto-filter on the first line: 1 FRUIT 2 Apple 3 Banana 4 Apple 2. Filter out the centre line using the auto-filter FRUIT=Apple 3. Use the mouse click and drag to select a block of cells covering the two remaining cells (ie 2A and 4A, both Apple). This also selects the hidden cell 3A (Banana). 4. Press CTRL-B and both visible cells are set BOLD 5. Press CTRL-B again Current behavior: Nothing happens Expected behavior: The second CTRL-B should set visible cells to NOT BOLD.
** 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 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
Bug still exists. Version: 5.4.2.2 (x64) Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 4; OS: Windows 6.1; UI render: default; Locale: en-GB (en_GB); Calc: CL
Retested on v6.1.3.2 (x64) / win7pro - no change On the first CTRL-B, the visible cells are set BOLD. On the second CTRL-B, the visible cells should be set NOT BOLD, however nothing happens and they remain BOLD. 5 years :( Version: 6.1.3.2 (x64) Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU threads: 4; OS: Windows 6.1; UI render: default; Locale: en-GB (en_GB); Calc: group threaded
repro with Version: 6.2.0.0.alpha1+ Build ID: 84a0496de8300e4e7febb0f30862d8c5f9a1472e CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: nl-BE (en_US.UTF-8); UI-Language: en-US Calc: threaded Version: 6.3.0.0.alpha0+ Build ID: 587ef41f75b8ea0bcd03366178d42a324dcf481c CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); UI-Language: en-US Calc: threaded
Dear Toby, 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
Retested on 7.0.4.2 The same bug still exists. 1) Create the following lines of data and create an auto-filter on the first line: 1 FRUIT 2 Apple 3 Banana 4 Apple 2) Filter out the centre line using the auto-filter FRUIT=Apple 3) With the mouse select a block of cells covering 2A-4A 4) Press CTRL-B and both visible cells are set BOLD 5) Press CTRL-B again Current behaviour: Nothing happens Expected behaviour: The second CTRL-B should set visible cells to NOT BOLD
Dear Toby, 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
Retested on 7.5.0.3 This bug still exists.
While this can still be reproduced in current versions (after more than 9 years), I'd like to post a semi-workaround to those users that might be interested (FWIW). 1. Select the relevant range of cells (after the filter was applied) from the first to the last cell of the relevant range. 2. Menu Edit > Select > Select Visible Rows Only. Now you can press [CTRL]+[B] several times and see the results (on visible cells only).
Hi ady, "Edit > Select > Select Visible Rows Only" was not listed in my menu by default, but I added it using "Tools > Customise", and it does indeed work, thank you. Toby