Bug 86143 - Dragging merged from the corner puts it in a single cell
Summary: Dragging merged from the corner puts it in a single cell
Status: RESOLVED DUPLICATE of bug 43958
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3.3.1 rc
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Attila Szűcs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Calc-Merge-Split
  Show dependency treegraph
 
Reported: 2014-11-11 10:26 UTC by Ajinkya Dahale
Modified: 2020-09-30 08:33 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of current behavior (1.67 MB, image/png)
2019-10-18 00:13 UTC, Franklin Weng
Details
Screencast with Excel 2016 (33.67 KB, image/gif)
2019-10-25 08:16 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ajinkya Dahale 2014-11-11 10:26:25 UTC

    
Comment 1 Ajinkya Dahale 2014-11-11 10:53:11 UTC
Steps to reproduce:
1) Merge a bunch of cells and select it.
2) Try to drag from the bottom right corner along the row or column.

Current result:
As marker is pulled along, say, the row, only the topmost cell gets filled appropriately, and the filling continues in single column increments, regardless of the number of columns in the merged cell.

Expected result:
As the marker is pulled along, say, the row, the same number of cells along the column and row get merged and each newly made merged cell is filled accordingly.

At least the cells should be merged accordingly along the perpendicular direction.
Comment 2 Buovjaga 2014-11-16 19:23:22 UTC
Ok I get what you mean.
To have the selection behave like you want, click and drag from inside the merged cell a little bit outside of it and then back again. Now the merged cell is selected (blue). Now when you drag from the bottom right handle, it selects logically.

I'll set this to NEW and lower severity because a workaround exists.

Win 7 64-bit Version: 4.4.0.0.alpha2+
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08
Comment 3 Ajinkya Dahale 2014-11-18 07:40:33 UTC
(In reply to Beluga from comment #2)
> Ok I get what you mean.
> To have the selection behave like you want, click and drag from inside the
> merged cell a little bit outside of it and then back again. Now the merged
> cell is selected (blue). Now when you drag from the bottom right handle, it
> selects logically.

The workaround you provided does copy all the cells contained within the merged cell, treating it as an array of cells. However, it does not merge the cells.

This result is based on LibreOffice 4.3.3.2 430m0(Build:2) on Ubuntu 14.04.1 LTS.
Comment 4 m_a_riosv 2014-12-21 15:14:42 UTC
*** Bug 87529 has been marked as a duplicate of this bug. ***
Comment 5 Buovjaga 2014-12-30 15:32:58 UTC
Herman: please don't change the version field, it tells us the earliest version the bug occurs in.
Comment 6 QA Administrators 2016-01-17 20:03:51 UTC Comment hidden (obsolete)
Comment 7 m_a_riosv 2017-02-25 15:36:37 UTC
*** Bug 101229 has been marked as a duplicate of this bug. ***
Comment 8 QA Administrators 2018-06-04 02:34:29 UTC Comment hidden (obsolete)
Comment 9 Franklin Weng 2019-10-18 00:11:40 UTC Comment hidden (obsolete)
Comment 10 Franklin Weng 2019-10-18 00:13:34 UTC
Created attachment 155100 [details]
Screenshot of current behavior

It might be an UX issue?
Comment 11 Franklin Weng 2019-10-18 00:15:06 UTC
Copying a merged cell into another merged cell should be reasonable expectation.  @Heiko, do you think it an UX issue?
Comment 12 karsten.henning 2019-10-19 16:40:27 UTC
I have reproduced the problem with the same version 6.3.3.1 according to instructions both under Linux and under Windows. The behavior was identical and therefore it is not a UX problem.
The expected behavior is to copy a merged cell in any direction with the result that at the target also merged cells are created and counted as one cell. 
This is also the behavior in Excel.
Comment 13 Franklin Weng 2019-10-20 02:01:52 UTC
(In reply to karsten.henning from comment #12)
> I have reproduced the problem with the same version 6.3.3.1 according to
> instructions both under Linux and under Windows. The behavior was identical
> and therefore it is not a UX problem.

The behavior was identical and therefore it is not an UI problem.
What I said UX problem is that, is this behavior intuitive to users?  Is this behavior matching what users naturally expect?

> The expected behavior is to copy a merged cell in any direction with the
> result that at the target also merged cells are created and counted as one
> cell. 
> This is also the behavior in Excel.

Right, so I think it is an UX problem.  Regardless of what behavior Excel has, it is natural for users to expect this way.
Comment 14 Heiko Tietze 2019-10-24 14:13:10 UTC Comment hidden (off-topic)
Comment 15 Heiko Tietze 2019-10-25 08:16:40 UTC
Created attachment 155295 [details]
Screencast with Excel 2016

When I expand merged cells in Excel, the target is always merged too. In Franklin's example it would put 2019/11/1 in C+D. Same issue also happens on copy/paste. So perhaps we should change the summary to "Respect merged cells on copy/paste".
Comment 16 Heiko Tietze 2019-10-25 08:17:25 UTC
Since the issue affects results as shown in the example it's not of low importance.
Comment 17 Xisco Faulí 2019-10-31 14:44:10 UTC
(In reply to Heiko Tietze from comment #16)
> Since the issue affects results as shown in the example it's not of low
> importance.

Let's set it to Normal then, there is a workaround in comment 1
Comment 18 László Németh 2020-09-30 08:33:52 UTC

*** This bug has been marked as a duplicate of bug 43958 ***