Bug 126905 - Unexpected change in right-click menu and associated command availability.
Summary: Unexpected change in right-click menu and associated command availability.
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Context-Menu Regressions-1024plus-Columns
  Show dependency treegraph
 
Reported: 2019-08-14 02:04 UTC by Daniel Baran
Modified: 2020-06-03 02:44 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Partially protected spreadsheet file with macros. (60.89 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-08-14 02:08 UTC, Daniel Baran
Details
Macro-Enabled Workbook with Partially Protected Sheets (63.33 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-03-01 18:18 UTC, Daniel Baran
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Baran 2019-08-14 02:04:34 UTC
Description:
In LO Calc: Right click on a row number shows expected pull down menu, but only on
the first instance after opening the file. On the second instance several commands are no longer present. For example, "Delete Rows" disappears entirely.
This is a partially protected sheet, but the rows in question should allow deletion.
This problem does not occur in LO v6.2.5.


Steps to Reproduce:
1.Open the file and select "Sheet2".
2.Right-click on row 9 - "Delete Rows" option is seen.
3.Press "Escape" to close the menu, then right-click again - "Delete Rows" option is gone.

Actual Results:
Same as above!

Expected Results:
The "Delete Rows" option should remain present in the menu and functional as a command.



Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Comment 1 Daniel Baran 2019-08-14 02:08:05 UTC
Created attachment 153368 [details]
Partially protected spreadsheet file with macros.

The attached file can demonstrate the behavior described in the bug report.
This file is publicly available on my website, and therefore has no associated privacy concerns.
Comment 2 Jacques Guilleron 2019-08-20 16:01:23 UTC
Hi Daniel,
I reprodce with
LO 6.3.0.0.alpha0+ Build ID: f6a64f9bdce16cc18bb086b0de894fba7e1538c3
CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; 
Locale: fr-FR (fr_FR); UI-Language: en-US Calc: CL
and above versions
But not with
LO 6.2.0.0.alpha0+ Build ID: 1aa37aa6bee19099b57555a6d839992b054aa405
CPU threads: 2; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-09-23_10:17:54
Locale: fr-FR (fr_FR); Calc: threaded
Thank you to have reported it.

Jacques
Comment 3 raal 2019-08-21 06:15:21 UTC
This seems to have begun at the below commit.
Adding Cc: to Noel Grandin ; Could you possibly take a look at this one?
Thanks
 c5a668eb55c0000fe9b5ac32b4bf250325e12a67 is the first bad commit
commit c5a668eb55c0000fe9b5ac32b4bf250325e12a67
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Fri Apr 5 17:05:02 2019 +0200

    source 7282014e362a1529a36c88eb308df8ed359c2cfa

author	Noel Grandin <noel.grandin@collabora.co.uk>	2019-02-01 15:15:16 +0100
committer	Mike Kaganski <mike.kaganski@collabora.com>	2019-04-05 13:43:52 +0200
commit 7282014e362a1529a36c88eb308df8ed359c2cfa (patch)
tree 2776ad9601f494330076ac58c08554e719c6ab3a
parent df30a4515b1303b0891baa53754fa9b3e47e0c02 (diff)
tdf#50916 Makes numbers of columns dynamic.
Comment 4 Daniel Baran 2020-02-02 00:09:58 UTC
Testing on both 6.3.4 and 6.4.0 seems to indicate this issue has been corrected.
(at least in my specific test workbook)
Maybe someone can do additional independent confirmation.
Thanks all,
Daniel Baran
(timespreader.com)
Comment 5 Thomas Lendo 2020-03-01 08:17:30 UTC
Sorry. Due to the macros (?) I can't use mouse right-clicks or left-clicks on row and column headers in the attached file at all.

Version: 6.3.5.2 (x64)
Build-ID: dd0751754f11728f69b42ee2af66670068624673
CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win
Comment 6 Daniel Baran 2020-03-01 18:18:11 UTC
Created attachment 158287 [details]
Macro-Enabled Workbook with Partially Protected Sheets

This is an newer version of the original test case for this bug.
Comment 7 Daniel Baran 2020-03-01 18:19:07 UTC
Thanks Thomas,
Oddly, I do not reproduce the "no clicks" scenario on the same file on my Windows 10 / LO 6.3.5.2.
It's not clear to me if this bug occurs in workbooks other than mine (i.e. your macro suggestion), though it does not occur when in LO 6.2.8.2 with the same macros.
However, I have an updated version of the workbook (attached with this post).
This file does not seem to have issues with deletion of unprotected rows in 6.3.5.2.
I hope you will consider testing this one for comparison (especially regarding the "no-clicks" issue, which seems to be a new problem).
DB
Comment 8 Daniel Baran 2020-03-01 19:04:32 UTC
Thomas, just now realizing that you were probably working on "Sheet 1" of the workbook. That has some protected cells in all the rows, and so the "no-click" issue
you are seeing is expected. The original bug issue applies to "Sheet 2" only, specifically
for Rows 8 and below. Those rows are fully unprotected and should be deletable via a
right-click on the row number. Previously, the right-click "delete row" option was not
showing in the drop-down list. As of now, it appears to be working as expected with the
following circumstances:
Windows 10 Pro, LO 6.3.5.2 (x64),  and the attached workbook (3-1-2020).
It seems like this bug may be resolved if you can confirm per above.
Sorry for any confusion (and this rather long post).
DB
Comment 9 Thomas Lendo 2020-03-01 19:40:26 UTC
Daniel, thanks for the new file and description.

I can reproduce that there are missing some commands in the right-click menu of row 8 and above. I assume this is because of some kind of protection on sheet/cells. Cut and paste are also not working (but deactivated intead of missing).

As you are the bug reporter, it is OK if you close this bug as WORKSFORME if you think that the original problem is not available anymore.