Description: I cannot reproduce this with a complete new document although this document was created yesterday. Something is special. The data is not lost, through completely unaccessible for the enduser (content.xml contains the data). Steps to Reproduce: 1. take the attachment and shrink with the mouse the column B to the right so that it the width 0. 2. try to expand column b again 2.1 works neither using the mouse 2.2 nor the table properties! Actual Results: Column B is "gone" Expected Results: Column B should never been that small that you can access the data Reproducible: Always User Profile Reset: No Additional Info: attached also my resulting odt
Created attachment 197563 [details] Table before shrinking
Created attachment 197564 [details] Table after shrinking As said: this file includes the shrinked column. The data is still available in the xml, but not accessible for the enduser.
(In reply to Dennis Roczek from comment #0) > Steps to Reproduce: > 1. take the attachment and shrink with the mouse the column B to the right > so that it the width 0. I am unable to shrink it to 0. You marked operating system as All. Which OSes do you repro this on? Windows and macOS? Arch Linux 64-bit Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ccb96251ea15c3252010416377dd185205206cbd CPU threads: 8; OS: Linux 6.11; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 12 November 2024 Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9e3803ae438ddcf91ec0e15431be379561d28ba6 CPU threads: 2; OS: Windows 11 X86_64 (10.0 build 22621); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-GB Calc: threaded Arch Linux 64-bit Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 480(Build:1) CPU threads: 8; OS: Linux 6.11; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US 24.8.2-2 Calc: threaded
Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded strange...
Not with the menus, but dragging the line between column 1 and 2, shows the issue, even with the menus not possible to select the true column 2. Version: 24.8.3.2 (X86_64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Setting the column 2 to 0 width using menus, always left a minimal size being possible to resize the column 2.
Repro Version: 24.8.3.2 (X86_64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: ro-RO (en_US); UI: en-US Calc: threaded
Now I figured out helpful things in reproducing. It turns out you need to have zoom at 140% or bigger in order to shrink the column to zero width on the first try! However, you can still shrink it with <= 130% zoom by first dragging the left border of B1 to the right, then dragging the left border of C1 to the left and finally dragging the left border of B1 to the right again. Before saving, we can rescue the hidden column, but after saving and reloading, the table is ruined forever at the UI level. Bibisecting with linux-42max, the ability to go to width zero seems to be a side effect of commit bfa3f8584b2f2492f5c0573f22e4ebd96d9a8af5 fdo#38144 Enhance snapping to markers, also snap to frame margins In this old version, even with >= 140% zoom I sometimes had to tease out the zeroing behaviour by more than one attempt.