Description: Clicking into a cell of table will select the full table instead of entering the corresponding cell Steps to Reproduce: 1. Launch Impress 2. Insert a table 3. Deselect the table 4. Click on a cell Actual Results: Full table selection instead of entering the cell Expected Results: Should select a cell Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 6.1.0.0.alpha1+ Build ID: 08441d466dd70c203a519a133aaf1a5997adbbd3 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-05-06_23:59:40 Locale: nl-NL (nl_NL); Calc: CL but not in Version: 6.0.0.0.alpha1+ Build ID: 6eeac3539ea4cac32d126c5e24141f262eb5a4d9 CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Regression introduced by: author Armin Le Grand <Armin.Le.Grand@cib.de (CIB)> 2018-03-28 16:55:19 +0200 committer Armin Le Grand <Armin.Le.Grand@cib.de> 2018-03-29 12:00:23 +0200 commit 7a6b66942260837e2a627b1df2a4fee9af1e3227 (patch) tree 0c9dd67ab9b08e20e7a613c65c6685027d26a346 parent 87b0eb0183e9a379a3e715dcb5de29b29e406686 (diff) Allow URL-Check for non-selected TableText The part to detect a hit on a TableObjectText in Draw/Impress for a non-selected Table was setting the HitType to SdrHitKind::TextEditObj. This prevents the latter happeing check for URL (see below). Not directly setting to TextEditObj is okay, this is determined and set later. I checked various possible changes to keep the behaviour as for 'normal' SdrObjects, so please be careful when doing changes in the HitTest code Bisected with: bibisect-linux64-6.1 Adding Cc: to Armin Le Grand
@Buovjaga There quite bunch new duplicates added to bug 78326. Based on the number of reports and the time frame of the reports (since 6.1) I would assume the belong here instead bug 78326..
(In reply to Telesto from comment #2) > @Buovjaga > There quite bunch new duplicates added to bug 78326. Based on the number of > reports and the time frame of the reports (since 6.1) I would assume the > belong here instead bug 78326.. Ok, feel free to redistribute
Still repro wit Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: 42d2b2d55a27f11153ea1713737d93540a19211d CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
This is marked regression but looks so minor I set Low. Doesn't even look like a bug to me,double click enters cell.
Still present in: Version: 7.2.1.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 16; OS: Linux 5.11; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.2.1~rc2-0ubuntu0.21.04.1~lo1 Calc: threaded (In reply to Timur from comment #5) > This is marked regression but looks so minor I set Low. > Doesn't even look like a bug to me,double click enters cell. Hi Timur. I agree with you that this is not a bug... but IMO the user experience is not great. After using LO for a long time, you get used to it. But I understand why some users are annoyed by this workflow. I would love to be able to click on a cell and be able to directly type in text to the cell. Or to be able to click on a cell and drag the mouse without moving the table (which I very often do).
(In reply to Timur from comment #5) > Doesn't even look like a bug to me,double click enters cell. This has been true for so long it is now the "standard" behaviour and any change would probably trigger "regression" reports. If this where changed then people would complain about finding it hard to select and move the table... I would probably mark this as WONTFIX unless more evidence that the current way is WRONG. Thanks Raphael for a few perspectives that suggest that. It may be rather poor from an accessibility point of view for example.
(In reply to Justin L from comment #7) > This has been true for so long it is now the "standard" behaviour and any > change would probably trigger "regression" reports. If this where changed > then people would complain about finding it hard to select and move the > table... FWIW: well at the point when I posted this, this was surely a regression :-) Obvious the view on this topic might change over time.. I do like this going through UX. The current situation is more a coincidental compared to someone actively evaluation the workflow. Few arguments for me favoring the old state: * You mostly make more changes into a cell compared to 'moving table around'. So the most common activity needs additional click and takes the speed/flow out of it (that's my personal experience) * The repositioning in of a table wasn't that hard in the old state (try older version). And actually you even don't desire to reposition the table most of the time, you want to enter data into cell * PowerPoint has the same workflow as the 'old' Impress state. (Making switching more comfortable & maybe MSO UX design this, this way on purpose?)
Adding UX as wontfix was proposed
Switching into the edit mode works reasonable also compared with other controls. If you have text the cursor changes into the IBeam shape and you edit after a single click, outside it's a NESW shape indicating that you move the object. In the past (testing v5.2) we were not so consistent and treated empty cells as an editable area. I second the WF assessment.
The topic was on the agenda of the design meeting. I see no other opinion than "standard and consistent behavior". Resolving as NAB.