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.
This should go on the top level task menu as well. Make it really discoverable.
Putting on [nsbeta2-] radar. Not critical to beta2.
Pushing post beta2
Target Milestone: M18 → M20
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.
Summary: Need "Prefill Form" menu item on context menu → Need "Prefill Form" menu item on context menu and tasks menu
nsbeta3 changing subject to say context menu and tasks menu. Should be just below "Privacy and Security >" before the separator line.
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.
Assignee: morse → german
Status: ASSIGNED → NEW
Summary: Need "Prefill Form" menu item on context menu and tasks menu → Need "Prefill Form" menu item on context menu and main menu
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.
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.
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).
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.
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.
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"
Assignee: german → morse
Summary: Need "Prefill Form" menu item on context menu and main menu → Need "Prefill Form" menu item in edit menu
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
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.
Marketing has nixed the term "wallet". It is never used anywhere anymore.
Status: NEW → ASSIGNED
Target Milestone: M20 → M18
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
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
dbragg reviewed my changes so I have now checked them in. Closing as fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
BTW, I added the items to both the edit menu and the right-context menu.
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...
Status: RESOLVED → VERIFIED
Assignee: morse → nobody
Component: Form Manager → Form Manager
Product: Core → Toolkit
QA Contact: bugzilla → form.manager
Target Milestone: M18 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.