Description: Cells far from [A1] may become invisible to the second character after the cell input. Steps to Reproduce: 1. Open new Calc. 2. For example, Insert the text "aaaaaaaaaaaaaaaa" in cell [A100]. Actual Results: 3. The second character and subsequent characters may not be visible in the cell or displayed correctly. If you confirm with Enter, all text will be visible. Expected Results: 3. All inputs in the cell are visible. Reproducible: Always User Profile Reset: No Additional Info: I don't think this problem has happened until recently. It may only be the Windows version. Not reproducible with Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Reproducible with [2025-05-09] Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9bc5b89c149497a83117edfadc3fb0b96d2f9899 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (ja_JP); UI: en-US Calc: CL threaded
Not reproduced with (2025-04-26) Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e4fb32ffef1630ceaf5a0a77307e02ae93c9f8f4 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (ja_JP); UI: en-US Calc: CL threaded
Thank you for reporting the bug. I can confirm that the bug is present in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9bc5b89c149497a83117edfadc3fb0b96d2f9899 CPU threads: 2; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Once the text is inserted, only the text laying on the border between cells a100 and b100 and the text that overflows into the next cell (b100) is visible. Resizing the cell can change which characters are not visible before each insert. This behavior does not exist in Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
This problem must be more important. This makes it even difficult to verify the master version.
The second character is not displayed in cell L1 When you scroll, this isue is reproduced in cells B1 and A4. This issue was not reproduced in the current bibiect win64-25.8 master repository. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 078337562dc8c6a92def7760c54960a06d6a81cf CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: en-US Calc: CL threaded
Created attachment 200805 [details] 2025-05-14 LO main build repro on macOS Confirmed in Version: 25.8.0.0.alpha1+ (AARCH64) / LibreOffice Community Build ID: 7fd5af6b503260f2b66fbba7f1b4e750ce5dbb52 CPU threads: 12; OS: macOS 15.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Oddly this does not reproduce in cells close to top left. Have not investigated in which range this starts but repro worked on first attempt after scrolling down and right a bit.
OS -> all Importance -> high
Also reproduced in Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 4727305dd2e6fa1e92408d9fd7fef70b8d1fb913 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: x11 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded
Regression introduced by: commit f678ec9a65c4d7ae2d4dda4599a06fc4b66a27d8 [log] author Armin Le Grand (Collabora) <Armin.Le.Grand@me.com> Wed Apr 30 14:16:25 2025 +0200 committer Armin Le Grand <Armin.Le.Grand@me.com> Wed May 07 10:54:30 2025 +0200 tree cf1c9e038d9c936cb8b24d54fba5bc42a5059692 parent 0891df6b21fd95ec7c9614509d92829c0f17c353 [diff] CEOO: CellEditOnOverlay Bisected with: bibisect-linux64-25.8
Took a look in Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 97eee3c482f25c08680ab7ef52e7e3711f57c58a CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded but could not reproduce (?) Most comments have Skia active in VersionInfo - could someone check if it may have to do with that, e.g. switch to default/cairo...?
(In reply to Armin Le Grand (allotropia) from comment #9) > but could not reproduce (?) Most comments have Skia active in VersionInfo - > could someone check if it may have to do with that, e.g. switch to > default/cairo...? I can reproduce something similar with gtk3 or qt6 (Cairo) at least, and bibisected this to the commit mentioned in comment 8, so it might be caused by the same root problem: * start new Calc doc * select cell J20 by single left click on that cell * click on the calc input bar in the toolbar * type "eee" Since f678ec9a65c4d7ae2d4dda4599a06fc4b66a27d8, the start of the first character is cut off until pressing Enter to confirm input. Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: a5239bd4a8ceba49996df84d31400e573dd9cfa1 CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded
(In reply to Michael Weghorn from comment #10) > Since f678ec9a65c4d7ae2d4dda4599a06fc4b66a27d8, the start of the first > character is cut off until pressing Enter to confirm input. i.e. it is not rendered correctly in the document view (but is shown fine in the input bar itself).
I can reproduce this bug on macOS with Skia/Metal, Skia/Raster, and Skia disabled. It is as if "auto" text color is being replaced with black when in Dark Mode: Version: 25.8.0.0.alpha1+ (AARCH64) / LibreOffice Community Build ID: c854f5aaae575a0570f79a225b80b53ed420578c CPU threads: 8; OS: macOS 15.4.1; UI render: default; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
Created attachment 200866 [details] Snapshot of text entered but not yet committed in an empty cell Note how in cell A100 that all "a" characters after the first character up to the blinking cursor are black instead of white even though the character color is "auto". Also, pressing Command-A to select the text does not render the semi-transparent overlay selection rectangle.
Thanks for the Infos! - I always tried to type in the cell itself...
(In reply to Armin Le Grand (allotropia) from comment #14) > Thanks for the Infos! - I always tried to type in the cell itself... Don't know if it helps, but I have always encountered this bug in recent nightly builds when typing directly in an empty cell. I never tried entering in the toolbar input field. I would just click on cell A100 and start entering multiple "a" characters. Also, when selecting an uncommmitted cell, I had the focus on the cell and pressed Command-A or selected the native macOS menu.
(In reply to Patrick (volunteer) from comment #15) > Don't know if it helps, but I have always encountered this bug in recent > nightly builds when typing directly in an empty cell. That was probably https://bugs.documentfoundation.org/show_bug.cgi?id=165621 Hunting this one, can now reproduce (thanks!) and confirm that it's independent of render used
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6064d732dc9baf06e2d778b0167f149ed212def9 tdf#166520 make OverlayManagerBuffered more aware of MapModes It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I think I identified the problem, should be fixed with https://gerrit.libreoffice.org/c/core/+/185563. Pls have a look
(In reply to Armin Le Grand (allotropia) from comment #18) > I think I identified the problem, should be fixed with > https://gerrit.libreoffice.org/c/core/+/185563. Pls have a look Tested in my local master build and the bug is fixed for me: Version: 25.8.0.0.alpha1+ (AARCH64) / LibreOffice Community Build ID: b96aedb6f4a830c9b61f103dbbe71f491dca1d70 CPU threads: 8; OS: macOS 15.5; UI render: default; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
verified in Version: 25.8.0.0.alpha1+ (AARCH64) / LibreOffice Community Build ID: 3158b14e0b26875300a8098bc117a5e69b76f48f CPU threads: 12; OS: macOS 15.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Thanks so much for the quick fix, Armin.