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"
nominating for nsbeta1+ doc team can create patch for this and steer through reviews.
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?
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
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.
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.
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).
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.
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 on attachment 74837 [details] [diff] [review] real deal + cookieviewer logic r=morse
Attachment #74837 - Flags: review+
Keywords: nsbeta1 → nsbeta1+
Comment on attachment 74837 [details] [diff] [review] real deal + cookieviewer logic sr=alecf
Attachment #74837 - Flags: superreview+
setting priority & target
Priority: -- → P3
Target Milestone: --- → mozilla1.0
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+
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Verified fixed win XP build 2002041011. linux build 2002041109 and Mac OS X build 2002041105
Status: RESOLVED → VERIFIED
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.