Created attachment 205164 [details] screencast showing the bug In LO 26.2 one can no longer is the toolbar button to select the bullet style: * insert a text box using F2 (Insert -> Text box) * use the toolbar to make the text a bulleted list with e.g. a star at item character result: no matter what you select in the toolbar, you always get a black bullet as character. This makes the whole toolbar button useless because it offers different styles but one can only have black bullets, see the attached screencast. For me this is a regression to LO 25.8 where the toolbar button works correctly. I use Windows 11.
Bibisected on Windows (win64-26.2). First bad commit: 928f0beedaa39b975765565ef61bd201a8c0bf7d Author: Jenkins Build User <tdf@tb102-2> Commit message: source bed0edbc11d5aaeaaf1a5f4b80f791e728bc55b8 tdf#90993 Fix anchored objects disappear Reproducible with bullet toolbar regression in LO 26.2 on Windows 11: - Toolbar bullet style no longer changes character (always black bullet) - Works correctly in LO 25.8.4.2
many thanks for your quick test and confirmation.
Confirmed. TB103 nightly from 2026-01-25 Though result of that bibisect comment 1 looks odd, wrong module? Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 680(Build:0) CPU threads: 28; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded @Aron, checked with the 2026-01-25 nightly of 26.8 and the Bullet library split button does not behave as noted here. So work on bug 169441 (in builds after 2026-01-23) doesn't quite restore function for the Bullet lists and the Bullet Library.
My bibisect result points to a different commit, the 26.2 backport of the following change: https://git.libreoffice.org/core/commit/fe9fab9702613b1a5d192821d8a620aa527234b7 author Miklos Vajna <vmiklos@collabora.com> Thu Dec 18 08:21:14 2025 +0100 committer Miklos Vajna <vmiklos@collabora.com> Thu Dec 18 13:34:33 2025 +0100 Related: tdf#89365 sd UI, from numbering to bullet: fix defaults
My above change was for outliner shapes and this report is for plan textboxes in Impress, so perhaps the fix is to go back to the old behavior for non-outliner shapes. I plan to take a look at this in the near future. Thanks for the bisect.