Add Help buttons to Form Manager windows

VERIFIED FIXED

Status

()

Toolkit
Form Manager
P3
normal
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: Sean Cotter, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

17 years ago
Context-sensitive help text is checked in for the Form Manager windows. 

Ian Oeschger has agreed to create a patch that adds help buttons to these windows:

Prefill Form window
(Edit menu/Prifill Form Data when you're viewing a form and some stored data is
available)

target = "forms_prefill"


Form Manager window (for managing stored data)
(Edit menu/Preferences/Privacy & Security/Forms, then click Manage Stored Form Data)

target = "forms_data"


Form Manager window (for managing stored site info)
(Edit menu/Preferences/Privacy & Security/Forms, then click Manage Sites)

target = "forms_sites"
(Reporter)

Comment 1

17 years ago
nominating for nsbeta1+

doc team can create patch for this and steer through reviews.
Keywords: nsbeta1

Comment 2

17 years ago
Created attachment 74642 [details] [diff] [review]
patch for form manager help buttons

Comment 3

17 years ago
I have a few questions regarding the patch posted here:

1. WalletViewer.xul

Where is the linkage to the doHelp function?  Don't you need to add something 
that specifies that the doHelp function is to be invoked when the help button is 
pressed?

Any js code added to this dialog should go into WalletViewer.js and not 
WalletViewer.xul

2. SignonViewer.xul

Any js code added to this dialog should go into SignonViewer.js and not 
SignonViewer.xul

SignonViewer dialog can run in either password manager mode or form manager 
mode.  You'll need a different help text for each and you'll have to dynamically 
figure out which one to associate with the help button when the dialog starts.  
Search for isPasswordManager in SignonViewer.js to see what I'm talking about.

3. WalletPreview.xul/js

Why do you have both a function doHelp which calls openHelp and also 
ondialoghelp which does its own direct call to openHelp?  Isn't only one ever 
used?

Comment 4

17 years ago
Created attachment 74670 [details] [diff] [review]
update to button patch

A1. The set of buttons you get from okCancelHelpButtonsRight calls
doHelpButton() back on the window (not doHelp()!, as I had it earlier. riddled
with errors!). If you use this method of overlaying help buttons, you need only
implement the doHelpButton function. 

A2. I will do the logic for the subframe thing in SignonViewer, but I will need
to hear from Sean if he has a target in mind for the password manager, which I
didn't realize might also be using this file.

I have done doHelpButton() in the script rather than the XUL file in both of
the cases you mention. 

A3. The redundancy in WalletPreview.xul/js was just an effect of not saving my
XUL file before running the diff: I was trying to decide which direction to
take.

Thanks for looking at this, Steve.
Attachment #74642 - Attachment is obsolete: true

Comment 5

17 years ago
OK, I can't give an r= until I see the change you make for signon viewer 
regarding the choice of help functions.  Also I can't r= it until you tell me 
that it's been tested and that it works.
(Reporter)

Comment 6

17 years ago
You are right, Password Manager should also have a button and target. Sorry for
the oversight.

The target will be "password_mgr" and I'll have text & ID checked in by tomorrow.

Comment 7

17 years ago
Created attachment 74800 [details] [diff] [review]
the real deal

This update includes the logic for determining whether signonviewer is loading
password manager or form manager. built and tested (with a different ID until
sean check's in his password id).

Updated

17 years ago
Attachment #74670 - Attachment is obsolete: true

Comment 8

17 years ago
You have exactly the same problem with the CookieViewer.js.  That dialog is 
shared between the cookie manager and the image manager, depending on how it was 
invoked.  Look at the variable isImage in that file.

I realize that this is outside the scope of the current bug, but since it is the 
identical change that you are making here, it might make sense to do it all at 
the same time.

Comment 9

17 years ago
Created attachment 74837 [details] [diff] [review]
real deal + cookieviewer logic

That's funny. This is UI that is present in Mozilla but removed for Netscape.
Not used to it. Sean is checking in a new target, "image_mgr". Tested and
working.

Comment 10

17 years ago
Comment on attachment 74837 [details] [diff] [review]
real deal + cookieviewer logic

r=morse
Attachment #74837 - Flags: review+

Comment 11

17 years ago
nsbeta1+
Keywords: nsbeta1 → nsbeta1+

Comment 12

17 years ago
Comment on attachment 74837 [details] [diff] [review]
real deal + cookieviewer logic

sr=alecf
Attachment #74837 - Flags: superreview+
(Reporter)

Comment 13

17 years ago
setting priority & target
Priority: -- → P3
Target Milestone: --- → mozilla1.0

Comment 14

17 years ago
Comment on attachment 74837 [details] [diff] [review]
real deal + cookieviewer logic

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #74837 - Flags: approval+

Comment 15

17 years ago
FIXED
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 16

17 years ago
Verified fixed win XP build 2002041011. linux build 2002041109 and Mac OS X
build 2002041105
Status: RESOLVED → VERIFIED

Updated

10 years ago
Assignee: oeschger → nobody
Component: Form Manager → Form Manager
Product: Core → Toolkit
QA Contact: tpreston → form.manager
Target Milestone: mozilla1.0 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.