Bug 49638 - FORMATTING: Edit Fill Down mishandles merged cells
Summary: FORMATTING: Edit Fill Down mishandles merged cells
Status: RESOLVED DUPLICATE of bug 47778
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Master old -3.6
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Calc-Merge-Split AutoFill
  Show dependency treegraph
 
Reported: 2012-05-08 05:59 UTC by pierre-yves samyn
Modified: 2018-12-24 17:35 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Sample spreadsheet (10.07 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-05-08 05:59 UTC, pierre-yves samyn
Details
Screenshot after Edit Fill Down (5.89 KB, image/png)
2012-05-08 06:01 UTC, pierre-yves samyn
Details
Screenshot after reload (6.10 KB, image/png)
2012-05-08 06:01 UTC, pierre-yves samyn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pierre-yves samyn 2012-05-08 05:59:50 UTC
Created attachment 61223 [details]
Sample spreadsheet

Hello

Problem description: 

Problem occurs if the "source", the selected cell, is actually several merged cells. The "merged format" is not ok after Edit> Fill> Down.

The attached screenshot & workbook explain what happens (easy to reproduce, more difficult to explain...)

Steps to reproduce:

1. open the attached workbook 
2. Select A3:B10
3. Edit> Fill> Down (Ctrl + D)

Expected result:
4 merged cells in A3:B10

Actual result:
The result after filling is "inconsistent" since it is possible to select one line: A6 for example (G6 in the screenshot) then we should be able to click only A5 or A7 and while the selection behaves as for merged cells (black square on 2 col. x 2 lig. cf. G6 in screenshot).

4. Save, Close, Reload

We find consistency: the selection displayed is the actual situation ... which is not good.
The cells have been merged 2 columns x 1 line and a merged cell
is shifted I4 cf. screenshot


Platform :

3.6.0alpha0+ (Build ID: c2003c7) Windows 7 64bits 
This problem does not appear in this version. Also occurs with older versions.

Reproduces (fr-discuss) with LibO 3.5.2 Windows Vista SP2 64 bits

Regards
Pierre-Yves
Comment 1 pierre-yves samyn 2012-05-08 06:01:18 UTC
Created attachment 61224 [details]
Screenshot after Edit Fill Down
Comment 2 pierre-yves samyn 2012-05-08 06:01:54 UTC
Created attachment 61225 [details]
Screenshot after reload
Comment 3 bfoman (inactive) 2012-10-25 10:14:43 UTC
Confirmed with:
LO 3.6.3.1 
Build ID: f8fce0b
Windows 7 Professional SP1 64 bit

NEW as all issues reproduced.
Comment 4 Owen Genat (retired) 2013-11-18 01:52:14 UTC
Update for this bug. Under Ubuntu 10.04 x86_64 running v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a using the example spreadsheet from the description the initial rendering problem shown in the attachment to comment #1 is not visible. Same with new sheets.

The problem will a fill commencing a merged cell does however remain:

- Selecting the merged cell group A3:B4 and using the click-n-drag fill method results in only cells A5:A10 being filled i.e., the A-B cells are not merged as indicated in the G:H "Actual result" example. 

- Selecting cells A5:B5 and using the Edit > Fill > Down (CTRL+D) method results in A5:B5 being coloured yellow but unfilled and unable to be subsequently selected i.e., the content from merged cell group A3:B4 is not copied and clicking on cells A5:B5 results in the selection of A3:B4.

- Selecting multiple rows (e.g., A5:B5 and A6:B6) and using the Edit > Fill > Down (CTRL+D) method results in no change / action.

Seems somewhat related to bug 47778, although that bug deals with the issue of filling *through* a merged cell, rather than using a merge cell as the source.
Comment 5 Owen Genat (retired) 2013-11-18 01:57:47 UTC
(In reply to comment #4)
> Update for this bug. Under Ubuntu 10.04 x86_64 running v4.1.3.2 Build ID:
> 70feb7d99726f064edab4605a8ab840c50ec57a using the example spreadsheet from
> the description the initial rendering problem shown in the attachment to
> comment #1 is not visible. Same with new sheets.

Apologies. This part of my prior comment is not true. This rendering issue *is* still visible when the indicated A3:B10 range is selected. My other comments are accurate, but given this condition, now seem ancillary. Sorry for any confusion.
Comment 6 pierre-yves samyn 2013-11-18 14:19:22 UTC
Hello

(In reply to comment #5)
> Apologies. This part of my prior comment is not true. This rendering issue
> *is* still visible.

Yes I confirm that and also still reproducible with
Version: 4.2.0.0.alpha0+
Build ID: cc2a405915e82c4b332dd25457f76704dc536d7f
TinderBox: Win-x86@39, Branch:master, Time: 2013-10-15_15:51:52

Regards
Pierre-Yves
Comment 7 QA Administrators 2015-04-19 03:20:43 UTC Comment hidden (obsolete)
Comment 8 pierre-yves samyn 2015-04-19 05:57:29 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2016-09-20 09:24:57 UTC Comment hidden (obsolete)
Comment 10 pierre-yves samyn 2016-09-21 06:50:58 UTC Comment hidden (obsolete)
Comment 11 pierre-yves samyn 2016-09-21 06:58:38 UTC
(In reply to pierre-yves samyn from comment #10)
> Still reproduced on windows 7/64 & Version: 5.2.1.2

Of course now the menu is Sheet>Fill Cells>Down

Pierre-Yves
Comment 12 QA Administrators 2018-06-04 02:33:50 UTC Comment hidden (obsolete)
Comment 13 pierre-yves samyn 2018-06-09 06:04:37 UTC
Hi


Still reproduced on windows 7/64:
Version: 6.0.4.2 (x64)
Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
CPU threads: 2; OS: Windows 6.1; UI render: default; 
Locale: fr-FR (fr_FR); Calc: group

Regards
Pierre-Yves
Comment 14 Xavier Van Wijmeersch 2018-06-09 12:16:05 UTC
can also reproduce with linux x86_64

Version: 6.2.0.0.alpha0+
Build ID: 5708534b942c1d0ce384f6a8473da6bb569410e7
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group threaded
Comment 15 Timur 2018-12-24 17:35:25 UTC
Looks like a duplicate of Bug 47778 to me. 
If not, please explain and set back New because it's repro in 6.3+.

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