Bug 169307 - The bookmark(s) on current cursor position should be displayed in the status bar and/or in the properties window.
Summary: The bookmark(s) on current cursor position should be displayed in the status ...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Navigator Navigate-By
  Show dependency treegraph
 
Reported: 2025-11-07 00:18 UTC by Hartmut Schorrig
Modified: 2025-12-02 07:29 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hartmut Schorrig 2025-11-07 00:18:12 UTC
All bookmarks are visible for example pressing <ctrl-F2> for "Insert cross references" or also press right mouse button in the status bar in the page field to select all bookmarks as destination to select. On menu "Insert bookmark" the used bookmarks on pages are shown.
But a inserted bookmark in the text is never displayed. The bookmark to a text position can be evaluated by looking in the content.xml, maybe it's possible to generate a report file from there by self programming, which analyzes the content.xml. But this is not feasible by normal working.
Why is the bookmark at the current cursor position not displayed anywhere? It may be an important information for the structure of the document and using cross references. 
The status line on bottom of the window may be the best place for a bookmark if given, or for more as one bookmark if more as one are given on the same location. 
Another also acceptable place to show the bookmark may be the "properties" window, where also formatting stuff is shown.
This feature proposal should be seen related to bug 169306 as general feature: "All relevant content in the document should be easily visible: What you see is what you have".
Comment 1 V Stuart Foote 2025-11-07 01:41:11 UTC
This is supported in the Navigator deck of the Sidebar (docked or the floating F5 instance).

All bookmarks show in the Sidebar Navigator, with visual feedback. While on mouse-over of a URL will open a tooltip with the URL value and list the accelerator to follow the URL.

While many web browsers URL are flashed bottom edge of browser, but the Status bar is already overloaded at that position. IMHO the Navigator handling suffices.

What more is needed? Please describe a workflow that would be improved by placing bookmark or URL on the Status bar.


Version: 25.8.3.1 (X86_64)
Build ID: 52ad9dd1c984050a9fb6932dbfb16e86a49e9758
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
Comment 2 Hartmut Schorrig 2025-11-10 22:18:07 UTC
The Navigator side bar shows Headings, Tables, Frames, Images etc. and also Bookmarks. It is proper to go from a known Bookmark (as also from known Image Label, or from header) to the text where it is located. But not in the back direction. The back direction refers from the text to either header, if click in the text on a header, or to a section. The last one is not usable for me (by the way) because there are many sections without name and meaning because they exists because I write in columns (only by the way). 
But never I can reference from the text to the apropriate bookmark. The Navigator is not able to explore or see, which bookmark is used for the current text part (usual a header on my usage). Instead it shows the header text in the chapter structure, which is proper for other using approaches.
If a bookmark is used for a text part, small gray [...] are visible. So I get the information, there is a bookmark. But it is not possible to see which (its identifier).
The only possibility to find which bookmark is: Open navigator, estimate which bookmark may the correct one, select it and press enter. Then the text position is set to the selected bookmark. But unfortunately then, immediately the position in the Navigator is lost, because the Navigator goes to the header entry. So it is NOT POSSIBLE to evaluate in the given order a bookmark in the near, test next etc. 
The bookmarks in the Navigator are sorted in order as in the text, that is proper (!). But this is not usable because the selected position in the Navigator is away because select the adequate header in this long table.  
If for example the bookmarks are an extra select table (separated from Header, and also sections) this effect would also supressed. But only one table for all destroys ability of usage.
It means, have an extra Navigator only for bookmarks may be also a proper feature. - Should be discussed in another bug number. 
But why, the context info which bookmark label is not shown with the right mouse context menu. This would be the most obvious conceivable solution. 
The status bar has also enough space. But, yes, discussion what is shown in the status bar needs more detail discussion. 
The status bar contains ~30% of space to show the page style. This is simple able to evaluate on opened Styles Window, selecting page styles. It is (in my mind) not necessary in the status bar.
Comment 3 V Stuart Foote 2025-11-11 14:02:37 UTC
(In reply to Hartmut Schorrig from comment #2)

Navigator presentation is bi-modal, by document structure (Sections, Headings, Table elements, etc.) The other mode is by specific element--Bookmarks as you'd prefer. 

So have you toggled the Navigator button 'Content Navigation View' disabled and then selected 'Bookmarks' as your Navigate-by mode?  Clicking the document "bookmark" mark then reposition to the corresponding bookmark in the Navigator deck, or the opposite--positioning edit cursor on canvas--when click selecting the item from the Navigator.  Simple mouse-over action just flashes the position on document canvas.

This all Works for me.


Version: 25.8.3.1 (X86_64)
Build ID: 52ad9dd1c984050a9fb6932dbfb16e86a49e9758
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
Comment 4 Hartmut Schorrig 2025-11-12 14:47:37 UTC
Ok. With your description I can now show which bookmark is bounded to a text part, usual Heading or also Image caption. This is a work arround. I can work with it. 
But I have not found this solution by myself (supposed other users are also so stupid as I am). To improve the handling in the navigator, make it more intuitively, another bug entry will be necessary. I say, this are all not hi priority bugs, they are inputs to improve handling (topic of usability) to improve acceptance by users for LibreOffice at all.
The original request for this change request (it is not a bug, it is a requested feature, designated as "medium enhancement") is in my mind not solved. Do not set the bug to resolved. It should be discussed also with more users and/or in other round tables. I think it may be set to "assigned" but I have to less experience with bugzilla.
But thank you very much for your support, now I can better work with my bookmark system.
Comment 5 V Stuart Foote 2025-11-12 15:43:29 UTC
-1, the handing in the Navigator is sufficient. No need to clutter the Status bar or SB Properties deck

Folks just need to RTM and work with the Navigator to realize its bi-modal nature. It supports hierarchical navigation *AND* it supports by object type navigation.

User was in the wrong mode.
Comment 6 Heiko Tietze 2025-11-12 15:49:17 UTC
We have bug 113828 about status bar customization. But in any case I don't get what information of bookmarks need to be always present (BM can be on a single character or even a hidden text). Bookmarks are meant as anchor to quickly navigate through the document. And that's well represented in the Navigator.

(In reply to Hartmut Schorrig from comment #4)
> But thank you very much for your support, now I can better work with my
> bookmark system.

(In reply to V Stuart Foote from comment #5)
> -1, the handing in the Navigator is sufficient.

=> WF
Comment 7 Hartmut Schorrig 2025-11-19 13:23:02 UTC
@Heiko "Bookmarks are meant as anchor" Yes! They can be also used as anchor to navigate from outside to the inner of the document, which contains information to process. Process may be also in a content management system which reads the odg-content.xml, searches the bookmark etc. That's why it should be simple possible to see which bookmark text is associated to a chapter title (or other text), to use a system of well designated bookmarks for content management.
I have tried to get the bookmark text from a searched chapter, looking in the text for content. First I should open the navigator for header view, search the possible proper chapter in the structure, looking of matching content in the document. Then I set the cursor on the chapter title (heading paragraph), want to know which bookmark text. But I should go to navigator, switch off "Content Navigation view", scroll to any bookmark, switch on "Content Navigation view", (by the way loss the overview of the chapter structure), then again click to the chapter title to select the bookmark in the navigator. To get its text in the clipboard, I should first press right mouse and "Edit", then mark, then hope (it is so) that ctrl-C copies. That are too much steps to get the bookmark to the chapter. It disturbs the working flow, always concentrating to handling with LOffice, no concentration to the intrincis problem. 
It will be very more nice navigate in the text, concentrate to content, regardless of other, then either look in the status line, copy the bookmark with mark and ctrl-C, or alternatively press right mouse, select "show Bookmark" (if it would exist), copy it. Work furthermore in the own workflow. It is a quest of usability. 
That's why I think the problem should be solved, Bookmarks may have a relevant meaning to work with content.
Comment 8 V Stuart Foote 2025-11-19 13:37:25 UTC
I still don't follow the work flow that adding Bookmark content to the Status Bar would support. The Status Bar itself is a single row GUI (actually a toolbar structure), limited space to "show" a field containing content of a bookmark.

=> WF
Comment 9 Heiko Tietze 2025-12-02 07:29:11 UTC
(In reply to Hartmut Schorrig from comment #7)
> That's why it should be simple possible to see which bookmark text
> is associated to a chapter title (or other text), to use a system
> of well designated bookmarks for content management.
Sounds like an abuse of bookmarks. Anyway, the Navigator shows the BM text nicely, no need to fuss with the statusbar. Keep also in mind that BM are very contextual - relevant fgor only a very small part of the text - while the statusbar typically is agnostic of these little changes. => WF