The Bullets and Numbering toolbar disappears when not being used. When I check View> Toolbars> Bullets and Numbering, the toolbar becomes visible. I dock the Bullets and Numbering toolbar. If I backspace on a line, deleting the Bullet/Number, the toolbar disappears which requires that I recheck the toolbar to make it visible again. If I check view the toolbar (to make it visible) then the toolbar should remain visible until I uncheck it. Thanks, Tracey
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
It looks like RFE bugreport. Reopening.
I can confirm this bug in LO 4.0beta1 on platform windows vista Same behaviour is also seen for tables toolbar (it disappears when focus moves out from the table in any document)
This issue is related to bug 34451 and apparently inherited from OOo.
I can confirm this bug in 4.3.2. I'll copy my comment from https://bugs.freedesktop.org/show_bug.cgi?id=81475#c23 here: I think that dynamic appearance/disappearance of toolbars is not a good idea. For me it is comfortable to place toolbars once and use them when I want to use them, not contextually (current object- or action- dependent). But now in 4.3.2 toolbars disappear even if they have Lock Toolbar Position option checked. Please enable static toolbar positions. Popping toolbars may cause attention switch and may lower document author's productivity. Otherwise you will create another stupid, ugly, non-usable Ribbon/MFI. I think that many LibreOffice users would be happy with MS Office 2003-like interface. Users do not need bells and whistles, they need comfortable and customizable interface. This interface should allow users to place and pin (lock) toolbars as they want and use keyboard shortcuts for more productivity (for example, the fastest way to add Cross-Reference is to press <Alt-i><e>).
*** Bug 59176 has been marked as a duplicate of this bug. ***
This bug still exists as recently as LibreOffice 7.1.4.2 on Windows 10 x64. And I'd argue that, from a user perspective, this is NOT the same bug as Bug 59176. To recap (similar to original bug report): 1. Create a bulleted list 2. View -> Toolbars -> Bullets and Numbering 3. Move the cursor out of the list 4. Toolbar suddenly disappears Basically, the toolbar only remains visible when you are within a list. As soon as you exit the list the toolbar disappears. This is NOT the behaviour in LibreOffice Impress where the Bullets and Numbering toolbar automatically shows up when you are editing a bulleted list. SUGGESTIONS 1. For uniformity across LibreOffice I'd suggest that the Impress behaviour should be implemented in Writer. 2. In addition, when the user selects the toolbar from the menu then it should never disappear - under any circumstances.
*** Bug 148673 has been marked as a duplicate of this bug. ***
As discussed on bug 148673 we should show the toolbar for any paragraph which outline level is not Text Body. And the toolbar should become renamed "Outline and List".
(In reply to Heiko Tietze from comment #13) > As discussed on bug 148673 we should show the toolbar for any paragraph > which outline level is not Text Body. iiuc the OP here is about allowing the user to manually override the context-sensitive nature of the B&N toolbar. STR. 1. Insert a non-list paragraph. 2. View > Toolbars > Bullets and Numbering. 3. Insert a new paragraph, formatted as a list paragraph 4. Place cursor in (initial) non-list paragraph. Actual: Toolbar appears after step 2, but disappears after step 4 Expected: Toolbar remains visible (because I have manually chosen to "View" it) until I manually choose to "hide" it. Tested with: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: f8e11c6480ff0005715b989a6d4e2e10a3816cf6 (I have not tested other context-sensitive toolbars, but I could imagine that the request can be generalized to "always show toolbars that I manually "activate" with View > Toolbars.) That request seems worthy of consideration, but the issue discussed in bug 148673 would not "resolve" the OP here -- because the B&N bar would disappear on non-list paragraphs with "Text Body" outline level.
(In reply to sdc.blanco from comment #14) > .. the request can be generalized to "always show toolbars that I manually > "activate" with View > Toolbars.) That's my understanding too. Somehow I manage this in my recent tests but I couldn't reproduce. Neither with the table toolbar. Fact is that leaving the context hides the contextual toolbar even when it was enabled manually. But additional to this bug we should auto-show the list/outline toolbar more often. Which would be kind of a workaround to the other issue as it makes the manual activation obsolete.
(In reply to Heiko Tietze from comment #15) > Fact is.... Some do not like context-sensitive menus popping up (comment 9) Others want to control toolbars manually, without it being overridden by context sensitivity (comment 0, comment 11) If Tools > Options > Writer > View had a checkbox: o Do not use context-sensitive toolbars Then I believe all the concerns in this ticket would be addressed, except for the new issue about outline and list, which I believe is incorrectly injected here. And for the new issue, an Outline bar should be made separate from a List (B&N) bar. - No other toolbar combines two different issues/functions. - Additional reasons available. - Bug 148673 comment 7 elaborates how to make an Outline bar.
(In reply to sdc.blanco from comment #16) > If Tools > Options > Writer > View had a checkbox: > o Do not use context-sensitive toolbars Could be an option but I would prefer the tristate solution (on/off and automatic). > Then I believe all the concerns in this ticket would be addressed, except > for the new issue about outline and list, which I believe is incorrectly > injected here. Feel free to revert the duplication. > And for the new issue, an Outline bar should be made separate from a List > (B&N) bar. The toolbar offers Promote/Demote, Move up/down, and various list attributes. Makes no sense to separate one from the other.
(In reply to Heiko Tietze from comment #17) > prefer the tristate solution (on/off and automatic). +1 - changing bug summary here (In reply to Heiko Tietze from comment #15) > But additional to this bug we should auto-show the list/outline toolbar more > often. +1 -- which is the OP of bug 148673 > Which would be kind of a workaround to the other issue But would not address the general concern here about controlling appearance of toolbars Last two points => reverting the dup of bug 148673
Bug 36976 looks like a duplicate (or visa versa)
*** Bug 100314 has been marked as a duplicate of this bug. ***
*** Bug 109291 has been marked as a duplicate of this bug. ***
*** Bug 119998 has been marked as a duplicate of this bug. ***
*** Bug 122030 has been marked as a duplicate of this bug. ***
*** Bug 36976 has been marked as a duplicate of this bug. ***
*** Bug 34451 has been marked as a duplicate of this bug. ***
*** Bug 45547 has been marked as a duplicate of this bug. ***
*** Bug 61237 has been marked as a duplicate of this bug. ***
Also Bug 106846 and duplicates requesting the same, I guess
*** Bug 137760 has been marked as a duplicate of this bug. ***
*** Bug 127039 has been marked as a duplicate of this bug. ***
*** Bug 125787 has been marked as a duplicate of this bug. ***
FWIW: on or off pretty binary. There tremendous amounts of toolbars. I'm not totally against context-sensitive toolbars in general. In my reading bug 106846 is actually asking for possibility to make customized toolbars context depended too (which I do even get) However I do use only a selection of toolbars more often, and want those to be permanent. To prevent continues changes within the UI (with toolbar appears, disappearing etc). And certain controls in the toolbar have something a function even outside the context (which makes the disappear), another reason to have the non-context-sensitive I have no problem with incidental context depended toolbars. If I would disable context-depended toolbars across the board, I would lack the controls at certain actions I incidentally use (and I might even overlook the existence of those) So I actually prefer to have an entry similar to the 'lock toolbar position', except this entry called 'lock toolbar' (or Disable Context Sensitivity or whatever label fitting). This would give the maximum control.
*** Bug 105111 has been marked as a duplicate of this bug. ***
*** Bug 98434 has been marked as a duplicate of this bug. ***
Bug 98434 mentions content jumping up and down because the toolbars total height is changed. By default, the first toolbar line is filled, so the context-sensitive toolbars show up on a second line.