Description: Applying color fill to textbox from toolbar not working Steps to Reproduce: 1. open attachment 168890 [details] 2. Select the textbox 3. Select a fill color in the toolbar (not sidebar) Actual Results: Not applied Expected Results: Working as in 4.4.7.2 Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) Build ID: f2171af6ce3516598d9f8bac8294025a21a5b1a2 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL and in 5.0.2.2 not in 4.4.7.2
Seems that Draw text box object has DF applied, with area fill set none and line set none. Simply select the object and clear DF. That will restore the ability to fill with color picker. Alternatively, select the object and apply a different style (which will clear the DF). Or modify the applied default drawing style, but better to duplicate the default and save as a new style. WFM and => NAB
(In reply to V Stuart Foote from comment #1) > Seems that Draw text box object has DF applied, with area fill set none and > line set none. does the answer change if this the default behavior.. 1. Open Impress 2. Press F2 And you got the textbox seen in attachment.. Applying DF by default to textbox seems wrong to me..
Thank you for reporting the bug. I can confirm the bug present in Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Version: 7.2.0.0.alpha0+ (x64) Build ID: 761a672d62df1891b9f4f367a499b220ab2b33fa CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still an issue in: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 636f853bda69a889146968116b276d88f105b47f CPU threads: 6; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Nothing has changed. The <F2> inserts a textbox with formatting to match other "draw:Frame" objects (no-fill, no-stroke) while the TB shape inserts a "draw:custom-shape". They result in different objects. Checked back to 3.4.6 build (couldn't check at 3.3.0 as save to a FlatODF needed 32bit java). Assume it is inherited from OO. IMHO => NAB =-=-= @Regina, what's your take (or recollection) on why a newly <F2> created sd draw:frame gets DF with draw:fill="none" and draw:stroke="none"? As opposed to a newly TB drawn:custom-shape object taking the "graphic" <- "standard" parent's attributes. Is this convenience so that when adding a drawn textbox in Writer or Calc there is no fill or line--to better match a Frame graphic? And if so, would it make sense to test which module is receiving the object and in draw or impress Also, if a text box with no-fill and no-line is needed across the modules, why don't we use the default 'Object with no fill and no line' style instead of "Default drawing style" needing Direct Formatting applied?
(In reply to V Stuart Foote from comment #6) >... to test which module is receiving the object and in draw or > impress I better finish that thought, ...and in draw or impress, rather than a draw:frame, insert a draw:custom-shape. Or do the alternate and adjust the frame graphic style to *include* fill and stroke from the parent style only for a Draw or Impress graphic object.