268353 - Built-in Help cannot be extended without using a separate content pack

Status: NEW

(SeaMonkey :: Help Viewer, enhancement)

Description

[Ondrej Donek]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; cs-CZ; rv:1.7.3) Gecko/20041027 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs-CZ; rv:1.7.3) Gecko/20041027 Firefox/1.0RC1

I am developed one extension and in the final step I want to add help into it.
My plan was simple - create index/toc/glossary/html and other needed files and
register them through overlays into the Firefox so the original Firefox index
help file will be extended with my new content and end user will be used only
one help. But it doesn't work.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Actual Results:  
I create my new help content and display it when I calling helpViewer in right
way but if I want see the standard Firefox help in the same time I need another
one helpViewer with original content.

Expected Results:  
Original help content extended by help of new extension.

I think that the main problem is in this file: 
chrome:\\help\content\help.js
where on line 48 I founded this: 
const defaultHelpFile = "chrome://help/locale/help.rdf";
So I consider this is the main fault.

Comment 1

[Jeff Walden (gone starting June 8)]

Check out this document, which should tell you how to do things:

http://www.mozilla.org/projects/help-viewer/content_packs.php

Comment 2

[Met - Martin Hassman]

Jeff>As I understund
http://www.mozilla.org/projects/help-viewer/content_packs.php is about using
Help for your own application, not about how to extend (add you theme) to the
Mozilla Help (without editing mozilla help files).

So probably this bug really IS NOT invalid.
It can be WONTFIX, if you do not want to implement it, but please consider, if
there is good reason for wontfixig.

Comment 3

[Jeff Walden (gone starting June 8)]

If you mean integrate your Help docs directly into Firefox Help docs so that the
two are indistinguishable when accessed via F1, then no, that won't help you
(probably intentionally, but I think similarly regardless of the reasons this
hasn't been implemented).

It does, however, describe how to create Help docs for a Firefox extension in
such a way that you can access them through the Help Viewer (tho not through the
exact same method used by the built-in Help).  You can create Help docs, make
them accessible through chrome (but *not* by selecting Help>Help Contents or by
pressing F1), and use all the features of the Help Viewer.  If you need more,
post here and we can consider.  Right now, tho, it seems you don't understand
exactly what the document describes.

Comment 4

[Met - Martin Hassman]

>It does, however, describe how to create Help docs for a Firefox extension in
>such a way that you can access them through the Help Viewer

Yes, I know. We have tested it with Ondrej and it is working for us, but seems
not fully suitable for our purpose.

> If you need more, post here and we can consider.

May be, we was unclear before. Well, we want more.
The summary of tihs bug should be probably be something like "Add another pages
to the Help" (but I have no rights to change it).

>Right now, tho, it seems you don't understand exactly what the document 
>describes.

I hope, I have understood it, but you have misunderstood our request 8-)

Example: Assuming somebody is creating extension e.g. some CMS for some company.
It is for begginer users. They do not know exactly about difference what is
still the Firefox browser and what is the extension. Somebody have installed it
for them, they are using it together. For such reason they do not understand two
different Helps. They want one help with all entries.

This is our request ad please consider if this can/cannot be implemented. 

Implementation detailes proposal:

It should work in similar way like you contentc-pack - directory with the
yourApp.rdf, myApp-toc.rdf, myApp-index.rdf etc. Installed extension which want
to include own help to the browser it should registed this directory somehow
(overlay, registering during startup etc.).

Browser displaying help will try to put these helps together (combine topics,
index, search.). Yes, there are some point like use non-interfering ID etc. I
don't know if it is easy to implement this.

Consider yourself, but I think this bug should be reopened as enhancement bug (I
hope with the Firefox penetration to the companies, there will be more such
requests) or otherwise wontfixed.

Comment 5

[Jeff Walden (gone starting June 8)]

Okay, so you want to be able to make a Help extension completely
indistinguishable from built-in Help.  I'm still mostly against this, but we
might as well see what someone else working on Help has to say about it.  CCing
Neil to see if he's had any experience with this in Seamonkey...

Comment 6

[Ondrej Donek]

(In reply to comment #5)
> Okay, so you want to be able to make a Help extension completely
> indistinguishable from built-in Help.  I'm still mostly against this, but we
> might as well see what someone else working on Help has to say about it.  CCing
> Neil to see if he's had any experience with this in Seamonkey...

Simply - all topics in one place for simply users.(In reply to comment #5)
> Okay, so you want to be able to make a Help extension completely
> indistinguishable from built-in Help.  I'm still mostly against this, but we
> might as well see what someone else working on Help has to say about it.  CCing
> Neil to see if he's had any experience with this in Seamonkey...

Yes - shortly I only want add few topics into existing help.

Comment 7

[[e-mail]]

I was trying to think of a way to do this for SeaMonkey so that we could have a
platform help index overlay... somewhere we would have a list of help indexes
and just merge them all together in the normal RDF way of things.

Comment 8

[Ondrej Donek]

Reopen according to the comments bellow for considering of possible implementation.

Comment 9

[[e-mail]]

What I'm thinking is that if the help window finds that it's displaying default
help then it looks up additional help documents in some sort of registry,
possibly as simply as a chrome overlay of help.xul that appends an element to an
array. Then when the help window loads the datasources all the sources from all
the registered documents get loaded.

I don't think we want to overlay non-default help to avoid potential problems.

Comment 10

[R.J. Keller]

(In reply to comment #9)
> What I'm thinking is that if the help window finds that it's displaying default
> help then it looks up additional help documents in some sort of registry,
> possibly as simply as a chrome overlay of help.xul that appends an element to an
> array. Then when the help window loads the datasources all the sources from all
> the registered documents get loaded.
> 
> I don't think we want to overlay non-default help to avoid potential problems.

What kind of registry are you thinking? We might be able to include some kind of
chrome registry attribute like overlayHelp="true" and if that equals true, look
for help.rdf that contains the content pack to overlay to help. When the chrome
is registered, we could store all of the help overlays into some kind of
datasource file that can be read from. It'll be a bit messy any way you try and
tackle it though.

A workaround might be to hide the Help menuitem and make your own menuitem that
overlays the Help menu. That menuitem can open help with your content pack that
can inherit mozilla's content pack. The issue with this though is if you have 2
extensions overlaying help, it'll mess things up a bit.