Download it now!
Bug 133530 - Context menu Paste disabled in Calc with content on the clipboard
Summary: Context menu Paste disabled in Calc with content on the clipboard
Status: RESOLVED DUPLICATE of bug 116983
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.2.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks:
 
Reported: 2020-05-30 21:14 UTC by Telesto
Modified: 2020-06-10 13:53 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Bibisect log (3.23 KB, text/plain)
2020-05-30 21:15 UTC, Telesto
Details
Bibisect log (3.07 KB, text/plain)
2020-05-31 13:17 UTC, Telesto
Details
Example file (8.21 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-05-31 18:10 UTC, Telesto
Details
Screencast (1.26 MB, video/mp4)
2020-06-01 18:54 UTC, Telesto
Details
Screencast (1.59 MB, video/mp4)
2020-06-01 19:25 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-05-30 21:14:10 UTC
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
Comment 1 Telesto 2020-05-30 21:15:20 UTC
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
Comment 2 Aron Budea 2020-05-31 03:28:59 UTC
(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.
Comment 3 Telesto 2020-05-31 06:23:54 UTC
(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..
Comment 4 Telesto 2020-05-31 13:17:03 UTC
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.
Comment 5 Telesto 2020-05-31 15:36:34 UTC
@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..
Comment 6 Buovjaga 2020-05-31 17:52:26 UTC
1. Why does it have to be LibO 6.0 as the source?
2. Where is the promised attached file and is it necessary?
Comment 7 Telesto 2020-05-31 18:10:50 UTC
Created attachment 161468 [details]
Example file
Comment 8 Telesto 2020-05-31 18:16:23 UTC
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
Comment 9 Telesto 2020-05-31 20:05:37 UTC
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
Comment 10 Telesto 2020-05-31 20:31:58 UTC
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)
Comment 11 Buovjaga 2020-06-01 08:37:28 UTC
(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
Comment 12 Buovjaga 2020-06-01 08:55:14 UTC
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
Comment 13 Telesto 2020-06-01 18:54:09 UTC
Created attachment 161503 [details]
Screencast
Comment 14 Buovjaga 2020-06-01 18:57:36 UTC
(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?
Comment 15 Telesto 2020-06-01 19:25:01 UTC
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
Comment 16 Xisco Faulí 2020-06-04 13:14:12 UTC
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.
Comment 17 Buovjaga 2020-06-04 13:19:21 UTC
(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.
Comment 18 Telesto 2020-06-04 16:30:43 UTC
(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.
Comment 19 Timur 2020-06-10 13:41:21 UTC
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 ***
Comment 20 Timur 2020-06-10 13:53:27 UTC
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.