Download it now!
Bug 78326 - Can't delete a table in Impress/Draw if cells are selected
Summary: Can't delete a table in Impress/Draw if cells are selected
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 90518 107672 113669 123929 124428 124779 (view as bug list)
Depends on:
Blocks: ImpressDraw-Tables
  Show dependency treegraph
 
Reported: 2014-05-06 08:05 UTC by naga44
Modified: 2020-01-08 17:43 UTC (History)
19 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description naga44 2014-05-06 08:05:53 UTC
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 !
Comment 1 Maxim Monastirsky 2014-05-06 15:35:24 UTC
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.
Comment 2 daviding 2014-10-12 02:38:52 UTC
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.
Comment 3 QA Administrators 2015-10-14 19:56:14 UTC Comment hidden (obsolete)
Comment 4 Buovjaga 2015-12-02 10:09:49 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2017-01-03 19:39:39 UTC Comment hidden (obsolete)
Comment 6 daviding 2017-01-04 03:31:58 UTC
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
Comment 7 Buovjaga 2017-01-04 08:34:34 UTC
(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)
Comment 8 Aron Budea 2017-04-16 18:15:55 UTC
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>
Comment 9 Aron Budea 2017-04-16 19:34:29 UTC
Affects Windows builds as well, setting OS to All.
Comment 10 Jacques Guilleron 2017-11-06 11:33:58 UTC
*** Bug 113669 has been marked as a duplicate of this bug. ***
Comment 11 Aron Budea 2018-02-01 00:57:16 UTC
*** Bug 90518 has been marked as a duplicate of this bug. ***
Comment 12 Regina Henschel 2018-02-01 01:21:04 UTC
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.
Comment 13 Buovjaga 2018-02-01 07:17:35 UTC
*** Bug 107672 has been marked as a duplicate of this bug. ***
Comment 14 QA Administrators 2019-02-02 03:44:14 UTC Comment hidden (obsolete)
Comment 15 naga44 2019-02-02 04:00:04 UTC Comment hidden (obsolete)
Comment 16 naga44 2019-02-02 04:00:30 UTC Comment hidden (obsolete)
Comment 17 Eyal Rozenberg 2019-02-02 10:11:22 UTC
This bug will not just go away...

still manifests with LO 6.2 RC2, i.e.:

Version: 6.2.0.2
Build ID: 2ce5217b30a543f7666022df50f0562f82be0cff
Comment 18 Buovjaga 2019-03-30 11:25:17 UTC
*** Bug 123929 has been marked as a duplicate of this bug. ***
Comment 19 Buovjaga 2019-03-30 11:26:04 UTC
*** Bug 124428 has been marked as a duplicate of this bug. ***
Comment 20 Buovjaga 2019-04-18 16:59:12 UTC
*** Bug 124779 has been marked as a duplicate of this bug. ***
Comment 21 Oliver Grimm 2019-11-27 23:04:38 UTC
still confirmed in version 6.3.3.2.0+
Comment 22 Xisco Faulí 2019-12-02 13:18:36 UTC
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
Comment 23 BogdanB 2019-12-08 08:16:47 UTC
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
Comment 24 Stepas Toliautas 2019-12-19 11:50:49 UTC
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.
Comment 25 Buovjaga 2019-12-19 12:05:52 UTC
(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?
Comment 26 Stepas Toliautas 2019-12-19 14:21:22 UTC
> 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.
Comment 27 Heiko Tietze 2020-01-08 15:35:24 UTC
(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.
Comment 28 Stepas Toliautas 2020-01-08 16:00:28 UTC
(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?
Comment 29 Heiko Tietze 2020-01-08 16:24:37 UTC
(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.
Comment 30 Eyal Rozenberg 2020-01-08 17:03:38 UTC
(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.
Comment 31 Stepas Toliautas 2020-01-08 17:43:18 UTC
(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)