Created attachment 189166 [details] The effect of width-increasing and width-decreasing edits on a textbox A textbox can be set to "Fit width to text". In that state, when one edits the textbox and changes the width - e.g. by joining or splitting lines - it stands to reason that the user see an indication of what the automatically-resized textbox will look like with the text having been edited. Well, this happens, but - not consistently. In the attached video, you'll see a textbox, with an orange color background and two paragraphs of text, being edited twice: * Once decreasing the width by inserting a paragraph break * Then again by increasing the width by removing the break (de-selecting the textbox between these two actions). With the first action, we note that the grayish frame surrounding the textbox doesn't change dimensions, nor does the background. With the second action, the grayish frame is resized - that's the indication of what the textbox will be like after the edit - while the background retains the dimensions of the existing, non-resized, box. The bug is the inconsistency between these two cases. As for what to do, I like the behavior in the second case better, despite it being a bit jarring to have some textbox features change and some remain as is, so I'd like the second case behavior to apply to the first case as well. Another option is two have all textbox features fit the altered size immediately (i.e. like neither of the cases).
Created attachment 189167 [details] Presentation used for the recording in 189166 Super-simple presentation with a textbox which I used for the screen recording. Result of deleting the main content area in an new empty presentation, adding a textbox, typing in the text and setting an orange background.
Isn't it just a visual glitch? The "Fit to Width" does its job properly.
(In reply to Heiko Tietze from comment #2) > Isn't it just a visual glitch? The "Fit to Width" does its job properly. It's a bug in the visualization we get while editing the text. Indeed, it doesn't persist when you finish editing, which is why I marked this bug as being of minor severity.
Please update the summary accordingly. No need for UX input (QA should test on the various platforms and whether it's Skia-related.
Reproduced in: Version: 7.6.1.1 (X86_64) / LibreOffice Community Build ID: c7cda394c5de06de37d8109c310df89a4d4c3a98 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: beaea2e992912b4747d790070b26371f557b1f57 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Delay in updating background fill to new size when text width is increased, and delay in fitting size to contents when text width is reduced. With example file, no update whatsoever if the first action after fileopen is reducing text width. No repro in OOo 3.3 -> regression. There's (at least) two issues here. Checking with the linux-64-releases bibisect repo: - The lack of update in size when removing text started in libreoffice-4.3.0.0.beta1 - The delayed repaint of the background when adding text started in libreoffice-6.0.0.0.alpha1 Let's start with the delayed repaint. We can open a separate report for the issue introduced in 4.3 if needed.