Download it now!
Bug 43020 - Help Viewer document structure shown in Navigator
Summary: Help Viewer document structure shown in Navigator
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Navigator Help-Viewer
  Show dependency treegraph
 
Reported: 2011-11-17 02:55 UTC by Harald Koester
Modified: 2019-01-24 10:07 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Screen shot of Wrinter Window (110.72 KB, image/png)
2012-09-07 21:07 UTC, Harald Koester
Details
Screen shot of help Window (83.48 KB, image/png)
2012-09-07 21:10 UTC, Harald Koester
Details
HelpInNavigator screenshot (11.04 KB, image/png)
2012-12-14 14:15 UTC, pierre-yves samyn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Koester 2011-11-17 02:55:28 UTC
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
Comment 1 sasha.libreoffice 2012-02-16 06:48:26 UTC
Reproducible in 3.6.0 master. But my be so should be by some reason?
Comment 2 Joel Madero 2012-09-07 20:29:27 UTC
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
Comment 3 Harald Koester 2012-09-07 21:07:05 UTC
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).
Comment 4 Harald Koester 2012-09-07 21:10:19 UTC
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.
Comment 5 pierre-yves samyn 2012-12-14 14:13:11 UTC
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
Comment 6 pierre-yves samyn 2012-12-14 14:15:05 UTC
Created attachment 71502 [details]
HelpInNavigator screenshot
Comment 7 Harald Koester 2015-01-13 09:06:32 UTC
Bug still exists in version 4.3.5 and 4.4.0.2 (RC2).
Comment 8 QA Administrators 2016-01-17 20:05:21 UTC Comment hidden (obsolete)
Comment 9 Harald Koester 2016-01-18 19:25:54 UTC
Bug still exists in version 5.0.4 with Win7.
Comment 10 QA Administrators 2017-03-06 14:40:26 UTC Comment hidden (obsolete)
Comment 11 Harald Koester 2017-03-15 22:58:01 UTC
Bug still exists in version 5.3.0 (Win7).
Bug already exists in version 3.3.0. Hence inherited from OOo.
Comment 12 Yousuf Philips (jay) (retired) 2017-03-16 11:27:02 UTC
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?
Comment 13 V Stuart Foote 2017-03-16 16:01:29 UTC
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.
Comment 14 Heiko Tietze 2017-03-18 09:30:04 UTC
(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)
Comment 15 Olivier Hallot 2017-03-18 10:11:19 UTC
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.
Comment 16 V Stuart Foote 2017-03-18 13:44:21 UTC
(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.
Comment 17 Harald Koester 2019-01-24 10:07:21 UTC
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.