Bug 128029 - Writer: cannot paste RTF more than once if content copied from Internet Explorer (per Comment 2) - other formats paste
Summary: Writer: cannot paste RTF more than once if content copied from Internet Explo...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All Windows (All)
: low minor
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Blocks: RTF-Paste
  Show dependency treegraph
Reported: 2019-10-08 15:19 UTC by hasmid
Modified: 2022-06-27 03:44 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description hasmid 2019-10-08 15:19:06 UTC Comment hidden (obsolete)
Comment 1 Timur 2019-10-08 16:40:23 UTC
Auto translate

libre office After version 6 (I don't remember the full version extension), when I copy content from a site in internet exlorer, it only pastes once, and then doesn't do anything if I make new copies. do not copy.

Steps to Reproduce:
1. I did not remove and install.
2.6 before the version worked.
3.chrome from the copy made.

Actual Results:
copying content from internet explorer once, copying a different area again does not copy.

Expected Results:
copy and paste from multiple explorer pages. separately.
Comment 2 Timur 2019-10-09 13:25:26 UTC
I repro this in LO 6.1. and 6.4+ in Windows only. No repro 6.0. Looks like regression. 
Simple, copy from Internet Explorer and Ctrl+V paste in Writer. First paste works, subsequent not. 
Paste special works for Unformatted Text and HTML, doesn't work for RTF.
Comment 3 Timur 2019-10-09 13:33:44 UTC
I guess we had a change in default paste format in 6.1 (I don't see it in Release Notes, it should be there). So even if it looks so with Ctrl+V, that's not a relevant version. 
What's important is RTF paste special. Works in 5.1, not from 5.4. Still a regression.
Somehow 5.2. and 5.3 lack RTF in Paste Special. I guess fix went awry.
Comment 4 hasmid 2019-10-14 06:14:28 UTC Comment hidden (no-value)
Comment 5 Timur 2019-10-23 11:20:27 UTC
Hi Oliver. I was free to add you to CC since I noticed you do bibisect in Win. 
This is somewhat more complex because two commits should be found, per Comment 3.
Comment 6 Oliver Brinzing 2019-10-26 13:06:11 UTC
seems to have started with:


commit 29d4ecf32392bc94ab0ba9e73fd79eba65c23fdb	[log]
author	Miklos Vajna <vmiklos@collabora.co.uk>	
Thu Mar 29 18:27:13 2018 +0200
committer Miklos Vajna <vmiklos@collabora.co.uk>
Thu Mar 29 19:28:11 2018 +0200
tree a6f88f801f0857063820b7f39a894f10d64fee7b
parent d7a8fa7adf2b2b098a1e38cd7002c928d015b489 [diff]

tdf#115574 sot: fix Excel -> Writer paste

Reported problem is that nothing happens for paste. Direct cause is that
BITMAP is selected as the format, and Excel advertises BITMAP, but when
we try to import that, it fails. There are 3 interesting commits in the
recent history for this topic:

- commit c47db038f98aaf7aec3cbe57c4e5683591afa23e (fdo#52547 SOT: Prefer
  embedding image data to embedding linked image., 2014-02-07) was a
  bugfix due to newer firefox
- commit 538c13f3d1756f2d105115f64ab1bc0b7426eebc (fdo#78801 fdo#52547
  Paste preference is image, then html, then text., 2014-05-28) was a
  regression fix from the previous fix
- commit a96a7ce51aa98fb9ee97ea3803e2b7e648611008 (fdo#81835 Don't
  prefer GDI Metafiles to RTF/HTML, 2014-08-05), was a regression fix
  from the previous fixes

Going back to the original state shows that the Excel -> Writer use-case
used to be RTF.

Restore the old Excel -> Writer (RTF) behavior by:

- going back to the original state, ignoring the enum class conversions
- re-fix fdo#52547: prefer bitmap over html, but leave everything else
- fdo#78801 needs no fix in this case
- fdo#81835 needs no fix in this case
- tdf#115574 selects RTF -> table shows up

After all these complications, the actual fix is surprisingly simple.

$ git bisect good f4cfb9598988ab03f10832b93b89c7249e66f14b is the first bad commit
commit f4cfb9598988ab03f10832b93b89c7249e66f14b
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Sat Mar 31 01:52:10 2018 -0700
    source 29d4ecf32392bc94ab0ba9e73fd79eba65c23fdb
    source 29d4ecf32392bc94ab0ba9e73fd79eba65c23fdb

:040000 040000 ee603774f375ab42a016c45f73a4ba09b65c73c2 e160bac95b7dfbe9bd6371ee64f20be386e64d97 M      instdir

$ git bisect log
# bad: [75d131082ce51ed5a898d97bdc2b7a9fe5ddb340] source 5b3765f4d881e7ddefd0c4aad6886a46f000b4fc
# good: [29d08f54c2f71ffee4fe12dbb24c5f5cbedecfd2] source 6eeac3539ea4cac32d126c5e24141f262eb5a4d9
git bisect start 'master' 'oldest'
# good: [6227e15df9be101688e37cd891817cd858b49e03] source b8b7f8a8f8d97088181d287bb75e74facece16c6
git bisect good 6227e15df9be101688e37cd891817cd858b49e03
# bad: [50b236fe0d359b9d5cc9998d2e72009a90a11d08] source b6025e6cffe2024fefebd161ea739188b4b4fdaf
git bisect bad 50b236fe0d359b9d5cc9998d2e72009a90a11d08
# bad: [f90bd08b3698a799ce313bacc87521d2a5439e45] source 352a99b8cc3ac5b0bb579b9f1dd528711d1cd27a
git bisect bad f90bd08b3698a799ce313bacc87521d2a5439e45
# good: [abb031939baa8841c549f558c340aa298924f773] source 5204a5145d8232ea0650144fb4756c38303ef06e
git bisect good abb031939baa8841c549f558c340aa298924f773
# good: [0fd02cafc7f2ace56c1a880d71442525b316da5e] source 449d416335802b23cf0f8f4725042f92138019cd
git bisect good 0fd02cafc7f2ace56c1a880d71442525b316da5e
# bad: [7d0423fd570da9c907e472319764bae46074a0a9] source 7260cd5381ce5511fd761cd4ca012fcb62fe3c17
git bisect bad 7d0423fd570da9c907e472319764bae46074a0a9
# good: [bf8a0a00955720312c42498e4dfa000d6b99b0a3] source 6a189b2ac72d5fb83199bdb09e41f7d088440cc9
git bisect good bf8a0a00955720312c42498e4dfa000d6b99b0a3
# good: [f53ca9859be58b596f6077408c89ee82d85e9261] source 484fe43b5e9f3696d26b8c0452aab6fd14e10772
git bisect good f53ca9859be58b596f6077408c89ee82d85e9261
# good: [74067fb4f5b23a02e27376f56bb463e111231c73] source f62fcab7f16a2c6abbc37a0d83145e9ded3ad6e3
git bisect good 74067fb4f5b23a02e27376f56bb463e111231c73
# good: [f9a068e6b90ae0bb85c42dfc72f04102ecba9d9b] source 596fd41b9b19e28bab0c84e3821f79cb5d468f24
git bisect good f9a068e6b90ae0bb85c42dfc72f04102ecba9d9b
# good: [64fa0e5b136d8a3e717203844cd0b8a158b3e12a] source da4121ee730a3c4c95bfc717c76ec016e6861737
git bisect good 64fa0e5b136d8a3e717203844cd0b8a158b3e12a
# bad: [f4cfb9598988ab03f10832b93b89c7249e66f14b] source 29d4ecf32392bc94ab0ba9e73fd79eba65c23fdb
git bisect bad f4cfb9598988ab03f10832b93b89c7249e66f14b
# good: [75b3f9f6f949625b5f5ac77bc7bd7df99ceaba5f] source d7a8fa7adf2b2b098a1e38cd7002c928d015b489
git bisect good 75b3f9f6f949625b5f5ac77bc7bd7df99ceaba5f
# first bad commit: [f4cfb9598988ab03f10832b93b89c7249e66f14b] source 29d4ecf32392bc94ab0ba9e73fd79eba65c23fdb
Comment 7 Timur 2019-10-26 18:43:02 UTC Comment hidden (obsolete)
Comment 8 Oliver Brinzing 2019-10-26 19:09:21 UTC
(In reply to Timur from comment #7)
> Oliver, thanks for bibisect. Did you follow default paste or paste RTF? 
> I'm not clear because RTF is from 5.4 and bibisected bug is from 6.1,as
> default paste.

I did bisection with a simple copy from Internet Explorer and Ctrl+V paste in Writer.
Comment 9 Miklos Vajna 2019-10-28 08:33:40 UTC
Are you sure this is a problem on LO's side, rather than IE preserving the RTF clipboard content only for the duration of a single paste? You could check the clipboard content with an external tool. If the RTF is not there on the clipboard after a first paste, this we can't do much.
Comment 10 Oliver Brinzing 2019-10-28 17:25:48 UTC
(In reply to Miklos Vajna from comment #9)
> Are you sure this is a problem on LO's side, rather than IE preserving the
> RTF clipboard content only for the duration of a single paste?

I have done the following procedure:

- copy text from IE
- paste into writer
- copy another text from IE
- paste into writer
Comment 11 Timur 2019-10-30 07:39:27 UTC
(In reply to Oliver Brinzing from comment #8)
> I did bisection with a simple copy from Internet Explorer and Ctrl+V paste
> in Writer.
That seems not to be correct per Comment 3. Likely default paste was changed, but that's not the source of the bug. So bibisect should be done with Pate special - RTF paste in LO 5.4.

(In reply to Miklos Vajna from comment #9)
> Are you sure this is a problem on LO's side, rather than IE preserving the
> RTF clipboard content only for the duration of a single paste? You could
> check the clipboard content with an external tool. If the RTF is not there
> on the clipboard after a first paste, this we can't do much.
Yes, problem is only LO, because clipboard is pasted in other apps. 
Please comment on RTF paste vs. default paste.
Comment 12 Oliver Brinzing 2019-10-31 20:31:06 UTC
I have done the following procedure (bibisect-win32-5.4):

- copy text from IE
- paste special into writer with option "Formatted text [RTF]"
- paste special into writer with option "Formatted text [RTF]"

good: option "Formatted text [RTF]" is not available
bad:  second paste fails (but it's possible to paste into 
                          another writer document)

this seems to have started with:


commit 048e30c1f8231e6cd144a9251061f6fa127b353e	[log]
author	Oliver Specht <oliver.specht@cib.de>
Fri Dec 30 16:47:17 2016 +0100
committer Thorsten Behrens <Thorsten.Behrens@CIB.de>	
Mon Jan 09 00:34:30 2017 +0000
tree 712f9d5cf96f28e01eb980f6314df855b619a7eb
parent 6f0993f2365cd8b6ce53f7a6e705c7fc9bd07ab6 [diff]

tdf#101828 handle rtf/richtext correctly

Change-Id: Id894f62a918bd6e6fa59f8d546307343bf2bd4b0
Reviewed-on: https://gerrit.libreoffice.org/32682
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

$ git bisect bad 6528c37752c3bc07348fa4c9ce435b164977b219 is the first bad commit
commit 6528c37752c3bc07348fa4c9ce435b164977b219
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Fri Feb 10 01:17:04 2017 -0800

    source 048e30c1f8231e6cd144a9251061f6fa127b353e
    source 048e30c1f8231e6cd144a9251061f6fa127b353e

:040000 040000 81ebbd7238bc94112365ed2b7ae3e218e987d32f 0286e403787993ccfd3e5e5a952849aa138488fe M      instdir

$ git bisect log
# bad: [5b9390199c309eb0f061804e45031da85989a8ef] source 534fd9aacd3eea10070a3ee88fc654eb9791aa24
# good: [633bfe84509c1953415e5dd0f564098a16890131] source 4136757b4e51c4e6f7cb4132c95538a7f831ef2c
git bisect start 'master' 'oldest'
# bad: [fb6ad3d5a416ac122c263bb29a8d1b90a0750432] source 055c8cc676921176e2b9df76bd0e09bacab1d80b
git bisect bad fb6ad3d5a416ac122c263bb29a8d1b90a0750432
# bad: [8d77d829aceda0d7a4219eeab8e04d080d1e6d87] source 294c78fd65e62f8061dc2d54a4c8b1baa554e407
git bisect bad 8d77d829aceda0d7a4219eeab8e04d080d1e6d87
# good: [f905124ef123ce2a3193fd3a36127dc9949bae4b] source b36bf9f567f5b531f526dad6776c84e06203396f
git bisect good f905124ef123ce2a3193fd3a36127dc9949bae4b
# bad: [c21428486f696d90201e1bbe67d5dcb84a8a181e] source 10cb59eb914ba722c203242272de244d795a51e8
git bisect bad c21428486f696d90201e1bbe67d5dcb84a8a181e
# bad: [33954ef427779d33d371ef6e3eddb9b3a67daf48] source e316c4f2a40a4a562028f0a66c40321ffdf87378
git bisect bad 33954ef427779d33d371ef6e3eddb9b3a67daf48
# bad: [3b3c13e83572184ca5a89cdb7bf1f12255756e73] source 9c5494bfd781a32882b1cdfa2ab8645df960d85b
git bisect bad 3b3c13e83572184ca5a89cdb7bf1f12255756e73
# good: [7d907424c802e71c8eadb471be14c7af7a3639d9] source 8eb7069941d4888f02975a6aee78328d7236e93a
git bisect good 7d907424c802e71c8eadb471be14c7af7a3639d9
# bad: [e153665385e225311e264dec3cb26f4c012ee8ef] source b6988293c1c27dae8524ee0095d5e4c22ca62553
git bisect bad e153665385e225311e264dec3cb26f4c012ee8ef
# bad: [e9194bd084fc46b9a83eaaaa1df79acd5e2bebe1] source 9f18ee7fd912a6ba600985c5fcbe1e8672dfa993
git bisect bad e9194bd084fc46b9a83eaaaa1df79acd5e2bebe1
# good: [9496ae8c0edad4f95699a89850be72d661bc67ac] source 8320083d2299cc48e3ec92f44e387d69765f431f
git bisect good 9496ae8c0edad4f95699a89850be72d661bc67ac
# good: [e8ef5fcc0cde607c3fa1b9c6d997702cc53849d3] source 6f0993f2365cd8b6ce53f7a6e705c7fc9bd07ab6
git bisect good e8ef5fcc0cde607c3fa1b9c6d997702cc53849d3
# bad: [f44830703f00984f94b1b5f380099abd1face207] source cb8b05eb486d1def2d6332bcad221c7de333d67d
git bisect bad f44830703f00984f94b1b5f380099abd1face207
# bad: [6528c37752c3bc07348fa4c9ce435b164977b219] source 048e30c1f8231e6cd144a9251061f6fa127b353e
git bisect bad 6528c37752c3bc07348fa4c9ce435b164977b219
# first bad commit: [6528c37752c3bc07348fa4c9ce435b164977b219] source 048e30c1f8231e6cd144a9251061f6fa127b353e
Comment 13 Timur 2019-11-01 07:05:08 UTC
Thank you Oliver DE. I add another Oliver DE to CC with kind request to check. 
This is a minor issue but worth fixing.
Comment 14 QA Administrators 2021-11-01 04:15:22 UTC Comment hidden (obsolete, spam)
Comment 15 Michael 2022-06-27 03:44:14 UTC
I'm afraid I need to report that this issue continues to exist or reappeared in Version (x64) Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2. Now you may say this doesn't really matter a lot since MS ceased support for IE as of 
June 15th, but as you can tell from their Internet Explorer 11 desktop app retirement FAQ at <https://techcommunity.microsoft.com/t5/windows-it-pro-blog/internet-explorer-11-desktop-app-retirement-faq/ba-p/2366549> this doesn't mean it may not affect other applications using the MSHTML renderer anymore as does the application I'm supporting. I'm particularly surprised about this since there's no such issue in the Calc and Impress modules which can perfectly deal with repeatedly pasting RTF from the clipboard into the same document over an over again no matter of its contents. If you should need any further details please let me know.