From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0+) Gecko/20020510 BuildID: 2002051008 This is a continuation of bug 135919 which was (in my opinion) wrongly marked as a duplication of another bug. Please do NOT mark this bug as a duplicate of bug 135919. One or the other of them needs to remain open. Essentially, with the absence of prefill form from the new context menus there is no easy way of doing this. The prefill form should be a) added back to the context menus, b) given a keyboard shortcut, c) have double-click expanded to include the whole form rather than just the form field (and "fixed" so that it works at all on the Mac, and/or d) the UI needs to be modified to show users an easy/intuitive way of doing this rather than via the menus. Reproducible: Always Steps to Reproduce: 1. Try to prefill a form easily. Assume you do not know where to locate this within the menus. Actual Results: It is confusing and laborious to do so now that it is not in the context menus. Expected Results: It should be in the context menus, in a keyboard shortcut, and/or easily locatable via the UI.

You are making several points in one bug. This is not helpful.

This bug is about having an obvious way to prefill a form. There are several different ways of accomplishing this. So long as one of them is implemented the bug will be fixed. There needs to be discussion to determine which of these methods is the most appropriate.

If a prefillable field appeared as an editable combobox (ala the urlbar) when the caret was in it, would that suffice?

timeless: I think what Jason is asking for is a way to prefill the entire form, not just a single field.

Yes. You can already double-click (in Windows anyway) on a form field and have it prefill that one field. I'm looking for a way to prefill the entire form (all fields). If double-click were expanded to the whole form that would be one possible solution. If that would generate complaints about having just the one field filled then comment 3 in addition would offer a good compromise.

Although I would very much like to see a keyboard shortcut for prefilling the whole form (as well as a keyboard shortcut for saving the form data), I am not sure that a keyboard shortcut qualifies as being obvious. It is definitely more convienent than the current method via the menu -- especially when the menu is not accessible. Adding these form field commands back to the context menu really seems to be the all around best solution to this problem. The form is a context and these commands are directly related to that context. Previously, in related bugs, I have been told that form fields are not context sensitive "by design" (despite the fact that text fields are context sensitive) but I have not heard the rationalization of that design decision.

While I personally agree that putting the prefill form data back into the context menus is the most sensible and obvious solution, bugs related to that have all been marked WONTFIX so, unless there is some way of changing this decision, I believe that using the context menus is not a viable solution here. As for a keyboard shortcut not being obvious, you are correct. But I believe it might be obvious "enough" if the text for the shortcut were included to the right of the menu entry for the action. (E.g. "Fill in Form Ctrl-Shift-F," or whatever the shortcut ended up being.) The idea here is that I believe enough people find this function useful enough that there be some method, other than the menu, by which they can do this. Listing that method in the menu (assuming that it is put in place) would be enough to elevate it from the status of a "hidden function", which is what double-click in a form field is at present. (BTW: I understand that double-click in form fields is now functional on the Mac.) Another alternative, in line with comment #3, is to have "Fill in Form" (rather than just the data for the field itself) listed in a dropdown combo box for the form field itself. That, too, would be an acceptable solution to me.

Of course another possibility is to have a form toolbar that appears only when a form is being displayed. This is the way roboform (a third-party add-on for IE) and our own obongo (add-on for both IE and mozilla) do it. The code for a form toolbar already exists in the codebase and was functional but it is currently commented out.

That sounds all right too. So long as there's something that lets you easily get to the prefill data. In fact, this seems to offer the most flexible solution - it could provide a host of easily reached form functions.

I can't decide if this bug blocks bug 48860 or is a duplicate of it. So I'll mention http://www.mozilla.org/projects/ui/communicator/browser/formfill/ and http://www.mozilla.org/projects/ui/communicator/browser/formfill/Notes_1_25_01.html instead.

> I can't decide if this bug blocks bug 48860 or is a duplicate of it. As per bug 48860 comment 7, this bug should be marked as blocking that. > http://www.mozilla.org/projects/ui/communicator/browser/formfill/ Bingo. Just what has been discussed here. However, it's a little difficult to mark a bug as being dependent on a project so I believe this should stay open so long as the project does... (There may be other means of addressing this bug too, even if the project is one of them. E.g. If prefill were returned to the context menus or a keyboard shortcut were introduced, and the menu UI were suitably modified to indicate their existence.)

*** Bug 136037 has been marked as a duplicate of this bug. ***

*** Bug 146885 has been marked as a duplicate of this bug. ***

+1 vote for the prefill feature. Missing from Mozilla v1.1a

How about if you triple-click a form field, the all form fields that can be prefilled are prefilled?

Has a triple-click ever been used for anything? I think that would be too confusing...

> Has a triple-click ever been used for anything? Selecting an entire document in Word. I think that says something about the intuitiveness of this shortcut.

Thank you very much.

uid is being phased out.

this USED to be easy ...

I do not vote for double or triple clicking on the field. Sometimes form manager stores more values for that field and user has to have choice to select what value to fill in. I prefer to have pop up window with values shown before they are filled into the form.

dveditz is the new module owner, reassigning.

*** Bug 188317 has been marked as a duplicate of this bug. ***

How would people feel if the behaviour was that double-clicking on a form opened up the Fill-In Form dialog instead of filling in the current field (which I didn't know it did until now), and possibly having an option so people can choose between double-click to fill in field and double-click to open Form Manager?

I would have no problem with double-click on a "Form Manager" dialogue / menu (or whatever) so long as "Fill in Field" is one of the items I could select. (Currently, there is no such item listed in Tools -> Form Manager.) I would object to another preference to choose between the two actions, especially if with, one more click, you could fill in the field anyway. The bottom line of this bug is that I don't want to have to move my mouse from the form I'm currently looking at all the way up to the top of the browser. If I can double-click on the form and either immediately get the form field filled in, or gain access to something else next to my mouse pointer that does the same thing, that's all I want. (If fact, having a Form Manager dialog appear is even better because it would let me do multiple things.)

> If I can double-click on the form and either immediately get the form field > filled in, I "mistyped" myself. Of course, I know that this already works. I'd meant to simply say that I'd like to be able to double-click (or whatever with my mouse) on the form where I am and get *all* of the form functionality I need without moving up to the menu bar.

OK, After having spent a lot of time on banking websites over the last few days, I realise why this bug is so important. Most of these sites ask you to enter your personal details into a pop-up window - one without a menu bar. As I have two addresses loaded into Form Manager, work and home, the fact I cannot access the Form Manager dialog renders the entire concept useless on these sites. There has to be a way to access the dialog without the menu bar.

I have used Mozilla since 1.0 and only two weeks ago I discovered the "Fill Form"-feature in the "Form manager"-submenu! This powerful feature is hidden too well. I strongly suggest adding "Fill form" and "Save form info" for the context menu of a form element in order to enhance the usability for this feature.

*** Bug 243910 has been marked as a duplicate of this bug. ***

Filter on "Nobody_NScomTLD_20080620"

The old form autofill UI no longer exists, so this isn't relevant any more.

Shouldn't this be changed to "enhancement request" rather than Invalid?

If a concrete idea exists, better file a new bug. Things have too much changed since those old days. The discussions here are mostly irrelevant to todays situation.

I am quite confused. In SeaMonkey this feature is still there in the current release.

1: I don't believe that any change in the backend code negates in any way the overall original purpose of this bug - having a way to easily pre-fill an entire form. However, the mechanisms of doing so in general are certainly different now. Look at comment 28. There is no longer a form manager menu... 2: I'm the original reporter of this bug, but I no longer really care. I no longer need or want entire forms to be pre-filled - perhaps my browsing behaviour has changed over the years. Plus, given how long it's been with a lack of input, it doesn't seem likely that there's interest in the coding community to actually do anything with it either. I agree with the resolution here. The if somebody else wants things to happen differently, and has a suggestion based on how things currently works, then file a new bug with that feature request. (If nothing else, it will be a "fresh" bug without a long list of comments that produce anything.)

In Seamonkey 1.1.11 there is a form manger menu.

But there isn't one in 2.0pre. I don't think that anybody's going to implement something that doesn't work for the direction that SeaMonkey is headed in...

Correct -- the code SM 2.0 is based on no longer has the form management UI of the past. It's now using the same code Firefox has been using since 1.0ish days, which replaces the complex and unwieldy fill/management UI with simple autocomplete dropdowns. An old-style UI isn't going to come back into Toolkit code... Use an extension, or file a Seamonkey-specific bug to bring it back just there.