Description: Merhaba, libre ofis 6. versiyondan (tam sürüm uzatısını hatırlamıyorum) sonra internet exlorer da ki bir siteden içerik kopyaladığımda sadece bir defa yapıştırıyor, sonrasında yeni kopyalamalar yapsamda herhangi bir işlem yapmıyor. kopyalamıyor. Steps to Reproduce: 1.kaldırıp kurdum olmadı. 2.6 nın öncesi versiyonda çalıştı. 3.chrome dan kopyalama yapınca kopyaladı. Actual Results: internet explorer dan içeriği bir kere kopyalıyor, tekrar farklı bir alanı kopyaladığında kopyama yapmıyor. Expected Results: birden fazla explorer da ki sayfalardan kopyalayıp yapıştırmak. ayrı ayrı. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info:
Auto translate Hello, 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.
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.
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.
merhaba, sorunumu anlatabildim mi ? daha detaylı anlatmamı ister misiniz? Teşekkürler.
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.
seems to have started with: https://gerrit.libreoffice.org/plugins/gitiles/core/+/29d4ecf32392bc94ab0ba9e73fd79eba65c23fdb 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 unchanged - 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. /cygdrive/d/sources/bibisect/bibisect-win32-6.1 $ 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 /cygdrive/d/sources/bibisect/bibisect-win32-6.1 $ 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
hasmid, do not wrongly change Version,which says Earliest affected. 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.
(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.
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.
(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
(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.
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: https://gerrit.libreoffice.org/plugins/gitiles/core/+/048e30c1f8231e6cd144a9251061f6fa127b353e 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> /cygdrive/d/sources/bibisect/bibisect-win32-5.4 $ 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 /cygdrive/d/sources/bibisect/bibisect-win32-5.4 $ 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
Thank you Oliver DE. I add another Oliver DE to CC with kind request to check. This is a minor issue but worth fixing.
Dear hasmid, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I'm afraid I need to report that this issue continues to exist or reappeared in Version 7.2.7.2 (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. Michael
It still exists in the below version, tested with copying RTF from MS Edge's IE compatibility mode on Windows 10: Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 Michael