Problem description: If the Help System is active and a help page is displayed, the items (Headings, Tables, Text frames, ...) of this page are displayed in the item list of the Navigator (Writer). This may be interesting for the author of the help page, but a normal user is rather irritated. Steps to reproduce the bug: 1. Start LO and open a new text document. 2. Display the Navigator (F5). 3. Start Help (F1). A help page is displayed. 4. Change back to document (Alt+Tab). 5. Choose "Active Window" at the bottom of the Navigator window. Now the item list of the help page is displayed in the Navigator. You can even jump to the help page with a double-click of an item. My System: Win XP SP3, LO V. 3.4.4. The bug exists also in V. 3.4.3. I do not use the online help but the German help pack. (Download file: LibO_3.4.4_Win_x86_helppack_de.exe) Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.24) Gecko/20111103 Firefox/3.6.24
Reproducible in 3.6.0 master. But my be so should be by some reason?
Can one of you provide an attachment showing what you're talking about. I'm not clear on what the problem is. Marking as NEEDINFO, once the attachment is made mark as UNCONFIRMED and we'll triage it
Created attachment 66816 [details] Screen shot of Wrinter Window The displayed items (headings and hyperlinks) of the navigator belong to the help window. The text document is completely empty (no headings, no hyperlinks).
Created attachment 66818 [details] Screen shot of help Window Headings and hyperlinks of this help page are displayed in the Navigator of the writer window.
Hello I confirm with windows 7 64bits and: - Version 3.6.4.3 (Build ID: 2ef5aff) - Version 4.0.0.0.beta1+ (Build ID: 58889b2f592658a6c68ed13fe604fbbe7eaad96) More information A. Was already the same with OOo (not a regression) B. We have the same issue with the "Object catalog" in EDI Steps to reproduce: 1. Start LibO 2. Tools> Macros> Organize macros> Basic> Edit (EDI opens) 3. Open help (F1) 4. Change back to EDI 5. Display Object catalog if not (click on the tool in standard toolbar) Help is listed in the catalog, item: vnd.sun.star.help://sbasic.... See attached screenshot (HelpInNavigator.png ) In Writer's context, we can wonder if it is a bug or not: Help is here considered a document. In contrast, in EDI's context, this can be nothing but a bug because the purpose of the catalog is to list macros. Regards Pierre-Yves
Created attachment 71502 [details] HelpInNavigator screenshot
Bug still exists in version 4.3.5 and 4.4.0.2 (RC2).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT: - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-01-17
Bug still exists in version 5.0.4 with Win7.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Bug still exists in version 5.3.0 (Win7). Bug already exists in version 3.3.0. Hence inherited from OOo.
Tested out clicking the various tree objects in the navigator and there wasnt any real benefit to it, so i'd suggest this be fixed for the limited amount of users who would ever stumble on this functionality. @Heiko, @Stuart, @Cor: Your thoughts?
Following STR of comment 0 the issue is reproducible in 5.3.1 However, it does not manifest with Navigator's Sidebar Deck instance. On the other hand if the Sidebar is undocked, it is still treated as part of the main program frame. Meaning it is not Navigator code (common to the two Navigator instances) but rather that an active window other than the main program frame has focus. The Macro related "edit" and "organize" dialogs launched from Tools -> Macros have the same behavior when focused and F1 launches the associated Help content. With Navigator (F5 instance) active, simply shift focus back to the program main frame and document canvas the F1 help points to the appropriate help article for the main frame. So, question if this should be considered a bug. When a program element other than the main frame has focus--as does Navigator with F5 launch--what should be the target for an F1 contextual help query? I'd say it works correctly now--no reason to change -> NOTABUG. Although we may have some work with the on-line help on correctly instrumenting help for the Sidebar deck's content panels--they are missing now.
(In reply to Yousuf Philips (jay) from comment #12) > @Heiko, @Stuart, @Cor: Your thoughts? My position with the current Navigator is clear: tear down and build new from scratch [1,2] (I believe this issue here results from an unclear definition of what the Navigator is good for). Stuart's statements assume that the help browser is an internal window which is wrong, IMHO. At least most programs I know run help in an extra browser window. If help content goes internal, which makes sense on the other hand, it needs a default look and feel like any other document. In sum I wouldn't put too much effort in removing an annoyance for a few users from a feature that needs to get reworked completely. If we continue with the current workflow/UX we should move all sidebar navigation from the help form into the Navigator to become consistent. As a side note: the floating Navigator is hidden when the help form receives the focus. Both variants are not updated immediately (bug is filed IIRC) and start with the current document e.g. 'Untitled 1' meaning you have to switch to 'Active Window' in order to see the help content. [1] https://design.blog.documentfoundation.org/2016/07/31/how-the-navigator-may-support-object-handling-in-libreoffice-draw/ [2] http://pad.documentfoundation.org/p/UX-GSoC_Ideas (#7)
If it helps the understanding of the bug, the Help window (F1) is a UI-tweaked Writer/Web displaying a XHP file transformed into HTML 3.2 by a XSLT transformation. That explain why the navigator is showing the help page structure.
(In reply to Heiko Tietze from comment #14) > > Stuart's statements assume that the help browser is an internal window which > is wrong, IMHO. At least most programs I know run help in an extra browser > window. If help content goes internal, which makes sense on the other hand, > it needs a default look and feel like any other document. > > In sum I wouldn't put too much effort in removing an annoyance for a few > users from a feature that needs to get reworked completely. If we continue > with the current workflow/UX we should move all sidebar navigation from the > help form into the Navigator to become consistent. > Hmm, not sure I'd agree--adjustments to Navigator is not the issue. The real *issue* is the behavior of the F1 "built-in" Help as a component of the GUI (a Writer/Web instance), and to some extent the derived media-wiki "online" help. So it is not the F1 help for any one pop-up dialog window (Navigator in this case)--but rather the help article that is being displayed in response to an F1 action (as indexed and linked). I do not find getting F1 help for the Navigator when it has focus to be incorrect--and when focus is shifted back to the document the element from the document becomes the F1 target. So in this case for Navigator linked articles are correct, but the user has the wrong element active in GUI--a user error, yet they complain. While for the Tools -> Macros related dialogs the F1 linked articles are what the user needs, so no complaint. In short the help system is behaving correctly in both instances. And yes we could probably send the associated Help articles to a system default HTML browser rather than our own pop-open viewer, but our existing help viewer is functional--its search capability is superior to the current web delivered media-wiki content. And as Oliver notes it is XSLT parsed from associated XHP the HTML "style" could be adjusted--even brought current with CSS3 and HTML5 if that facilitates a better match between "built-in" local and "online" web delivered help. So the ongoing *issue* is assuring the correct XHP (or its replacement as for bug 97629) is authored and is indexed/linked to the GUI element we need F1 response for. IMHO we have always done this correctly here and this should be closed NOTABUG or WONTFIX. The dialog introduced for bug 103391 now alerts that the "built-in" help is not installed and that they can read help online. But the help system must still have correct index and linkage for the element receiving F1 action. Additionally, we are missing appropriate F1 linked articles for the Sidebar elements introduced since this bug was submitted, and lately for the new Notebook Bar elements of MUFFIN--so the help system (built-in and online) has degraded in that sense.
With the new help system this bug does not appear no longer. Checked with version 6.1.4 (64 bit, Win 10). Set status to WORKSFORME.