Bug 131455 - Right arrow causes a large unexpected column jump. ( steps in comment 4 )
Summary: Right arrow causes a large unexpected column jump. ( steps in comment 4 )
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Regressions-1024plus-Columns
  Show dependency treegraph
 
Reported: 2020-03-21 00:38 UTC by Daniel Baran
Modified: 2020-06-03 02:44 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Partially protected ODS workbook with macros. (63.45 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-03-21 00:41 UTC, Daniel Baran
Details
This is the full text of the macro that triggers the issue. (2.46 KB, text/plain)
2020-03-21 02:48 UTC, Daniel Baran
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Baran 2020-03-21 00:38:33 UTC
Description:
In a partially protected sheet, a right arrow causes a large and unexpected column jump
into a protected area of the sheet. This result is virtually indiscernible from the behavior
of Bug 126904. The main difference being that the unexpected behavior does not occur
upon first opening of the sheet, but does occur after execution of a particular macro.
I will describe that step below.

Steps to Reproduce:
1.Open the workbook to Sheet 1 (in TimeSpreader file).
2. Press -  Right Arrow to column "N". Further Right Arrows do nothing (expected).
3. Execute "End of Day" macro, then return to Sheet1.
4. Right Arrows beyond column "N" cause a large jump to column "BM" (unexpected)


Actual Results:
Right Arrows beyond column "N" cause a large jump to column "BM" (unexpected)
after executing the "End of Day" macro. This end result is very much like the previous
Bug 126904.


Expected Results:
Right arrows beyond column "N" should be ignored (i.e. do nothing).



Reproducible: Always


User Profile Reset: No



Additional Info:
The unexpected result occurs in the versions listed below, but NOT in v6.2.8.2

Version: 6.4.2.2 (x64)
Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

Version: 6.4.2.2
Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3
CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
 
Version: 7.0.0.0.alpha0+ (x64)
Build ID: c63148ba139bd6b9ae7a0f9e24e51f29e5370963
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 1 Daniel Baran 2020-03-21 00:41:33 UTC
Created attachment 158842 [details]
Partially protected ODS workbook with macros.

This file can demonstrate the bug per the "steps to reproduce" provided.
Comment 2 m.a.riosv 2020-03-21 02:16:56 UTC
It's your macro and protected, please test in the macro when the modification happens, and right places to find help:

https://ask.libreoffice.org/en/questions/
https://ask.libreoffice.org/es/questions/
Comment 3 Daniel Baran 2020-03-21 02:48:36 UTC
Created attachment 158843 [details]
This is the full text of the macro that triggers the issue.

This file is the full text of the macro that triggers the issue.
I hope it will be useful in diagnosing the problem.
While it seems to have been suggested that the macro is at fault,
this exact macro works in LO version 6.2.8.2 and earlier without causing the problem.
If it seems likely that I will have to reconstruct and test numerous macros every time there is a new LO release, I hope someone will at least acknowledge that so that I can decide
whether or not it makes sense to continue investing time in this.
Comment 4 Daniel Baran 2020-03-21 15:46:03 UTC
Here is a way to trigger the unexpected behavior without using any macros whatsoever:

1. Open the workbook.
2. Select Sheet2.
3. Right-Click on the Row 9 header and Delete the row.
      (Rows below 7 are not protected and intentionally deletable)
4. Return to Sheet1 - Right Arrow beyond Column "N" causes jump to "BM".
Comment 5 Daniel Baran 2020-03-21 20:37:32 UTC
Also:
I find the tone and content of Comment 2 to be needlessly glib, dimissive and inappropriate.
Comment 6 Andreas Heinisch 2020-03-25 08:33:59 UTC
I can confirm the behaviour of Comment 5, but is this a bug? LO jumps to the first non protected cell in that line, which is BM. If you protect the whole row then no jump occurs.
Comment 7 Xisco Faulí 2020-03-25 11:54:38 UTC
(In reply to Daniel Baran from comment #4)
> Here is a way to trigger the unexpected behavior without using any macros
> whatsoever:
> 
> 1. Open the workbook.
> 2. Select Sheet2.
> 3. Right-Click on the Row 9 header and Delete the row.
>       (Rows below 7 are not protected and intentionally deletable)
> 4. Return to Sheet1 - Right Arrow beyond Column "N" causes jump to "BM".

Reproduced in

Version: 7.0.0.0.alpha0+
Build ID: 9163755e9f64a0b1dd5f2090e0702c19e31c12c9
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 8 Xisco Faulí 2020-03-25 11:59:23 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=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.

Bisected with: bibisect-linux64-6.3

Adding Cc: to Noel Grandin
Comment 9 Euler German 2020-05-16 20:13:58 UTC
Greetings,

I've been following this bug since 126904. As a matter of fact I first reported this as 127246, lately merged to the already assigned 126904 by Daniel Baran. Not far from now I got a mail saying the bug was sorted out and the fix would be available in a developing alpha version. I`m afraid the bug still there.

I had one of my spreadsheets installed in a Linux Mint machine of a friend and the problem appeared there. He was using the latest stable version of LibreOffice (6.4.3). I then copied my spreadsheets to my own Linux machine that had an older version (6.3.0) and the same bug. I tried to get it updated to the last developing versions so I find one without the problem. No joy. :(

From the version 6.4.4 to the latest 7.0.0 alpha-1, all of them had the bug, so I had to uninstall them and get version 6.2.8 from the archives to have a working set of LibreOffice for Linux as I have for Windows 7.

I'm not sure if I send a sample to you on the bug 127246 thread, but I'm sure those sent by Daniel Baran should suffice. Hope you get it sorted soon.

Thanks for your efforts.