Description: Editing a formula, the results are displayed at the same time. Steps to Reproduce: 1. Open new Calc. 2. Insert formula "=1" in Cell [ A1 ]. 3. Edit cell formula by [F2] key. Actual Results: 4. The formula and the results are displayed at the same time. Expected Results: 4. No results will be displayed in the cell. Reproducible: Always User Profile Reset: No Additional Info: It may be useful for short formulas and short results, but they overlap and become difficult to see in general formulas. 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 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
Please attach a screenshot on how do you see it.
Created attachment 200760 [details] sample png I don't understand the meaning of the question. However, I'll attach a sample that I think is unnecessary. Attach the image when editing cell [A2].
Created attachment 200761 [details] sample file
Created attachment 200764 [details] Screenshot Please test modifying, even disabling Skia options. Menu>Tools>Options>LibreOffice>View
Created attachment 200766 [details] Screenshot with 25.8 Ok the previous screenshot was with 25.2.3 In other test I can see it with Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 19f3b72f34c487dc97d582712d21734a7e055fd5 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-GB Calc: CL threaded
BTW changing Skia options or disabling doesn't solve the issue.
(In reply to m_a_riosv from comment #6) > BTW changing Skia options or disabling doesn't solve the issue. Yes.
For the most obvious explanation, I have explained it in formulas and results, but there is a similar problem with text and numbers. This problem must be more important. And it may have been created with the same commit as the bug below. https://bugs.documentfoundation.org/show_bug.cgi?id=166520 https://bugs.documentfoundation.org/show_bug.cgi?id=166559
(In reply to nobu from comment #8) > For the most obvious explanation, I have explained it in formulas and > results, but there is a similar problem with text and numbers. > This problem must be more important. > And it may have been created with the same commit as the bug below. > > https://bugs.documentfoundation.org/show_bug.cgi?id=166520 > https://bugs.documentfoundation.org/show_bug.cgi?id=166559 right. bibisected with linux-64-25.8 author Armin Le Grand (Collabora) commit f678ec9a65c4d7ae2d4dda4599a06fc4b66a27d8 CEOO: CellEditOnOverlay Instead of using EditView's Paint directly to Window I changed this now to using the Overlay that is available in all applications. This allows to have less repaints of the Calc View since the Overlay has a copy of the area it is working overlayed. It also allows to get away from one of the last areas where XOR selection was used since EditView/EditEngine have no better way to do this. Selection is now visualized using the OS'es choosen SelectionColor, as in all other apps. I could also get rid of the flush() of the OverlayManager that was needed before and caused some problems (see tdf#165621 and associated tasks). A failing UnitTest showed that OverlayManagerBuffered needs to be aware when no CompleteRedraw was done yet and thus no background data exists and refresh makes no sense. This may happen when there is no redraw/UI e.g. UnitTests, but still an OverlayManager is used and together with a Reschedule (many possible reasons) that refresh might be triggered. Made access to EditView in OverlayObject no longer dependent on ActiveView, that is not always the one with the EditView. Now using a combination of ScTabView and ScSplitPos for accesses. Asserting now if no EditView -> is mandatory. Continuing going through CppunitTest_sc_tiledrendering UTs, one more identified. Have to re-activate EditViewInvalidate rect forwarding since the Invalidate is needed for sc tiled rendering tests, but not for sd tiled rendering tests. Added that to the impl of EditViewCallbacks using LibreOfficeKit::isActive(). Change-Id: I41f5448bfbabfaae4858c7617478771053c2cd77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184830