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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/49a49acf65f5d77383551217abc39c06dbd62909 tdf#170466 sd UI, bullet library: avoid unwanted defaults It will be available in 26.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.
> affected users are encouraged to test the fix and report feedback Many thanks for the quick fix! Since it will not be in LO 26.2, this bug will stay in the next stable version. Then other will encounter the same bug, report it again because bugzilla does not list it as an open/known bug. This created unnecessary work for the bugzilla moderators. Therefore it should only be marked as FIXED if the fix is in the stable version -> I reopened it therefore. Besides this, someone should conform that it is fixed before it is marked FIXED.
https://gerrit.libreoffice.org/c/core/+/198424 is already pending CI (thanks Xisco!), so it'll be fixed in 26.2.next. :-)
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/32333f8e5367bc703083057caafae3351ec9a983 tdf#170466 sd UI, bullet library: avoid unwanted defaults It will be available in 26.2.1. 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.
(In reply to muso from comment #7) > Therefore it should only be marked as FIXED if the fix is in the stable > version -> I reopened it therefore. The bug tracker has its rules. Please don't try to enforce your ideas of what is correct. Thank you for filing the bug!
> The bug tracker has its rules. https://bugs.documentfoundation.org/docs/en/html/using/editing.html The point is that when I file a bug, I get bugs as proposed and when I encounter a bug in the current latest version, I would not consider a bug marked as "fixed" because if it would be fixed, why do I see the bug then? maybe you can discuss and adapt the rules with your team. I think it would save the bug moderators a lot of time if people don't report bugs as duplicates because they don't understand that "Fixed" does not mean fixed in the stable version.
(In reply to muso from comment #11) Nothing that you write changes a tiny bit in the workflow of Bugzilla. 1. Bugzilla is a tool to enable getting information, reproducing, and finally fixing a bug. The "finally fixing" is the ultimate goal; the point where the code is changed to fix the problem is the most important point. The release procedure adopted by the project makes sure that the code change will reach a release at the due time. There is absolutely no point to waste volunteer resources to keep track of one more thing - when it was released. Doing that would only result in many (more) bugs forgotten in wrong status. 2. Testing by others, if the bug was fixed or not, is reflected by "verified" status, which is orthogonal. 3. There is no single idea of "latest" version. On some platforms, it's what TDF releases. On others, it's what respective maintainers decide to release at their own pace. "why do I see the bug" question has the same answer in all cases: "because you are using a version that has it", which doesn't change even if there is no newer version (yet). 4. Most important: even if we decided to implement your idea, it would do zero to "save the bug moderators a lot of time" - simply because people would keep filing duplicate bugs, no matter if one bug was declared fixed or not. Filing duplicates *is unavoidable* (at least because you never guess how someone else could phrase their description of the same underlying bug); but the interesting detail is: *is a useful thing* - even for already fixed bugs: it reflects how much the bug affects people (and we consider duplicate could as an important metric). I write this to create the *correct* expectations. The current workflow helps us, and the proposal would not improve it. But again: thank you for filing the bug report. It's the most important thing people do to make developers informed.
(In reply to Mike Kaganski from comment #12) > Nothing that you write changes a tiny bit in the workflow of Bugzilla. I was for several years the bug and documentation maintainer of the project lyx.org. Later I was the release manager of the project freecad.org. And I can report these 2 things: * after we changed for LyX the bug policy to mark bugs as "Fixed" we got way less duplicate bug reports (apparently most users googled when they encountered a problem. People consider "Fixed" as being fixed and when the encounter them nevertheless, they are sure they report a new bug.) * For FreeCAD we spent a lot of time on setting up and polishing a pure documentation Wiki (https://wiki.freecad.org/User_hub) because we noticed also int he forum - the better the docs the fewer questions and misunderstandings. And many bug reports were misunderstandings of features or sometimes a feature simply does not exist yet. All this information was added to the Wiki pages and this reduced bug reports AND also forum help requests. Now with AI search tools the AI always refer to the Wiki. I am just a guest here, encounter many bugs, find often no proper information, there is no documentation Wiki in which I can search or publish information. Regarding the bug tracker, I get bugs proposed to avoid duplicates but there should only be open bugs. I only gave feedback.
(In reply to muso from comment #13) > I am just a guest here, encounter many bugs, find often no proper > information, there is no documentation Wiki in which I can search or publish > information. Regarding the bug tracker, I get bugs proposed to avoid > duplicates but there should only be open bugs. If you mean user-facing documentation, some of it does live in the wiki under paths like: https://wiki.documentfoundation.org/Documentation/HowTo https://wiki.documentfoundation.org/Faq https://wiki.documentfoundation.org/Documentation/Calc_Functions ...but the dry reference help lives in a git repository: https://wiki.documentfoundation.org/Documentation/Help The guide books are done as master documents: https://books.libreoffice.org/ https://wiki.documentfoundation.org/Documentation/Cloud https://wiki.documentfoundation.org/Documentation/DocumentationTeamInfo/TrackingTasksWithNextcloudDeck https://wiki.documentfoundation.org/Documentation/DocumentationTeamInfo/ProducingLibreOfficeUserGuides Let me know, if you need help in getting started in some of those areas. About the detail of possible duplicates shown when creating a new report, I disagree because seeing closed reports there is surely helpful to anyone doing QA at least.
> Let me know, if you need help in getting started in some of those areas. I would contribute something but I am really lost. Once I started with FreeCAD for comparison, there are Wiki pages describing the different workbenches (like Impress is a "workbench" in LO). One gets an overview: https://wiki.freecad.org/PartDesign_Workbench As new user I got info for every toolbar item. Then I could simply extend or update these Wiki pages. And the first months I did nothing else than Wiki editing. And this was as easy (or complicated) as editing the Wikipedia. However, with LO I am lost. I would like to use Impress. And my task is that I work for different persons and every customer has its own design. So all I wanted was to setup master slides that fulfill the design rules of the different customers. But there is no Wiki I can start with. There is this: https://help.libreoffice.org/latest/en-US/text/simpress/guide/masterpage.html?DbPAR=IMPRESS#bm_id3152596 But it has no way to edit and the different pages have no page name I can reference. I mean "masterpage.html?DbPAR=IMPRESS#bm_id3152596" is meaningless. I failed to even setup simple lists (spacing does not work, fonts change unexpectedly and are not consistent) etc. I could not find any info how to setup lists in a master slide so that every new list appears exactly as designed. -------------------- > I disagree because seeing closed reports there is surely helpful to anyone doing QA at least. This is not the right perspective. Not a QA person opens a bug but normal users. Most users did not heard of the term "QA". As a user when I encounter a bug, then it is logical for me that if my bug is not already an open bug, it cannot be mine - because if it would be fixed, I would not encounter it.
(In reply to muso from comment #15) > This is not the right perspective. Not a QA person opens a bug but normal > users. Most users did not heard of the term "QA". As a user when I encounter > a bug, then it is logical for me that if my bug is not already an open bug, > it cannot be mine - because if it would be fixed, I would not encounter it. This is not the right perspective. Users file bugs not for themselves, but to enable us to work on them. So whatever procedure makes the bug tracker *useful to us* the people working on the bug, the better. And as I said: preventing duplicates at all costs is BAD, because duplicates themselves are very useful metric. If a user has a problem, it is NOT advisable to them to spend a single second looking for duplicates, for multiple reasons (and our use of duplicates is not even the most important of them). Please stop this off-topic here. If you like, you may use mailing list for discussion of the procedure.
(In reply to muso from comment #15) > > Let me know, if you need help in getting started in some of those areas. > > I would contribute something but I am really lost. Once I started with > FreeCAD for comparison, there are Wiki pages describing the different > workbenches (like Impress is a "workbench" in LO). > One gets an overview: > https://wiki.freecad.org/PartDesign_Workbench > As new user I got info for every toolbar item. Then I could simply extend or > update these Wiki pages. And the first months I did nothing else than Wiki > editing. And this was as easy (or complicated) as editing the Wikipedia. > > However, with LO I am lost. I would like to use Impress. And my task is that > I work for different persons and every customer has its own design. So all I > wanted was to setup master slides that fulfill the design rules of the > different customers. But there is no Wiki I can start with. > > There is this: > https://help.libreoffice.org/latest/en-US/text/simpress/guide/masterpage. > html?DbPAR=IMPRESS#bm_id3152596 https://sports-games.io/ > > But it has no way to edit and the different pages have no page name I can > reference. I mean "masterpage.html?DbPAR=IMPRESS#bm_id3152596" is > meaningless. > > I failed to even setup simple lists (spacing does not work, fonts change > unexpectedly and are not consistent) etc. I could not find any info how to > setup lists in a master slide so that every new list appears exactly as > designed. > > -------------------- > > > I disagree because seeing closed reports there is surely helpful to anyone doing QA at least. > > This is not the right perspective. Not a QA person opens a bug but normal > users. Most users did not heard of the term "QA". As a user when I encounter > a bug, then it is logical for me that if my bug is not already an open bug, > it cannot be mine - because if it would be fixed, I would not encounter it. Impress can be really confusing at first, especially with lists and master slides. The key thing is: it’s all controlled by styles, not just what you click on the toolbar. If you go into Master Slide and then tweak the Outline styles (F11), that’s where spacing, bullets, fonts actually stick. If you don’t use styles, it’ll keep acting weird. And yeah… docs aren’t great. Most of us just learn by trial and error or looking at templates. Once you get styles set up properly, it gets way more predictable.