Description: Pasting unformatted text in a fully selected right table cell pastes in both cells. Right one will include hashtags Steps to Reproduce: 1. Open the attached file 2. Copy Hello World 3. Cursor at in cell B1 4. Shift + arrow left 5. Shift + arrow right 6. CRTL+SHIFT+V -> Paste as unformatted text Actual Results: H#e#l#l#o# #w#o#r#l#d# in the right cell Expected Results: Hello world in the right cell (and no content in left cell, but this is also happening with normal paste Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 6.2.0.0.alpha0+ Build ID: 414ef6cb187dd3bbcc917dbedf3c0c1cc8668f60 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-08-20_22:43:18 Locale: nl-NL (nl_NL); Calc: CL and in 4.0.0.3 but not in LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
Created attachment 144484 [details] Example file
I confirm it with Version: 6.2.0.0.alpha0+ (x64) Build ID: 414ef6cb187dd3bbcc917dbedf3c0c1cc8668f60 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-08-21_00:13:04 Locale: en-US (de_DE); Calc: CL
I confirm it on linux. Version: 6.2.0.0.alpha0+ Build ID: f05b0a6aaf8af5d78f9cad8bb953228cb0ce09f1 CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-08-20_01:57:14 Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
Happening to me too in a new document. 1. New Writer document. 2. Type "abc". 3. Select All. 4. Copy. 5. Create a new two-cell table. 6. Select both cells. 7. Paste Unformatted. One cell will be ok, the other one w#i#l#l# #n#o#t#. Try it on a 10x10 table; you will see different results. It will always be one correct cell and the rest incorrect. Behavior varies depending on what is the first selected column and the direction on which the selection is made. Problem does not occur using normal pasting. Version: 6.1.0.2 (x64) Build ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: group threaded
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Test LO 7.0+ with steps from comment 1 and comment 4, there's change upon Paste as unformatted text: I get "Error reading from the clipboard" but content pasted in left cell, right stays empty. So, different but not OK. That change is bibisected to: 7b4866ade6cc36c2b41113f3329918c2046870ec is the first bad commit commit 7b4866ade6cc36c2b41113f3329918c2046870ec Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Dec 16 16:34:31 2019 +0100 source 46f36451e84b8ba86d8b3a8745ebc79edc05a554 :040000 040000 452122fe85d27e691e671ea936e3a05aa0cf36b4 d8d335a8ae6d8b1896fd2d9e536b25cc0955638a M instdir Previous: commit 7b2418462fa4c73774c9e277c67c85085ccfa568 (HEAD, refs/bisect/good-7b2418462fa4c73774c9e277c67c85085ccfa568) Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Dec 16 16:33:47 2019 +0100 source d1064efc84c151630c0294a92b4caa08be676d8b A single commit: https://gerrit.libreoffice.org/plugins/gitiles/core/+/46f36451e84b8ba86d8b3a8745ebc79edc05a554%5E!/ commit 46f36451e84b8ba86d8b3a8745ebc79edc05a554 [log] author Ashod Nakashian <ashod.nakashian@collabora.co.uk> Wed Jul 10 08:31:39 2019 -0400 committer Michael Meeks <michael.meeks@collabora.com> Mon Dec 16 15:01:19 2019 +0100 tree 45adb86a9a62c6fb6ed49f3afea6fdc3e46a4ceb parent d1064efc84c151630c0294a92b4caa08be676d8b [diff] sw: fail loading when the fallback text detection fails When we document in question fails to match any known type, we try to open as plain text (and convert to a Writer doc). However we should not display non-text when we have failed to detect ascii or unicode contents in the file. This happens with corrupted documents, for example, where we end up displaying non-printable binary data. Change-Id: Iccc158a4cb6051a8b17ba01987a30a9882a27fa9 Reviewed-on: https://gerrit.libreoffice.org/75512 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Jan Holesovsky <kendy@collabora.com> (cherry picked from commit d1f6f27e2a014aa55e2762f1209dc520fb183404) Reviewed-on: https://gerrit.libreoffice.org/78452 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/82099 Tested-by: Jenkins Reviewed-by: Michael Meeks <michael.meeks@collabora.com> CC: ashod.nakashian@collabora.co.uk, kendy@collabora.com Please take a look to this related bug.
As for the first bibisectRequest that Telesto marked from 4.0, it was wrong. Bug is Inherited from OO. With behavior changed in 7.0+.
One cell will be alright, the other one w# I #l#l# #n#o#t#. Give it a shot at a 10x10 table; you will see various outcomes. It will continuously be one right cell and the rest inaccurate. Conduct shifts relying upon what is the primary chosen section and the heading on which the determination is made. The issue doesn't happen to utilize typical gluing. https://dislyke.com/top-100-instagram-hashtags-for-likes-2020/ Adaptation: 6.1.0.2 (x64) Fabricate ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106 Computer processor strings: 4; OS: Windows 10.0; UI render: default; Area: en-US (en_US); Calc: bunch strung
Test LO 7.0+ with ventures from remark 1 and remark 4, there's change upon Paste as unformatted message: I get "Blunder perusing from the clipboard" however content glued in left cell, right stays unfilled. Thus, unique however not OK. That change is bibisected to: 7b4866ade6cc36c2b41113f3329918c2046870ec is the main terrible submit submit 7b4866ade6cc36c2b41113f3329918c2046870ec Creator: Jenkins Build User <tdf@pollux.tdf> Date: Mon Dec 16 16:34:31 2019 +0100 source 46f36451e84b8ba86d8b3a8745ebc79edc05a554 :040000 040000 452122fe85d27e691e671ea936e3a05aa0cf36b4 d8d335a8ae6d8b1896fd2d9e536b25cc0955638a M instdir Past: submit 7b2418462fa4c73774c9e277c67c85085ccfa568 (HEAD, refs/cut up/great 7b2418462fa4c73774c9e277c67c85085ccfa568) Creator: Jenkins Build User <tdf@pollux.tdf> Date: Mon Dec 16 16:33:47 2019 +0100 source d1064efc84c151630c0294a92b4caa08be676d8b A solitary submit: https://dislyke.com/category/hashtags//center/+/46f36451e84b8ba86d8b3a8745ebc79edc05a554%5E!/ commit 46f36451e84b8ba86d8b3a8745ebc79edc05a554 [log] author Ashod Nakashian <ashod.nakashian@collabora.co.uk> Wed Jul 10 08:31:39 2019 - 0400 committer Michael Meeks <michael.meeks@collabora.com> Mon Dec 16 15:01:19 2019 +0100 tree 45adb86a9a62c6fb6ed49f3afea6fdc3e46a4ceb parent d1064efc84c151630c0294a92b4caa08be676d8b [diff] sw: bomb stacking when the backup text recognition fizzles At the point when we report being referred to neglects to match any known sort, we try to open as plain text (and convert to a Writer doc). Anyway we ought not show non-text when we have failed to distinguish ascii or unicode substance in the record. This occurs with undermined reports, for instance, where we wind up showing non-printable double information. Change-Id: Iccc158a4cb6051a8b17ba01987a30a9882a27fa9
Same issue as bug 143138?
Not same for me.
*** Bug 105521 has been marked as a duplicate of this bug. ***
More probable steps from duplicate bug, seen in attachment 130674 [details] Screencast: 1. Open or create file with table 2. Select some text 'AA' and copy it 3. Select table cell B2 to B1 and back until B2 only remains selected. 4. Press CTRL+V 5. See AA also in cell B1 while it should be in B2 only.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0031f34d0ba99de5384e13843e99ffbb01f729d0 tdf#145151 tdf#119540 sw IsTableMode: deselect unselected cell It will be available in 7.5.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.
No intention to backport this. It is extremely dangerous so I'm happy to have as much testing time as possible be applied here. (However, it is also extremely advantageous as it applies to a whole host of situations far above this specific formulation of the bug.) This patch should fix ALL right-to-left-selecting-only-rightmost-cell bugs.
VERIFIED with Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4827d5cb1508f6bca9489e31b877cfff36393c50 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Justin, thanks for fixing it!