Bug 119540 - Pasting unformatted text in a fully selected right table cell pastes in both cells. Right one will include hashtags
Summary: Pasting unformatted text in a fully selected right table cell pastes in both ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: low minor
Assignee: Not Assigned
Keywords: bibisected, bisected
Depends on:
Blocks: Paste-Special-Unformatted
  Show dependency treegraph
Reported: 2018-08-27 17:03 UTC by Telesto
Modified: 2020-03-10 09:09 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Example file (9.01 KB, application/vnd.oasis.opendocument.text)
2018-08-27 17:03 UTC, Telesto

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-08-27 17:03:23 UTC
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
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

but not in
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
Comment 1 Telesto 2018-08-27 17:03:39 UTC
Created attachment 144484 [details]
Example file
Comment 2 Dieter 2018-08-27 18:41:37 UTC
I confirm it with

Version: (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
Comment 3 BogdanB 2018-08-28 17:38:35 UTC
I confirm it on linux.

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
Comment 4 Octavio Alvarez 2018-09-13 18:47:11 UTC
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: (x64)
Build ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: en-US (en_US); Calc: group threaded
Comment 5 QA Administrators 2019-09-18 02:54:13 UTC Comment hidden (obsolete)
Comment 6 Timur 2020-03-10 08:49:22 UTC
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 sha:46f36451e84b8ba86d8b3a8745ebc79edc05a554

:040000 040000 452122fe85d27e691e671ea936e3a05aa0cf36b4 d8d335a8ae6d8b1896fd2d9e536b25cc0955638a M	instdir

commit 7b2418462fa4c73774c9e277c67c85085ccfa568 (HEAD, refs/bisect/good-7b2418462fa4c73774c9e277c67c85085ccfa568)
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Mon Dec 16 16:33:47 2019 +0100

    source sha:d1064efc84c151630c0294a92b4caa08be676d8b

A single commit:

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.
Comment 7 Timur 2020-03-10 09:08:53 UTC
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+.