Closed Bug 478913 Opened 11 years ago Closed 11 years ago

Some Help buttons (e.g. in Message Filters dialog) bring up empty Help window (Help file not found)


(SeaMonkey :: Help Documentation, defect)

Not set


(Not tracked)



(Reporter: InvisibleSmiley, Assigned: InvisibleSmiley)



(1 file)

With a current nightly I see the following when pressing the Help button in e.g. the Message Filters, Search Messages or Advanced Address Book Search dialogs:

1. an empty Help window comes up (empty window title, sidebar and content pane)
2. the Error Console says:
  Help file:  was not found.
  TypeError: datasource is undefined

Counter example: the Help button in the Filter Rules dialog (which is used to create/edit filter rules) works. The difference here is that the Filter Rules dialog is connected to helpMessengerOverlay.xul (see /suite/common/ line 39) which calls setHelpFileURI() (see line 45) which has the effect of making the second parameter to openHelp() optional (cf. Toolkit's contextHelp.js line 48). 

Ratty (who helped with the analysis) suggested to call setHelpFileURI() in utilityOverlay.js but I wonder if simply moving the broken dialogs over to using helpMessengerOverlay.xul is the better way to go.

This should help finding the affected files:
whereas these are not affected:
Using helpMessengerOverlay.xul is probably not advisable, it seems it's only for dialogs that have buttons at the end of the dialog. :-/ Just adding the second parameter for the few places where it currently doesn't work is probably enough (existing examples that do it this way are the Password Manager and the Permission Manager).

Already mentioned places:
- Message Filters [FilterListDialog.xul]
- Search Messages [SearchDialog.xul]
- Search Addresses [ABSearchDialog.xul]

More places that need fixing:
- Compose window > Options > Security > (Encrypt|Digitally Sign) This Message: when no personal certificate is set up for the active identity, an alert is shown asking whether one is willing to learn how to set it up. OK then opens a (currently blank) Help window. [msgCompSMIMEOverlay.js, msgCompSecurityInfo.js]

What I'm asking myself is: How can we prevent this from happening in the future if Help buttons are added elsewhere? It's not obvious where the second parameter is needed and where not. I think it would be best if setHelpFileURI() would be called in such a way that openHelp() just works with a single parameter from everywhere in the front end.

That having said I'll attach a patch that fixes the above places the simple way. Let's see what the reviewer says.
Asking for 2a3 approval for the simple fix; another approach might be desired for the longer term
Assignee: nobody → jh
Attachment #362772 - Flags: superreview?(neil)
Attachment #362772 - Flags: review?(neil)
Attachment #362772 - Flags: approval-seamonkey2.0a3?
I have to admit that I first missed the help buttons in those windows since they don't really look like the normal mac help buttons (I just took a quick glance at the bottom of the windows and expected to see the shiny question mark button).
Comment on attachment 362772 [details] [diff] [review]
Add second parameter where needed

The difference between the Filter Rules dialog and the Filter Editor dialog is that the former is forked so we weren't forced to overlay the help button.
Attachment #362772 - Flags: superreview?(neil)
Attachment #362772 - Flags: superreview+
Attachment #362772 - Flags: review?(neil)
Attachment #362772 - Flags: review+
Attachment #362772 - Flags: approval-seamonkey2.0a3? → approval-seamonkey2.0a3+
Comment on attachment 362772 [details] [diff] [review]
Add second parameter where needed

As we're waiting for a orangeness fix anyway, a=me for closed a3 tree as long as it lands within a few hours.
Pushed as for a3 still.
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.0a3
You need to log in before you can comment on or make changes to this bug.