Description: Paste disabled in Calc with content on the clipboard Steps to Reproduce: 1. Open the attached file in LibreOffice 6.0 2. Open LibreOffice 7.1 3. Copy A1 in 6.0 and paste Right Click paste into 7.1 -> Paste diabled Actual Results: Paste disabled Expected Results: Should be enabled Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: 83c4f86f22dc37269ac6a038fe7de053c42aad6e CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (nl_NL); UI: en-US Calc: CL
Created attachment 161432 [details] Bibisect log Bisected to author Noel Grandin <noel.grandin@collabora.co.uk> 2018-09-13 11:04:18 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> 2018-09-14 09:25:10 +0200 commit 9e0ee17d5059b9a7cf80c8839bb139e1626d0ebb (patch) tree 538962f824a815c75a8dd17ec1cddd6240d9f988 parent 2327d5cfc1cb938b5b7e1c6388d460a1236f4665 (diff) loplugin:useuniqueptr in SwTextFrame::EmptyHeight https://cgit.freedesktop.org/libreoffice/core/commit/?id=9e0ee17d5059b9a7cf80c8839bb139e1626d0ebb
(In reply to Telesto from comment #0) > 1. Open the attached file in LibreOffice 6.0 Please attach the file. (In reply to Telesto from comment #1) > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=9e0ee17d5059b9a7cf80c8839bb139e1626d0ebb Not sure about this result, the commit looks like a simple and straightforward change... but we'll see.
(In reply to Aron Budea from comment #2) > (In reply to Telesto from comment #0) > > 1. Open the attached file in LibreOffice 6.0 > Please attach the file. > > (In reply to Telesto from comment #1) > > https://cgit.freedesktop.org/libreoffice/core/commit/ > > ?id=9e0ee17d5059b9a7cf80c8839bb139e1626d0ebb > Not sure about this result, the commit looks like a simple and > straightforward change... but we'll see. Seeing sw.. so likely wrong indeed..
Created attachment 161457 [details] Bibisect log Bisected to author Caolán McNamara <caolanm@redhat.com> 2018-11-05 12:28:23 +0000 committer Caolán McNamara <caolanm@redhat.com> 2018-11-05 15:20:33 +0100 commit 05652e51420630310606ac29f86e76f3bb148af5 (patch) tree d676ec45f683dd67dc41a560bdf2df72247e5345 parent 3d8c159841bcab7365b2bed3df71ed3c15188312 (diff) ofz#11261 null-deref https://cgit.freedesktop.org/libreoffice/core/commit/?id=05652e51420630310606ac29f86e76f3bb148af5 No warranty's this time on the bibisect.. there is not a 'stable' way to reproduce.. as far I can see.. sometimes.
@Buovjaga, This should be reproducible on Linux too, based on previous reports (who all duped to so old obscure bug).. I attempted 3 bibisects.. two reported here.. always a different outcome.. so could you give it a try? If reproducible of course..
1. Why does it have to be LibO 6.0 as the source? 2. Where is the promised attached file and is it necessary?
Created attachment 161468 [details] Example file
I don't think it must be 6.0 necessarily. It's likely doesn't matter at all; however I did only use 6.0 and 4.4.7.2 ;-).. So can't judge about the other versions. The only real requirement is a second instance.. so the system clipboard is used and not the internal clipboard
Hmmm this starts to look awfully like bug 133533 1. Open example file in 7.1 2. Copy A1 5 times (CTRL+C) 3. Open Right Click paste menu in the other instance -> Working 4. Copy A1 5 itmes (CTRL+C) 5. Open Right Click paste menu in the other instance -> Failing Sometimes this is enough. sometimes you have to do it a little longer.. Pasting other apps is working.. Also seen in 4.4.7.2
Next update.. this is horrible bug .. When copying A1 from example file multiple times with 7.1 -> paste disabled often, even in 3.5.7.2. However copying multiple times from 4.4.7.2 and paste 3.5.7.2 appears to work fine Paste showing disabled started somewhere in 6.2 as far I can tell (using 4.4.7.2 to copy) Note 1: when I mean paste is disabled -> Right Click context menu shows disabled.. the paste is working (CTRL+V).. Not sure if the 'right' content would be pasted or some old history (as copy the same thing over and over) Note 2: 1. Open example file in 7.1 2. Copy A1 5 times (CTRL+C) 3. Open Right Click paste menu in the other instance -> Working 4. Copy A1 5 times (CTRL+C) 5. Open Right Click paste menu in the other instance -> Working 6. Copy A1 5 times (CTRL+C) 7. Open Right Click paste menu in the other instance (not working). At least for 6.2 origin/master & 4.4.7.2 as copy source) It's possible that the problematic commit is affecting the clipboard as a whole (copy & paste)
(In reply to Telesto from comment #10) > Note 2: > 1. Open example file in 7.1 > 2. Copy A1 5 times (CTRL+C) > 3. Open Right Click paste menu in the other instance -> Working > 4. Copy A1 5 times (CTRL+C) > 5. Open Right Click paste menu in the other instance -> Working > 6. Copy A1 5 times (CTRL+C) > 7. Open Right Click paste menu in the other instance (not working). At least > for 6.2 origin/master & 4.4.7.2 as copy source) No problem here Version: 7.0.0.0.alpha1+ (x64) Build ID: 21875558f6c478f07d68ff39e025d7ffd451674f CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded
No problem with this either Version: 7.1.0.0.alpha0+ (x64) Build ID: a0c90f1bccd9b5a349d3199746facab549f27dba CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded
Created attachment 161503 [details] Screencast
(In reply to Telesto from comment #13) > Created attachment 161503 [details] > Screencast Ok, in this video we see you do not use the same version for the test (you use 6.2 and 7.1). Does the same occur, if you purely use 7.1?
Created attachment 161504 [details] Screencast Yes it does.. but this stupid 'disabled' paste is hard to pin down. I really do't see any pattern... Except it does happen.. I enabled the MS Office clipboard sometimes - it appears - to happen more often - with it (screencast is without). It also depends on the build.. I could reproduce it pretty well with 6.2 range.. But it all depends.. 20 misses.. hit.. 20 misses Awfully boring.. As said.. the clipboard is not empty.. so I expect something within the code regulating the context menu.. to set it disabled or enabled.. And based on early observations.. probably very old code
Using the same comment I posted in bug 133533: "What are the chances an end user will use different versions of LibreOffice and copy paste content from one to the other ? Is there any real scenario where having two versions of LibreOffice is required ? I fail to see the point of this bug.
(In reply to Xisco Faulí from comment #16) > Using the same comment I posted in bug 133533: > "What are the chances an end user will use different versions of LibreOffice > and copy paste content from one to the other ? Is there any real scenario > where having two versions of LibreOffice is required ? I fail to see the > point of this bug. Telesto said that the problem also occurs when using instances of the same version.
(In reply to Xisco Faulí from comment #16) > Using the same comment I posted in bug 133533: > "What are the chances an end user will use different versions of LibreOffice > and copy paste content from one to the other ? Is there any real scenario > where having two versions of LibreOffice is required ? I fail to see the > point of this bug. I'm not interested in being able to be paste between a current version and an older versions of LibreOffice or between different instances of LibreOffice. Point is more being able to create circumstances which would explain some of the issues mentioned in dump-yard bug 62196; Where multiple copy/paste errors are added together as duplicate of each other.. [without having proper steps for any case]. (bug 97939) The common part appears to be 'some' failure at system clipboard. However the system clipboard has it's own handling for each OS. So issue of LibO and the Windows clipboard is something else as a Linux paste bug between system clipboard an LibO The current bug can reproduced with two instances of LibreOffice 7.1; however it need to be separate processes. A single process uses the internal LibO clipboard This report attempt to illustrates the problem.. but no, can't be sure if it's the same as reported previously..'paste' being disabled, but shortcut working or not being able to paste at all; bugs reports are quite obscure about that element. And as said bug 62196 is a dump-yard.. Mixing Linux and Windows together. Older/newer issues. However, I'm pretty sure something is not working quite right with copy past using the system clipboard. But it's surely not a straight forward bug.. as does happen on by occurrence in a while. You're surprised.. I did copy it; did I? So you retry and it's back working again.. until.. 30 pastes later.. Or maybe even 150 pastes.. I even consider a group not reporting this because of the unpredictability. And the other half can't proof the issue; running into the insufficient data closings.
Same comment as bug 133533, no point in duplicates an unrealistic usage. Bug 116983 may be the same as bug 57147 but never mind, point is to have realistic reproducible steps and they exist. *** This bug has been marked as a duplicate of bug 116983 ***
Another problem with thoise instances is copying from master to older. Wrong. Must be copied to master. As for bug 62196, please review all duplicates and comment. They mostly have no steps, while bug itself has some steps.