Hello, When you insert a spredsheet (by clicking on the icon from the picture appearing on a new slide), then you can't delete it by selecting it and pressing the "delete" key on the keyboard. Sometime it works after doing weird behaviour before (like moving to the other column when you have two columns.) Thanks for your job on Libre Office !
Confirmed using master (fb0ca7eff0e16fa8dd1a4c8d75fef23830903a3f) under Fedora 20. Steps to reproduce: 1. Open Impress/Draw. 2. Insert a table (f.e using Insert->Table... menu). 3. Select the frame of that table. 4. Hit 'Del'. Expected behavior: The selected table should be deleted. Actual behavior: Nothing is happens.
I am having this problem on LibreOffice 4.2.6.3 on Ubuntu 14.04. I installed LibreOffice 4.3, and still have the same problem. On an existing presentation, I am unable to delete an existing table created earlier. The table will also not respond to a cut command.
** 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.1 or preferably 5.0.2.2 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-10-14
Still repro. Ubuntu 15.10 64-bit Version: 5.0.3.2 Build ID: 1:5.0.3~rc2-0ubuntu1 Locale: en-US (en_US.UTF-8)
** 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.6 or 5.2.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-20170103
This bug is still present. When a table has multiple rows and columns, it's possible to delete all of the rows and columns down to a single cell. Then deleting or cutting that single cell doesn't work. Version: 5.2.3.2 Build ID: 1:5.2.3~rc2-0ubuntu1~xenial1 CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; Locale: en-CA (en_CA.UTF-8); Calc: group $ lsb_release -a LSB Version: core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:printing-9.20160110ubuntu0.2-amd64:printing-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch Distributor ID: Ubuntu Description: Ubuntu 16.04.1 LTS Release: 16.04 Codename: xenial
(In reply to daviding from comment #6) > When a table has multiple rows and columns, it's possible to delete all of > the rows and columns down to a single cell. Then deleting or cutting that > single cell doesn't work. Well, this is specifically about selecting the table frame and pressing delete. I still confirm it doesn't work. Surprise twist: it did work in 3.6.7.2, so we can add bibisectRequest. Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ Build ID: fc0d4e6bc43d5f982452df07930f5ecf5927ad22 CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on December 31st 2016 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
The underlying issue is that the table can't be deleted if the table cells are selected. This bug is already there in v3.3.0 / Ubuntu 16.04. What changed between 4.0.0.3 and 4.1.0.4 is that table cells are selected after the table is inserted. I'm not sure that change is intended or if that should be treated as a regression as well, I'm adding the details as information below (if it's a bug, open a new bug report on it): 02bb77b2f877fc23b622a3d1c239d697512fb811 is the first bad commit commit 02bb77b2f877fc23b622a3d1c239d697512fb811 Author: Matthew Francis <mjay.francis@gmail.com> Date: Fri Sep 18 10:29:02 2015 +0800 source-hash-a00b62422e5499e842d0b3b6302ba79f3d808c27 commit a00b62422e5499e842d0b3b6302ba79f3d808c27 Author: Gokul <gswaminathan@kacst.edu.sa> AuthorDate: Sat Feb 2 15:29:56 2013 +0300 Commit: Ahmad Harthi <aalharthi@kacst.edu.sa> CommitDate: Sat Feb 9 11:28:05 2013 +0000 Fixes fdo#46186, The Table Remains in the defined writing mode. The table in impress is drawn under the rectangular are, on Selecting the table it was only selecting the rectangular area and not the cells inside, Making the layout to be as RTL which was mirroring the table. But, We need the table to be in RTL Writing mode and not mirroring the table. Now on applying my patch, If table is selected, it will select the entire cells inside which is the actual table and the functionality works fine. Change-Id: I9d6bdde5019322488be66fa89a6488d348b2cf44 Reviewed-on: https://gerrit.libreoffice.org/1964 Reviewed-by: Ahmad Harthi <aalharthi@kacst.edu.sa> Tested-by: Ahmad Harthi <aalharthi@kacst.edu.sa>
Affects Windows builds as well, setting OS to All.
*** Bug 113669 has been marked as a duplicate of this bug. ***
*** Bug 90518 has been marked as a duplicate of this bug. ***
Workaround for deleting: Click into the table, then nothing is selected. Move the mouse to the edge of the table till the cursor becomes a cross. Click. Now only the frame is selected and you can press Del-key to delete the table. This does not resolve this bug report, because deleting without mouse is missing and "delete table" command similar to Writer is missing.
*** Bug 107672 has been marked as a duplicate of this bug. ***
** 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
Version: 6.0.7.3 bug still there
This bug will not just go away... still manifests with LO 6.2 RC2, i.e.: Version: 6.2.0.2 Build ID: 2ce5217b30a543f7666022df50f0562f82be0cff
*** Bug 123929 has been marked as a duplicate of this bug. ***
*** Bug 124428 has been marked as a duplicate of this bug. ***
*** Bug 124779 has been marked as a duplicate of this bug. ***
still confirmed in version 6.3.3.2.0+
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
Still happening on Version: 6.5.0.0.alpha0+ Build ID: 5030be4e85179147476b1e441eb618fb6ed58235 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-11-28_20:14:48 Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US Calc: threaded
As noted in Comment #8, when non-focused table is selected, all cells are selected with it. Then Del and Ctrl-X work identically and delete cell contents instead of the table. Using workaround in Comment #12 (entering any cell for editing, then clicking on the edge of the table) the table frame can be selected; then both Del and Ctrl-X remove table from the slide (Ctrl-X retains it in clipboard). Both behaviours are confirmed on 64-bit development build from current master, on Windows 10 x64: --- Version: 6.5.0.0.alpha0+ (x64) Build ID: a70c83f5881ec11def660a6158e04d9ec47207ef CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL --- According to Bug 100772, "Delete Table" context menu is on its way, but stuck somewhere in UNO development. When it is enabled, it will be the first step to sort out the confusion. However, some usability changes would also help; while using tables in Impress, I found this issue confusing to no end. I would propose following solution variants: a) assign Del key to Delete Table action even when cells (and not just the frame) are selected; or b) make single-click on the edge of fully-selected table select (or toggle selection of) only the frame. Currently, if all cells are selected, single-click on the edge does nothing, and double-click unselects/ removes focus from the table.
(In reply to Stepas Toliautas from comment #24) > According to Bug 100772, "Delete Table" context menu is on its way, but > stuck somewhere in UNO development. When it is enabled, it will be the first > step to sort out the confusion. > However, some usability changes would also help; while using tables in > Impress, I found this issue confusing to no end. I would propose following > solution variants: > a) assign Del key to Delete Table action even when cells (and not just the > frame) are selected; or > b) make single-click on the edge of fully-selected table select (or toggle > selection of) only the frame. Currently, if all cells are selected, > single-click on the edge does nothing, and double-click unselects/ removes > focus from the table. UX: what do you think?
> a) assign Del key to Delete Table action even when cells (and not just the > frame) are selected; or > b) make single-click on the edge of fully-selected table select (or toggle > selection of) only the frame. Currently, if all cells are selected, > single-click on the edge does nothing, and double-click unselects/ removes > focus from the table. I'm leaning towards b) or some similar operation myself because Del and Ctrl-X doing the same thing (deleting selected data) is common and consistent usage in today's application UI. It's just that selecting the table instead of its contents is difficult here. IIRC, tables in Writer are cleared if their content is selected, but can be deleted either by right-clicking -> Delete Table or by selecting them as text element (that is, putting cursor in a line before table, holding Shift and pressing right or down arrow until the table and its surroundings are selected) and then pressing Del. In Impress, there are no "surroundings", so no second choice.
(In reply to Stepas Toliautas from comment #24) > a) assign Del key to Delete Table action even when cells (and not just the > frame) are selected; or If you want to change the cell content, Delete might become handy ;-). So no to delete the table from anywhere else but the frame. (In reply to Stepas Toliautas from comment #24) > b) make single-click on the edge of fully-selected table select (or toggle > selection of) only the frame. The user expects operation on the whole object (cut or delete) without dependency to any selection state. Don't get the point with double-click here.
(In reply to Heiko Tietze from comment #27) > The user expects operation on the whole object (cut or delete) without > dependency to any selection state. Well, that cannot be true, otherwise one of the following would be impossible: a) selecting and cutting/ deleting content of all cells at once, or b) selecting and cutting/ deleting the table itself. So there has to be a difference between table and content selection states. As a matter of fact, Writer tables are about to adopt (in 6.4) the fix provided in tdf#118311 (Ctrl-X cuts table object, while Ctrl-C + Del simulates cutting table content). Are LO modules supposed to be consistent w.r.t. each other?
(In reply to Stepas Toliautas from comment #28) > Are LO modules supposed to be consistent w.r.t. each other? Sure, consistency is paramount. But tables are not placed inside a frame in Writer. And my take in bug 127759 comment 15 was to have additional <tr> marks. Current state is that ctrl+x cuts the fully-selected table but not delete.
(In reply to Stepas Toliautas from comment #28) > (In reply to Heiko Tietze from comment #27) > > The user expects operation on the whole object (cut or delete) without > > dependency to any selection state. > > Well, that cannot be true It is empirically true. That is, when a user clicks the frame of a table, or another object, they expect an operation on the entire object. At least, many, and I'd say almost all, users expect this. > otherwise one of the following would be > impossible: a) selecting and cutting/ deleting content of all cells at once, A user expects that clicking-down in some corner cell, then dragging along the diagonal, would eventually select all cells; and a minor expectation is that, at that point, a Delete keypress would clear cenn contents, not the entire table. In other words - users expect a single-click on the frame to do something different than selecting all cells. > or b) selecting and cutting/ deleting the table itself. So there has to be a > difference between table and content selection states. Indeed. But single-click on the frame must effect the former, not the latter.
(In reply to Eyal Rozenberg from comment #30) > It is empirically true. That is, when a user clicks the frame of a table, or > another object, they expect an operation on the entire object. At least, > many, and I'd say almost all, users expect this. All of the statements in your comment are correct (IMHO), but you seem to be replying to a different argument, since the wording was "The user expects operation on the whole object (cut or delete) without dependency to any selection state". While you rightfully point out that there are (at least) two different selection states. Also, fix for Writer tables does not follow the cut/ delete consistency, which I'm actually not happy about: there should be a difference between table selection and all all-cell selection, and cut/ delete should be symmetric within these selection modes. Going back to Impress, there are two current bugs that make practical use difficult regardless of UI choices: a) it's hard to select Impress table as object (since single-click from outside selects all cells as well) and b) during clicking-and-dragging of cells from within, any contact with table frame -- as well as simply selecting all cells -- automatically selects the frame as well. In effect, many new users only ever see "everything selected" mode, which does not even behave as expected. So, I guess... let's fix Impress table selection first? (5 years and counting)
*** Bug 137462 has been marked as a duplicate of this bug. ***
Two proposals: 1) Click on the edge always Selects table (Which can be then deleted) If one wants to select all cells, there would be two options: a) Drag the mouse over cells to be selected b) Place cursor in table cell and press Ctrl+A ("Select all" command) In both cases (a,b) the cells would be selected and pressing Del would delete cells's contents but keep Table in place. 2) First click would select table cells (as it is now) and delete would remove contents only (keep table), but once empty Table is selected again, "Del" would delete the table (so Del on table with all cells selected would delete cell's content; while the same operation but with cells already empty would delete table). I would prefer "1" as seems more intuitive to me (I expect "Del" to delete whole object surrounded by Edit frame).
*** Bug 141165 has been marked as a duplicate of this bug. ***
One should focus on the positive side: There is a "context menu on its way since two years" for a seven year old bug that has been reopened multiple times by various people. That's just the way it is for all the bugs of the cinderella of the LO suite and that's the reason why working with Impress as much fun as a root canal operation.
The commit bibisected in comment #8 was reverted by: https://git.libreoffice.org/core/+/3ba86ee82a2d0c2d8cac3c7ee83e2c5f0a3c291e%5E%21/#F1 author merttumer <mert.tumer@collabora.com> Thu Apr 15 11:21:01 2021 +0300 committer Mert Tumer <mert.tumer@collabora.com> Mon May 03 06:51:22 2021 +0200 Fix ESC key selects all the cells of the table object After this, selecting all the table (Table toolbar - right click - Select Table button) and pressing Del still did not work, but steps from comment #1 did. Even this manually select the table and Del started to work in 7.2, since https://git.libreoffice.org/core/+/13f981e262b04f40c377d0e4fff717b57855d8a3 author merttumer <mert.tumer@collabora.com> Mon May 17 05:52:01 2021 +0300 committer Mert Tumer <mert.tumer@collabora.com> Fri Jun 04 10:39:24 2021 +0200 Implemented Delete key deletes the table when all the cells are selected Huge thanks for fixing this one Mert!