Bug 163278 - EDITING: Odd behaviour when inserting shapes, callouts, arrows, drawings, text boxes, etc. when cell height greater than 80 inches
Summary: EDITING: Odd behaviour when inserting shapes, callouts, arrows, drawings, tex...
Status: RESOLVED DUPLICATE of bug 139722
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.3.2.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-03 21:28 UTC by wardrich
Modified: 2024-10-05 00:34 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
This is one such file in the "broken" state (7.11 KB, application/vnd.oasis.opendocument.spreadsheet)
2024-10-03 21:34 UTC, wardrich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description wardrich 2024-10-03 21:28:34 UTC
Description:
If you have some cells set with a background colour and border, then set all cells to any size greater than 80", you will find that most insertable things won't show.  I'm not sure if "object" is the correct term to use to refer to these, but I will be doing so throughout the report.  

I have been able to consistantly reproduce the error across multiple instances, and with the following:

- Most of the shape options
- Images
- Text Boxes
- Drawings
- Lines
- Callouts

Fontwork text appears to work, but exhibits the following problems:

- If you attempt to drag the object, it will immediately jump to the top of the sheet and only allow horizontal movement.

- If you try to resize the object:
-- Horizontal re-sizing works fine
-- Dragging from any of the three top handles looks like it does nothing, until you let go.  It will then seemingly snap to either a 1x height or 0x height (I can't tell) object.  It will give you 3 horizontal handles, if you click off the object it will become totally invisible and seemingly imposslbe to select again.
-- Dragging from the bottom corner handles will cause the image to go very thin and stretch up beyond the top cell of the sheet.
-- Skewing appears to behave properly.

Worth noting that if you have the Fontwork object "snapped" to the top of your sheet and try to resize from the bottom handles, it will snap the object up even higher up, just outside of the top of your sheet.  You may be able to see some bottoms of letters depending on the style and word.

If you select all cells and shrink them back down to 80" or smaller, your ability to insert shapes etc. will work as normal, however the other things you tried to add will still be missing.



This is the first bug report I've made, I hope I've done an okay job trying to explain the problem

Steps to Reproduce:
1. Select all cells
2. Drag height to anything over 80 inches
3. Try to insert a 5-point star (or any of the afforementioned shapes/items)

Actual Results:
Nothing will appear, however the undo step will show the relevant undo action for the thing you tried too add

Expected Results:
The shape/item would have appeared on the sheet and been accurately sizable/positionable 


Reproducible: Always


User Profile Reset: Yes

Additional Info:
I was able to narrow the issue down to 81" being where the problem seems to start.  

I tried all sorts of column widths and was unable to replicate the issue, so it seems to be tied to the row height.

I also tried expanding 10 rows to various >80" heights and things were working properly in the re-sized space, the untouched space, and bridging across both sections.

I'm not too sure what the minimum number of rows are where this starts to happen.

I tested this on a laptop running Arch Linux, and LibreOffice version 24.8.2.1 (x86_64) and was NOT able to replicate the issue.
Comment 1 wardrich 2024-10-03 21:31:07 UTC
When I first started writing this report, I thought the background & border were required to replicate the issue, howeve, they are not.  There was one instance where I was able to get it working fine but it broke as soon as I added the background & border, however I attempted again without them and it was broken on the first try.

It may help cause the issue, but I don't believe it is THE cause of the issue.
Comment 2 wardrich 2024-10-03 21:34:00 UTC
Created attachment 196875 [details]
This is one such file in the "broken" state

Attached is a copy of a file in the broken state.
Comment 3 wardrich 2024-10-03 21:37:50 UTC
(In reply to wardrich from comment #2)
> Created attachment 196875 [details]
> This is one such file in the "broken" state
> 
> Attached is a copy of a file in the broken state.

Opened on my Linux computer, worked totally fine there.

Closed LibreOffice Calc on my Windows PC, downloaded the attached file and tested, same issue again.  So it isn't something breaking in the program during the creation of the file or anything in that process.
Comment 4 Regina Henschel 2024-10-04 16:46:21 UTC
I think, your problems have the same reason as described in bug 139722.

The difference between Linux and Windows might be how the internally used datatype "long" is interpreted on Linux and Windows.

Workaround: Only set those rows to the requested height that are actually used in your spreadsheet. In addition you can set the other rows to a height that is smaller than the default height. I doubt, that you are actually using 1 Million rows. If you really need 1 Million rows, a spreadsheet is the wrong tool.
Comment 5 wardrich 2024-10-05 00:34:05 UTC
I think you may be right.  My apologies for the duplicate report - I tried searching and didn't see anything, so hopefully at the very least this record will serve to help others find the post they're really looking for.

*** This bug has been marked as a duplicate of bug 139722 ***