Description: Doesn't work simple pasting spreadsheet from Excel 2010 in to document Writer Steps to Reproduce: 1. Open file Excel 2010 from attach 2. Select range A1:B6 3. Copy it in to clipboard (Ctrl+C) 4. Open new Writer document 5. Try paste your copied range in to document Writer, uses simple "Paste" 6. It doesn't work. 7. But: 7.1 If you use command Paste only text -> it works fine 7.2 If you close Excel before pasting in to Writer, then simple pasting works fine Actual Results: Command "Paste" doesn't work for this case Expected Results: Command "Paste" always works fine Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36
Created attachment 139720 [details] Example of spreadsheet from Excel 2010
Thank you for reporting the bug. I can confirm that the bug is present in Version: 6.0.1.1 (x64) Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
We cannot confirm until it's clear what's going on. attachment 139720 [details] says "Example of spreadsheet from Excel 2010" but Excel says "file is corrupt". When attaching file, please specify how it was created. Also, did you search before reporting? And finally, always test with master before confirming. I could paste.
(In reply to Timur from comment #3) > We cannot confirm until it's clear what's going on. > attachment 139720 [details] says "Example of spreadsheet from Excel 2010" > but Excel says "file is corrupt". When attaching file, please specify how it > was created. > Also, did you search before reporting? > And finally, always test with master before confirming. I could paste. Who are "we"? File from attach downloads correctly and opens, i checked it I searched in BZ And finally, i found a bug in to release 6.0. Why must i test it in to master?! And finally №2 - why did you delete Mike from CC?
Reproducible with Excel 2016 and LO Version: 6.1.0.0.alpha0+ (x64) Build ID: 2a7057250c8f73fdfb4c65a7525d17e9770459df CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: ru-RU (ru_RU); Calc: CL Opening the attachment, or creating a new spreadsheet, and copying some range to clipboard, then pasting to Writer (Ctrl+V; or using main area of Paste toolbar button), nothing gets inserted. If you use a special options in the Paste button drop-down, then it pastes fine, *except* for the "Bitmap" option - which behaves the same as the main entry. If Excel is closed, then majority of special formats disappear (bitmap among them), and paste works OK. The questions are: 1. Why Writer chooses Bitmap by default (which it apparently does, while it has RTF, HTML, etc.) 2. Is this a regression?
i checked it in to LO 5.2.7.2 on Windows. Same behavior.
NOT reproducible using Version 4.0.0.3 (Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89) In it, looks like "HTML format without comments" is used. NOT reproducible (i.e., it pastes using Ctrl+V) using Version: 4.3.0.4 Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0 In it, apparently "GDI metafile" is pasted. Reproducible using Version: 4.4.0.1 Build ID: 1ba9640ddd424f1f535c75bf2b86703770b8cf6f Locale: ru_RU Also worth noting that *even in versions where it pastes OK*, the manually selected Bitmap clipboard format doesn't paste anything; so the change is in chosen format, not in code that handles that non-working Bitmap format.
/cygdrive/d/sources/bibisect-win32-4.4 $ git bisect log # bad: [489ffd1df414698b6cea9ab03bf6f663b8b5af7e] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2 # good: [8aa9fc9a0c92172593d6cd97662116a965db229d] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474 git bisect start 'latest' 'oldest' # bad: [897913acd244cb6a5d2f4c2da1d625d9b978edb6] source-hash-ac57362b23859591c088e36b7218f4a606dcf3bb git bisect bad 897913acd244cb6a5d2f4c2da1d625d9b978edb6 # bad: [897913acd244cb6a5d2f4c2da1d625d9b978edb6] source-hash-ac57362b23859591c088e36b7218f4a606dcf3bb git bisect bad 897913acd244cb6a5d2f4c2da1d625d9b978edb6 # good: [dc97f44745f96315fb6c5480705bb5d595d39c6c] source-hash-01c8962f281887db59e581906b89d027a994b52a git bisect good dc97f44745f96315fb6c5480705bb5d595d39c6c # good: [dc97f44745f96315fb6c5480705bb5d595d39c6c] source-hash-01c8962f281887db59e581906b89d027a994b52a git bisect good dc97f44745f96315fb6c5480705bb5d595d39c6c # good: [0f9d4de0b2616aa5646b545363585487f563e77e] source-hash-de024170a51b993109f27469ae869fc67548fc63 git bisect good 0f9d4de0b2616aa5646b545363585487f563e77e # bad: [45f072f6b01592dc50a570fd4a710cab4db81519] source-hash-e93bba26ddd8edbcc2852babc6b758ccd1ae39cc git bisect bad 45f072f6b01592dc50a570fd4a710cab4db81519 # bad: [4d6ebc085a5ebcce788da98b34854f56eceb91ab] source-hash-a33f9d080be4a51e816b25f94d19f591b2d9b75d git bisect bad 4d6ebc085a5ebcce788da98b34854f56eceb91ab # good: [0625f8086f430c50225071a7f084c72fdcab2659] source-hash-020e283970783d53f0c8a4b88ff7ae79f6f81618 git bisect good 0625f8086f430c50225071a7f084c72fdcab2659 # bad: [f80e2da7179da2758f6b06702930a8ffd237657a] source-hash-91cc314576f03bdca1a2d14e2306401759bc206e git bisect bad f80e2da7179da2758f6b06702930a8ffd237657a # bad: [39bfc0ba74b837382678adc423f318290b764b7b] source-hash-856bf05a1d8ce48ddc3038197b76123426be0daa git bisect bad 39bfc0ba74b837382678adc423f318290b764b7b # bad: [83105ea15c8179524731df28dc1fb318656c7e10] source-hash-eacd4c044f2bdec41b02e3832772c65327e5be57 git bisect bad 83105ea15c8179524731df28dc1fb318656c7e10 # good: [5d7f031faba48e9269b1175a7d8ea44ca8f525f9] source-hash-7627008b0671f16cf84a3f552e3316ab8d803ebb git bisect good 5d7f031faba48e9269b1175a7d8ea44ca8f525f9 # first bad commit: [83105ea15c8179524731df28dc1fb318656c7e10] source-hash-eacd4c044f2bdec41b02e3832772c65327e5be57 The regression is in the commit range 7627008b0671f16cf84a3f552e3316ab8d803ebb..eacd4c044f2bdec41b02e3832772c65327e5be57. Suspect commit is https://cgit.freedesktop.org/libreoffice/core/commit/?id=a96a7ce51aa98fb9ee97ea3803e2b7e648611008 author Andrzej Hunt <andrzej.hunt@collabora.com> 2014-08-05 19:15:14 +0200 committer Andrzej Hunt <andrzej.hunt@collabora.com> 2014-08-05 19:22:57 +0200 commit a96a7ce51aa98fb9ee97ea3803e2b7e648611008 tree 7734bd7024d2e964e178381efb836a62f0c9d142 parent 459603e36a03e91310c236555f80ae612f02d6b2 fdo#81835 Don't prefer GDI Metafiles to RTF/HTML
I can still reproduce this, I plan to take a look.
(In reply to Miklos Vajna from comment #9) > I can still reproduce this, I plan to take a look. Hi, Miklos, can you change default insert table from Excel/Calc to Writer from insert as OLE to insert as Writer table (a-la "Formatting RTF")?
It's not clear yet, first the regression needs fixing, then the bikesheding can start about defaults. :-)
(In reply to kompilainenn from comment #10) > Hi, Miklos, can you change default insert table from Excel/Calc to Writer > from insert as OLE to insert as Writer table (a-la "Formatting RTF")? Let's track that in bug 116685.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=29d4ecf32392bc94ab0ba9e73fd79eba65c23fdb tdf#115574 sot: fix Excel -> Writer paste It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I must've done sth. wrong when I wasn't able to reproduce. Happens with a number of bugs that we - folks who test then - open. I confirm it's working now.