Closed
Bug 143881
Opened 23 years ago
Closed 16 years ago
No obvious way to prefill form.
Categories
(Toolkit :: Form Manager, defect)
Toolkit
Form Manager
Tracking
()
RESOLVED
INVALID
People
(Reporter: jasonb, Unassigned)
References
Details
(Keywords: regression)
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.
Comment 1•23 years ago
|
||
You are making several points in one bug. This is not helpful.
Reporter | ||
Comment 2•23 years ago
|
||
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?
Comment 4•23 years ago
|
||
timeless: I think what Jason is asking for is a way to prefill the entire form,
not just a single field.
Reporter | ||
Comment 5•23 years ago
|
||
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.
Comment 6•23 years ago
|
||
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.
Reporter | ||
Comment 7•23 years ago
|
||
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.
Comment 8•23 years ago
|
||
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.
Reporter | ||
Comment 9•23 years ago
|
||
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.
Comment 10•23 years ago
|
||
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.
Reporter | ||
Comment 11•23 years ago
|
||
> 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.)
Blocks: 48860
Comment 12•23 years ago
|
||
*** Bug 136037 has been marked as a duplicate of this bug. ***
Comment 13•23 years ago
|
||
*** Bug 146885 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
+1 vote for the prefill feature. Missing from Mozilla v1.1a
Comment 15•23 years ago
|
||
How about if you triple-click a form field, the all form fields that can be
prefilled are prefilled?
Reporter | ||
Comment 16•23 years ago
|
||
Has a triple-click ever been used for anything? I think that would be too
confusing...
Comment 17•23 years ago
|
||
> 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.
Comment 18•23 years ago
|
||
Thank you very much.
Comment 19•22 years ago
|
||
uid is being phased out.
Assignee: mpt → morse
Component: User Interface Design → Form Manager
QA Contact: zach → tpreston
Updated•22 years ago
|
Target Milestone: --- → Future
Comment 21•22 years ago
|
||
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.
Assignee: morse → dveditz
Reporter | ||
Comment 23•22 years ago
|
||
*** Bug 188317 has been marked as a duplicate of this bug. ***
Comment 24•22 years ago
|
||
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?
Reporter | ||
Comment 25•22 years ago
|
||
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.)
Reporter | ||
Comment 26•22 years ago
|
||
> 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.
Comment 27•22 years ago
|
||
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.
Comment 28•21 years ago
|
||
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.
Comment 29•21 years ago
|
||
*** Bug 243910 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Assignee: dveditz → nobody
Comment 31•16 years ago
|
||
The old form autofill UI no longer exists, so this isn't relevant any more.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Updated•16 years ago
|
Product: Core → Toolkit
QA Contact: form-manager → form.manager
Target Milestone: Future → ---
Version: Trunk → unspecified
Comment 32•16 years ago
|
||
Shouldn't this be changed to "enhancement request" rather than Invalid?
Comment 33•16 years ago
|
||
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.
Comment 34•16 years ago
|
||
I am quite confused. In SeaMonkey this feature is still there in the current release.
Reporter | ||
Comment 35•16 years ago
|
||
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.)
Comment 36•16 years ago
|
||
In Seamonkey 1.1.11 there is a form manger menu.
Reporter | ||
Comment 37•16 years ago
|
||
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...
Comment 38•16 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•