Bug 132187 - For every repeated paste the page count (incl. content) doubles
Summary: For every repeated paste the page count (incl. content) doubles
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All All
: highest critical
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: target:7.0.0 target:6.4.4
Keywords: bibisected, bisected, regression
: 132641 132882 132988 133222 133308 (view as bug list)
Depends on:
Blocks: Paste redlinehide-regressions
  Show dependency treegraph
 
Reported: 2020-04-17 12:01 UTC by Telesto
Modified: 2020-11-19 11:09 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
minimal document (10.33 KB, application/vnd.oasis.opendocument.text)
2020-05-04 13:33 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-04-17 12:01:43 UTC
Description:
Pasting goes extremely fast

Steps to Reproduce:
1. Open attachment 159440 [details]
2. CTRL+A 
3. CTRL+C
4. CTRL+N
5. CTRL+V -> 8x fast (or hold it 5/6 seconds). Look at the number of text/pages pasted.. 

Actual Results:
Really fast pasting.. Seems like some sort of duplication process

Expected Results:
8 pastes?. Not 180 pages in 5 seconds...


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.0.alpha0+ (x64)
Build ID: 4475bcd83aac7e033fc5250f268eb922bd471e7b
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; 
Locale: en-US (nl_NL); UI-Language: en-US
Calc: CL
Comment 1 Xavier Van Wijmeersch 2020-04-17 12:32:22 UTC
Can reproduce with

Version: 7.0.0.0.alpha0+
Build ID: 822da642f1355f8ed1074737560430876d9ac932
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: nl-BE (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 2 Telesto 2020-04-19 12:10:50 UTC
1. Open attachment 155421 [details] 
2. Copy the first table
3. CTRL+N
4. CTRL+V, CTRL+V, CTRL+V,CTRL+V,CTRL+V ,CTRL+V (and take notice of the page count.. with a few steps at 2000 pages
Comment 3 Dieter 2020-04-21 07:31:52 UTC
(In reply to Xavier Van Wijmeersch from comment #1)
> Can reproduce with
> 
> Version: 7.0.0.0.alpha0+
> Build ID: 822da642f1355f8ed1074737560430876d9ac932
> CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; 
> Locale: nl-BE (en_US.UTF-8); UI-Language: en-US
> Calc: threaded

=> NEW

Xavier, if you're able to reproduce a bug, please change status to NEW. Thanks.
Comment 4 Telesto 2020-04-24 20:10:48 UTC
Bisected to:
author	Michael Stahl <Michael.Stahl@cib.de>	2020-04-02 17:18:37 +0200
committer	Michael Stahl <michael.stahl@cib.de>	2020-04-03 17:20:22 +0200
commit 166b5010b402a41b192b1659093a25acf9065fd9 (patch)
tree 58a783dfc1800c604979380c121337ada3e5ad6f
parent 27aa4b16bf704d0246595750daf57b57ff2577b3 (diff)
tdf#130685 sw_redlinehide: fix copying to position following redline
In DocumentContentOperationsManager::CopyWithFlyInFly(), first
CopyNodes() also creates all layout frames, then SaveRedlEndPosForRestore
fixes the end position of all redlines that were moved by CopyNodes()
(they were moved not by changing their position but by inserting
new nodes before their end position).

Of course this means that the layout frames are created with redlines
that have only a temporary end position, and then things go wrong when
the end positions are adjusted, so add something similar to
SwUndoDelete::UndoImpl() to recreate the frames in CopyWithFlyInFly().

This hit the assert:
sw/source/core/text/redlnitr.cxx:94: std::unique_ptr<sw::MergedPara> sw::CheckParaRedlineMerge(SwTextFrame&, SwTextNode&, sw::FrameMode): Assertion `pNode != &rTextNode || &pStart->nNode.GetNode() == &rTextNode' failed.

(regression from ... sw_redlinehide)

https://cgit.freedesktop.org/libreoffice/core/commit/?id=166b5010b402a41b192b1659093a25acf9065fd9
Comment 5 Telesto 2020-04-24 20:11:34 UTC
Adding CC to: Michael Stahl
Comment 6 Telesto 2020-04-25 21:01:37 UTC
Commit 166b5010b402a41b192b1659093a25acf9065fd9 has been backported to 6.4.4 branch. Should be reverted .. or this bug needs a fix soon..
Comment 7 Xisco Faulí 2020-04-27 16:28:23 UTC
(In reply to Telesto from comment #6)
> Commit 166b5010b402a41b192b1659093a25acf9065fd9 has been backported to 6.4.4
> branch. Should be reverted .. or this bug needs a fix soon..

Michael S already assigned it to himself. No need for revert
Comment 8 Telesto 2020-05-03 12:30:54 UTC
Increasing Importance.. This is a quite obvious bug which shouldn't land in LibreOffice 6.4.4
Comment 9 Xisco Faulí 2020-05-04 13:33:28 UTC
Created attachment 160325 [details]
minimal document

Steps to reproduce:
1. Open attachment
2. Copy All
3. Set cursor at the end
4. Paste

-> P2 is duplicated
Comment 10 Michael Stahl (allotropia) 2020-05-04 14:39:00 UTC
fixed on master
Comment 11 Commit Notification 2020-05-04 14:40:10 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/49f26e7dae550aff6ca90b3cda7f89e11ac8cfd4

tdf#132187 sw: fix creation of frames on end node in CopyWithFlyInFly()

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2020-05-04 20:50:16 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/d8bea028093fe3d4c0c0af0afad20c2c03bb9855

tdf#132187 sw: fix creation of frames on end node in CopyWithFlyInFly()

It will be available in 6.4.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Michael Stahl (allotropia) 2020-05-05 08:55:54 UTC
*** Bug 132641 has been marked as a duplicate of this bug. ***
Comment 14 Xisco Faulí 2020-05-05 09:24:50 UTC
Verified in

Version: 7.0.0.0.alpha0+
Build ID: 017f90788c330d2e35a9c05a5...
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

@Michael S. thanks for fixing this issue!
Comment 15 Marco Menardi 2020-05-05 13:24:08 UTC
OMHO should be fixed for the forthcoming 6.4.4 (now rc1) too, not waiting for 6.4.5. As you can see in related bug 132641, it makes Writer almost useless since copy/paste more than one line is so common and is a regression. Myself I'm in troubles using GNU/Linux since last update (Debian Sid), and people using Ubuntu and PPA will be as soon as 6.4.4 is released.
Comment 16 Commit Notification 2020-05-05 15:54:09 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/823a224843ee78a33f2d346c02344a88a77b2758

tdf#132187: sw: Add unittest

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Ming Hua 2020-05-05 20:42:19 UTC
(In reply to Marco Menardi from comment #15)
> OMHO should be fixed for the forthcoming 6.4.4 (now rc1) too, not waiting
> for 6.4.5.
Don't worry, developers are usually well aware of the severity of a bug.  However, backporting work are done on Gerrit, and while some developers write a short note on Bugzilla, others don't.  Backporting are also usually done in the master > 6-4 branch > 6-4-4 branch order.

In this particular case, if you follow one of the commit notices to Gerrit, you'll see from the "cherry picks" section that this fix has already been ported to 6-4-4 branch:
https://gerrit.libreoffice.org/c/core/+/93379
and will be available for 6.4.4 final if everything goes smoothly.
Comment 18 Commit Notification 2020-05-07 07:31:05 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-6-4-4":

https://git.libreoffice.org/core/commit/f29c24a8c23f232d4f59eb35984f6502043f44e5

tdf#132187 sw: fix creation of frames on end node in CopyWithFlyInFly()

It will be available in 6.4.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Commit Notification 2020-05-07 17:04:04 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/d8388a729ff199f8fb98df21eff4e253dfd420d2

tdf#132187: sw: Add unittest

It will be available in 6.4.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 20 Telesto 2020-05-10 16:12:09 UTC
*** Bug 132882 has been marked as a duplicate of this bug. ***
Comment 21 Telesto 2020-05-12 22:33:24 UTC
*** Bug 132988 has been marked as a duplicate of this bug. ***
Comment 22 Telesto 2020-05-21 11:01:49 UTC
*** Bug 133222 has been marked as a duplicate of this bug. ***
Comment 23 Telesto 2020-05-24 07:43:13 UTC
*** Bug 133308 has been marked as a duplicate of this bug. ***