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
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
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
(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.
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
Adding CC to: Michael Stahl
Commit 166b5010b402a41b192b1659093a25acf9065fd9 has been backported to 6.4.4 branch. Should be reverted .. or this bug needs a fix soon..
(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
Increasing Importance.. This is a quite obvious bug which shouldn't land in LibreOffice 6.4.4
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
fixed on master
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.
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.
*** Bug 132641 has been marked as a duplicate of this bug. ***
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!
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.
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.
(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.
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.
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.
*** Bug 132882 has been marked as a duplicate of this bug. ***
*** Bug 132988 has been marked as a duplicate of this bug. ***
*** Bug 133222 has been marked as a duplicate of this bug. ***
*** Bug 133308 has been marked as a duplicate of this bug. ***