End of June 2021 I first observed that the Navigator adjusts itself to the proper headline associated to the current editing position. The item belonging to the edit position in the Edit window gets highlighted. That's something which has long been missing and which is very useful. Now I found something inconsistent with that: If the edit position in the edit window is in a table, the highlight moves to the relevant entry in the Tables category, if it is in a section, the highlight jumps to the proper entry in the Sections category. When writing a larger document, the main hierarchy of things is by headline order. Being able to associate some place in the document to the surrounding headlines hierarchy is the main concern. Only in very special cases one might want to locate an image in the list of all images or a table in the list of all tables and so on. Locating something in another category than the one highlighted (Headings/Images/Sections/Table, ..., topmost drop-down setting of Navigator) is not meaningful, especially jumping to sections instead of headlines is bizarre. Sometimes I use tables because they make the location of inserted images more predictable than if I insert them into the text (e.g. anchored to paragraphs). If - as e.g. often in user manuals - many short text passages and corresponding illustrations follow one after another, it may even make sense to place headings in tables as well. If you do this, however, you lose the nice feature of the navigator that you can continuously see how a text is positioned in the hierarchy of associated headings: The navigator suddenly shows the position in the hierarchy of tables (or sections, if the text passage is in a section). Expected behavior: I expect the navigator to always show the location of the bookmark in the editing window with respect to the category selected in the navigator's drop-down list of categories at the top left (really useful there are headings, tables, maybe sections. For hyperlinks, I can only imagine that it might make sense to highlight the next hyperlink before the position of the bookmark in the editing window).
Created attachment 179856 [details] A demonstration of the bug and of two more other bugs, which will be reported in separate bug reports.
Adalbert, thank you for the report. I can see the amount of work, reporting this bug. But to be honest, I don't want to read a bug report like an article, but just have a set of steps to reproduce and I can't find it in your report. perhaps if i read it very carefully, i could figure out some steps and test, but this would take a lot of time and perhaps my steps are not yours. So please: Reduce your reports to a time saving minimum, and provide some steps: 1. ... 2. ... ... Kind regards Dieter
(In reply to Dieter from comment #2) > Adalbert, thank you for the report. I can see the amount of work, reporting > this bug. But to be honest, I don't want to read a bug report like an > article, but just have a set of steps to reproduce and I can't find it in > your report. perhaps if i read it very carefully, i could figure out some > steps and test, but this would take a lot of time and perhaps my steps are > not yours. So please: Reduce your reports to a time saving minimum, and > provide some steps: > > 1. ... > 2. ... > ... > > Kind regards > Dieter Dieter, the attached file is a playground and it has an example under the headline "Some screenshots demonstrating what goes wrong". 1. load the attached example https://bugs.documentfoundation.org/attachment.cgi?id=179856 2. enable the Navigator in LO Writer 3. select "H Headlines" in Navigator's selection box at the top left 4. in the edit window mark the word "End of June 2021" after the headline "Preceding events in a table" Observed result in the Navigator: "Table 1" under "Tables" is highlighted in the Navigator. Expected result: "Preceding events in a table" is highlighted under Headlines, since "H Headlines" is selected in the uppermost selection box. On page 9 of my report, it shows screenshots of a similar inconsistency in conjunction with sections. Probably it is the same bug and the remedy to cure the first example will also fix it. Conclusion The current editing position in the editing window shall always be reflected in the Navigator window with respect to the category selected in the navigator's drop-down list of categories at the top left of it (Step 3 above)..
Adalbert, I assume, that "Headlines" = "Heading". I confirm the behaviour, but i think it is expected, because if you click into a document the element in navigator is highlighted. the "Navigate By" selection is only relevant for up and down arrows next to that field [1]. But there is one question: If you have a heading in a table, "Table" is highlighted in navigator, but not heading (see for example heading "Expected behaviour in a table" in attachment 179856 [details]), although you use "Navigate By" function. I won't expect this, but perhaps, this is also expected. Jim, I'm sure, you can explain this. cc: Jim Raykowski [1] https://help.libreoffice.org/7.4/en-GB/text/shared/guide/navigator_setcursor.html?&DbPAR=WRITER&System=WIN
I don't think I can explain the current behavior any better than Dieter has. The content view can be toggled to show only Headings content, this seems to be what you are after. 1) Click the Headings category in the Navigator content tree or one of the headings listed in the Heading category. 2) Click the 'Content Navigation View' toggle button. It is the first button on the second line of controls in the Navigator. Here is a link to a screen cast demo that hopefully helps: https://bugs.documentfoundation.org/attachment.cgi?id=179020
Jim, thank you for quick reply and the video. So I think we can close this report as NOTABUG, because current behaviour is expected one and Adalbert, you can get the desired result by using "Content Navigation View". => RESOLVED NOTABUG Jim, I can see an inconsistency: Button is called "Content Navigation View", but in LO Help it is called "Content View" [1]. So if you try to search "Content Navigation View" (with quotation marks) in LO Help you won't get a result. So I would either change name of button or name in documentation. So my questions to you are: a) Do you agree, that we need more consistency here? b) Which name do you prefer? https://help.libreoffice.org/7.3/en-GB/text/swriter/01/02110000.html?&DbPAR=WRITER&System=WIN
> Jim, I can see an inconsistency: Button is called "Content Navigation View", > but in LO Help it is called "Content View" [1]. So if you try to search > "Content Navigation View" (with quotation marks) in LO Help you won't get a > result. So I would either change name of button or name in documentation. So > my questions to you are: > a) Do you agree, that we need more consistency here? > b) Which name do you prefer? Looks like the buttons tool tip was changed from "Content View" to "Content Navigation View" in version 5.2 by a commit made for bug 43514: https://bugs.documentfoundation.org/show_bug.cgi?id=43514#c20
(In reply to Jim Raykowski from comment #7) > Looks like the buttons tool tip was changed from "Content View" to "Content > Navigation View" in version 5.2 by a commit made for bug 43514: > https://bugs.documentfoundation.org/show_bug.cgi?id=43514#c20 Thank you for your investigation: So we should change name in documentation. I will file a bug report.
(In reply to Jim Raykowski from comment #5) > ... > > Here is a link to a screen cast demo that hopefully helps: > https://bugs.documentfoundation.org/attachment.cgi?id=179020 Thank you for your screen cast. One should emphasize the order of actions to be done: 1. Without the button ContentNavigatorView being pressed first select the category in whose hierarchy Navigator shall operate, e.g. H Headings. (If ContentNavigatorView is pressed, you won't be able to select another category than the presently active one. 2. Then latch the button ContentNavigatorView in the pressed state. Then Navigator will always center itself to the proper Navigator-item related to the actual editing position. By the way: After starting LO Writer, H Headings should be selected automatically and ContentNavigatorView should be pressed. This would be the most useful use case and it would prevent dumb questions like mine.
(In reply to Dieter from comment #8) > ... > > Thank you for your investigation: So we should change name in documentation. > I will file a bug report. Dieter, before paragraph "Click the plus sign (+) (or arrow) next to a category in the Navigator to view the items in the category…" please insert "The navigator shows what corresponds to the editing location in the navigator view. This can be according to different categories: Headings, Tables, Hyperlinks etc (see below). When the "Content Navigation View" button is pressed and headings are selected, the heading belonging to the current editing position is displayed and highlighted in the Navigator. When tables are selected, the associated table is displayed, and so on. If the element is located in a collapsed layer, the required layers above it are automatically expanded and remain expanded afterwards. If the "Content Navigation View" button is not pressed, the navigator selects the category by itself (in this case, sections take precedence over tables taking precedence over headings). If the "Content Navigation View" button is pressed, it is not possible to select any other category than the one currently selected. (This is a bit awkward and the selection probably was taken to show all possibilities. After a start NavigatorElement(Type(mousePosition), mousePosition) is shown mode instead of NavigatorElement(contentNavigationView, mousePosition). One might think about changing this. Also one might consider unifying "Navigate by" and "Content Navigation View", then one could show all categories and have the most useful function preset). This line should be added to the description of Content Navigation View: The button "Content Navigation View" is not to be mixed with the button "Navigate By", which merely defines the green arrow buttons previous and next to the right of it. The description of "Navigate By" should become "Navigate By" Use selection box to choose which type of item should be navigated, when using the Previous and Next buttons. This button should not be confused with "Content Navigation View".
(In reply to Dieter from comment #8) > I will file a bug report. Bug 149301