42438 - Need "Prefill Form" menu item in edit menu

Status: VERIFIED FIXED

(Toolkit :: Form Manager, defect, P3)

Description

[Daniel Veditz [:dveditz]]

For convenience and discoverability we need a "Prefill Form" menu item on the 
right-click context menu, which should do the same things as the "Prefill 
Safely" item under the "Tasks | Privacy [...] | Form Manager" menu.

Comment 1

[Stephen P. Morse]

This should go on the top level task menu as well.  Make it really discoverable.

Comment 2

[leger]

Putting on [nsbeta2-] radar. Not critical to beta2.

Comment 3

[Stephen P. Morse]

Pushing post beta2

Comment 4

[Matthew T (active 1999-2002)]

W.r.t the main menus, this belongs in the `Edit' menu, not the `Tasks' menu. The 
Tasks menu is used for stuff which is conceptually `outside' the current page 
(mail, history, other tools with their own windows, various `managers', etc); it 
is not where you go to find stuff relating to the editable contents of the 
current page.

Comment 5

[johng]

nsbeta3

changing subject to say context menu and tasks menu.  Should be just below 
"Privacy and Security >" before the separator line.

Comment 6

[johng]

reassigning to german to get his point of view about whether this should be 
under "Tasks" or "Edit" on the main menu bar - mpt has a good point.

Comment 7

[Matthew T (active 1999-2002)]

It's even worse than that ... This function is going to suffer from the 
invisibility problem. Because the Edit menu (or the Tasks menu, for that 
matter) is closed during normal browsing, I'm never going to be realize when 
Mozilla is able to fill in a given form.

I see two possible solutions to this.
1.  Use a transitory toolbar -- one which only appears when you're in a
    pre-fillable form, and disappears afterwards. Like the one which will be
    used for LINK element navigation. (Wasn't this the original idea, anyway?
    The `German line', I think it was called.)
2.  Use auto-complete, instead of pre-filling, for form elements.

Comment 8

[Stephen P. Morse]

There's a lot of talk here about placing the prefill-form button in other places 
to make it more usable (context menu, german line, etc).  But what about the 
capture button.  Wherever the prefill button is placed, the capture botton 
should be as well.

Comment 9

[german]

I am still hoping we can materialize a transitory toolbar, that would offer 
enough space for some assisting text as well as the button(s).

Comment 10

[Daniel Veditz [:dveditz]]

The difference between prefill and capture is that the form manager often 
recognizes forms and prompts the user to save the values, or the user has done 
the complete interview and has already set all their values so there really is 
no more to capture.

Pre-fill is never done automatically, and users will do it much more often than 
capturing data. In fact I would imagine after the first couple of weeks of 
using the feature they will never capture again, but still use prefill. Or 
maybe I'm misunderstanding the feature.

Comment 11

[Tim Hill]

I agree -- I think the form manager right now is next to useless as long as its 
activation remains so far away (Tasks > Privacy and Security > Form Manager) 
from the context in which it's actually going to be used.

German, what are the current plans for the transitory toolbar?  I think there 
are a few issues that need to be considered when designing this:
1. How much space it should take up when visible, minimizing the proportion of 
chrome to content, but allowing enough room for the necessary features.
2. Whether it should shift the content area when it is initially shown.  
Shifting the content area is a bit disconcerting and annoying.

I'm currently working on a transitory toolbar for Bug 2800 (the LINK tag), and 
these issues really need to be addressed for that as well.  (See 
http://www.prismelite.com/linktag/ for screen shots of it)  Right now, it 
appears in the Navigation toolbar under the URL field.  As you can see from the 
screen shots, the squeeze into this area is a bit tight.  But the advantage is 
that it doesn't take up a lot of space, or shift the content area.

Besides deciding where the toolbar is going to go, I think the other issues for 
this bug are:
- What the toolbar buttons should be.  Perhaps instead of separate buttons, 
there could be a menubutton called "Form" which shows all the necessary menu 
items pertaining to a form ("Fill in...", "View Saved Information...", "Save 
Current Information...")
- When it should appear.  Is it basically enabled for all HTML forms?  Perhaps 
it could be shown on page load whenever a page has forms... or only when a form 
element receives focus.  A method for determining whether a given form already 
has saved information would be required to enable/disable the appropriate menu 
items.

Comment 12

[johng]

nav triage team:
nsbeta3+ to add something to the edit menu.

tbd what we add:
do we just add "PRefill Form with Captured Data" or also add "Capture Data from 
Form"

Comment 13

[Daniel Veditz [:dveditz]]

What about the right-click context menu, too?

Re: my comments of 7/23: Steve has explained that capturing form data is page 
specific and that if plain pre-fill from wallet data didn't work well you 
would in fact want to capture data for that specific page. Since it was 
unclear to me before I thought I'd mention it here, it means capturing could be 
a much more common activity than I first thought.

Do we use the term "wallet" anywhere in public? "Prefill form from wallet" is 
shorter and friendlier than "Prefill form from Captured Data". Certainly 
it's a marketing and wordsmith call and I don't want to reopen a dead snake if 
this has been hashed out (sorry, I got involved with this feature only well 
after PR1), but I'd think a metaphor like wallet would be a lot easier to 
explain and catch on than something as abstract and imposing as "Captured 
Data".

Maybe it's the high-falutin' "Captured" that's throwing me, maybe something 
simple like "saved" would be better.

"Prefill form with saved data" (values?) and "Save form data". Having the 
two together would also help explain the feature in addition to the 
convenience and need to capture data. A lonely "prefill form" menu item raises 
the question of "prefill with what?"

I've gone well over my $0.02 budget so I'll quit now.

Comment 14

[Stephen P. Morse]

Marketing has nixed the term "wallet".  It is never used anywhere anymore.

Comment 15

[german]

I recommend we add the menu item to Edit menu that says "Prefill Form" (JohnG's 
suggestion is a bit too wordy, a static menu item should not have more than 3 
words if possible). We have to make this item properly disabled when page does 
not contain a form.
I would only add "Save Form Data" (like dveditz wording suggestion here - short 
and friendly) if we can properly disable this item when a) we are not on a form 
and b) when the form is empty. If the item stays "enabled" all the time it is 
rather confusing for the end user what it does. If we can't do proper enabling, 
than I'd rather not clutter the edit menu with this item. This second item also 
requires proper feedback in a small message, stating something like

Your data on this form has been saved for later reuse.

[ ] don't show me this message again 
                                       [   OK   ]

suggested position for the menu items (if we do both):
...
Select All
------------
Prefill Form
Save Form Data
------------
Preferences

if we do only the form fill item:
...
Select All
------------
Prefill Form
------------
Preferences

Comment 16

[Stephen P. Morse]

Making this fix in two stages.  Stage 1 is a cleanup of current modules to make 
the requested menu change easier to accomplish.  Stage 2 is the actual menu 
change.  I am going to attach the diffs for each stage to this report along with 
a description that will make it easy to code review.

The problem that is being addressed in stage 1 is the dialog that needs to be 
put up if there is nothing to prefill.  Currently that dialog is put up by the 
javascript code that is calling the c++ prefill routine in wallet.cpp.  If the 
prefill routine is going to be called from more than one place, then each such 
place will have to put up its own dialog.  This is bad and the dialog should be 
put up in the wallet.cpp routine instead.  In fact, it used to be there but was 
moved out due to problems with finding a parent window for the modal dialog.  
That problem has since been solved so the dialog can and should be moved back to 
wallet.cpp.

The changes to accomplish this are to add another parameter to the prefill 
routine -- that parameter being the parent window.  The changes involving this 
added parameter are in:

   extensions/wallet/public/nsIWalletService.idl
   extensions/wallet/src/nsWalletService.cpp
   extensions/wallet/src/wallet.h
   extensions/wallet/src/wallet.cpp

Two points to note:

1. The prefill routine used to take a boolean parameter called doPrefillMessage.  
That parameter is no longer needed and has been eliminated.

2. Logic in wallet.cpp's capture routine was improved slightly so that we can 
now tell if all the fields contains null values in which case nothing is 
captured.  This enables us to put out a more informative alert message.

Finally the caller of all this needs to be modified so it passes the window 
parameter.  This change is in

   nsBrowserInstance.cpp

Comment 17

[Stephen P. Morse]

Attachment: stage 1 changes for code review

Comment 18

[Stephen P. Morse]

Oops, I'm not through with stage 1 changes yet.  I need to remove the dialog 
from the javascript.  That change is in

   xpfe/communicator/resources/content/taskOverlay.js

And while I'm at it, I might as well clean up the appearance of the task menu a 
wee bit.  Those changes are in

   xpfe/communicator/resources/content/taskOverlay.xul
   xpfe/communicator/resources/locale/en-us/tasksOverlay.dtd

I'll attach this as stage 1.5 changes.

Comment 19

[Stephen P. Morse]

Attachment: stage 1.5 changes for code review

Comment 20

[Stephen P. Morse]

And now for stage 2 -- the actual addition of the wallet items to the edit menu.  
The files changed now are:

   
   xpfe/browser/resources/content/navigatorOverlay.xul
   xpfe/communicator/resources/content/utilityOverlay.xul
   xpfe/communicator/resources/content/utilityOverlay.js
   xpfe/communicator/resources/locale/en-us/utilityOverlay.dtd

Comment 21

[Stephen P. Morse]

Attachment: Patch to fix stage-2 problem

Comment 22

[Stephen P. Morse]

dbragg reviewed my changes so I have now checked them in.  Closing as fixed.

Comment 23

[Stephen P. Morse]

BTW, I added the items to both the edit menu and the right-context menu.

Comment 24

[sairuh (rarely reading bugmail)]

Save Form Data and Prefill Form are now in the Edit menu.

i've mentioned this earlier (either in person or over irc), but i'd've
preferred, ideally, to have the entire Privacy & Security submenu moved from
Tasks to its own toplevel menu (as it's rather long, and trowling thru it
presently is annoying to get something done). i'd rather not add these to the
Edit menu (since i associate *common* editing tasks there)... the context menu
is okay, but, again depending on the webpage (or frame) content, the context
menu can get quite long. *sigh* sorry to be such a lurker/complainer here.

however, thx to blake for filing bug 48860 --which might address my issues
above...