[Ext] Autofill Forms - Fill out web forms automatically.

[madblueimp]

It's supposed to be Option+j, but you can easily customize it on the settings page.

The Option-Key is the equivalent to the Alt-Key on the PC (Windows, Linux, ...)
http://developer.mozilla.org/en/docs/XU ... ey_element

[TonyFreixas]

Hello,

Thanks for taking the time to create this extension. I've been using the old Autofill 0.3 extension which hasn't been updated in years—luckily, with a little help from another extension, I've been able to keep it going. But it's nice to have something actively maintained.

I hope you've had a chance to look at Autofill 0.3 since it has some nice features (see http://autofill.mozdev.org/). After trying out Autofill Form, I have a few notes you may find useful:

Instead of a profile switcher, try listing the profiles directly in the toolbar button drop-down. It makes it easier to see what your current profile is and faster to change (see Autofill 0.3).

When you see a field you can fill, highlight it in yellow (see Autofill 0.3).

It would be really nice to have inheritable profiles—all fields are the same as the parent except for fields explicitly changed (or you might use a special value, like "<inherit>", to indicate fields that should inherit a value). I realize this is probably a lot of work. The value is that I have several profiles that are the same except for a few things. When I create them, it's easy to copy things, but from then on, the profiles are independent.

Bring up the settings window. Now resize it to be taller. The list should get taller, but not resizes. Try dragging the pane divider down. The form field rule moves down but the list still doesn't get bigger. Drag the pane divider up. The list area gets smaller. Drag the divider back down. The list area still remains small. Close the dialog and bring it back up. The list is still small. So fix this so the list uses all the extra space when the window becomes taller or the upper pane becomes taller.

Pick a rule to edit. Change the value but don't hit return. Select another rule. The value is not saved. I lost a lot of entries when I wasn't being careful about hitting return. When you click on a new entry (or on OK), the current textfield value should be automatically entered.

What do you do when you need to enter more than one possible value? This is important for fields that are selections. For states, for example, the value might be Oregon or OR. I noticed you had something for alternatives, but haven't found a form yet I can try it on. Ignore this comment if it's already implemented.

That's it. Thanks again.

[madblueimp]

I hope you've had a chance to look at Autofill 0.3 since it has some nice features (see http://autofill.mozdev.org/).

Autofill Forms has been developed on user request - Christopher Bolin, a Secure Login user asked me to implement features like that of Autofill - I decided to write a similar extension from scratch - but the inspiration originates from Autofill.

Instead of a profile switcher, try listing the profiles directly in the toolbar button drop-down. It makes it easier to see what your current profile is and faster to change

The current profile is listed in the tooltip of the Autofill Forms icon. Using a dialog to switch profiles makes it coherent and possible to use the same code when using the toolbar button, a keyboard shortcut or something else to call the function.

When you see a field you can fill, highlight it in yellow

This has been asked and answered here.
A similar but not resource consuming functionality has been added with version 0.6.1:

- Highlight style using CSS declarations via about:config for matched and not matched form fields

It would be really nice to have inheritable profiles—all fields are the same as the parent except for fields explicitly changed (or you might use a special value, like "<inherit>", to indicate fields that should inherit a value). I realize this is probably a lot of work. The value is that I have several profiles that are the same except for a few things. When I create them, it's easy to copy things, but from then on, the profiles are independent.

Like you said, it's easy to copy things if you create new profiles - in fact, new profiles are created by copying the current profile contents.
What you can do to use the same values for several profiles is using dynamic tags. Dynamic tags have been implemented for version 0.7.

fix this so the list uses all the extra space when the window becomes taller or the upper pane becomes taller.

Fixed with some other minor user interface improvements in the new version 0.7.0.1.

Pick a rule to edit. Change the value but don't hit return. Select another rule. The value is not saved. I lost a lot of entries when I wasn't being careful about hitting return. When you click on a new entry (or on OK), the current textfield value should be automatically entered.

Which version of Autofill Forms have you been using?
In versions prior to 0.7 you had to hit "Apply" to save a changed field rule. Since version 0.7 changes are saved as soon as a textbox loses focus.

What do you do when you need to enter more than one possible value? This is important for fields that are selections. For states, for example, the value might be Oregon or OR. I noticed you had something for alternatives, but haven't found a form yet I can try it on. Ignore this comment if it's already implemented.

It's already implemented - using multiple values to match selections since version 0.1.
Just define several similar field rules with different values.

[TonyFreixas]

Instead of a profile switcher, try listing the profiles directly in the toolbar button drop-down. It makes it easier to see what your current profile is and faster to change

The current profile is listed in the tooltip of the Autofill Forms icon. Using a dialog to switch profiles makes it coherent and possible to use the same code when using the toolbar button, a keyboard shortcut or something else to call the function.

I understand your reasoning. I hope you'll consider this a bit further. Consistency is nice—usability is better. I see no conflict with using one method on the toolbar and a different one for the shortcut key.

With Autofill, it was a quick operation to check the current profile and then change it if the right profile wasn't in place. With Autofill Form, I move the mouse over the pencil, and wait for the tooltip to show. If I don't have the right profile, I click on the pencil, select the profile switcher, select the profile and click OK.

I'll probably learn the shortcut, but I never felt the need to have one for Autofill. Even with the shortcut, the process is: try to remember shortcut keys , press shortcut keys, select profile, press OK.

Anyway, if this is the worst thing about Autofill Form, then you really have little to worry about

When you see a field you can fill, highlight it in yellow

This has been asked and answered here.
A similar but not resource consuming functionality has been added with version 0.6.1:

- Highlight style using CSS declarations via about:config for matched and not matched form fields

With all my suggestions, please understand that I appreciate your work and it is your choice entirely what you decide to do or not do.

I'm not sure I understand your reference to the change in version 0.6.1. I just checked the Help file and didn't see anything there. Maybe I'll find your changelog file, but at the moment, I don't know if this similar feature is a suitable substitute. I found what I assume are the entries you mentioned in about:config—I'll see if I can find the instructions.

My feeling is that my processor cycles are mine to waste as I see fit. I'd be happy with a checkbox to enable the highlighting, with the default being off. With Autofill, the highlighting would remind me that I had autofill capability. If you can do this without wasting cycles, all the better!

It would be really nice to have inheritable profiles—all fields are the same as the parent except for fields explicitly changed (or you might use a special value, like "<inherit>", to indicate fields that should inherit a value). I realize this is probably a lot of work. The value is that I have several profiles that are the same except for a few things. When I create them, it's easy to copy things, but from then on, the profiles are independent.

Like you said, it's easy to copy things if you create new profiles - in fact, new profiles are created by copying the current profile contents.
What you can do to use the same values for several profiles is using dynamic tags. Dynamic tags have been implemented for version 0.7.

Thanks. I'll check out dynamic tags. Copying is easy but doesn't solve the problem with changes made after copying that need to go to all profiles.

Pick a rule to edit. Change the value but don't hit return. Select another rule. The value is not saved. I lost a lot of entries when I wasn't being careful about hitting return. When you click on a new entry (or on OK), the current textfield value should be automatically entered.

Which version of Autofill Forms have you been using?
In versions prior to 0.7 you had to hit "Apply" to save a changed field rule. Since version 0.7 changes are saved as soon as a textbox loses focus.

I'm using Autofill Forms 0.7 (as reported by the Extensions dialog). I'll try to find out the exact way to reproduce the problem. I can't do that now because my list window is about 5 pixels high and I haven't got it to resize back to normal size. This interferes with my repeating the steps that caused the problems.

What do you do when you need to enter more than one possible value? This is important for fields that are selections. For states, for example, the value might be Oregon or OR. I noticed you had something for alternatives, but haven't found a form yet I can try it on. Ignore this comment if it's already implemented.

It's already implemented - using multiple values to match selections since version 0.1.
Just define several similar field rules with different values.

Excellent! Thanks. You know, it's funny how you can never find the right form when you need it. As soon as I do, I'll try this out.

[madblueimp]

I understand your reasoning. I hope you'll consider this a bit further. Consistency is nice—usability is better. I see no conflict with using one method on the toolbar and a different one for the shortcut key.

I don't reject your suggestion completely - but at the time being, I prefer it the way it is. Usability is sometimes a matter of taste - and the tooltips and profile dialogs are not "unusable" in my opinion.

With all my suggestions, please understand that I appreciate your work and it is your choice entirely what you decide to do or not do.

No problem. As long as you don't start insulting me for not doing what you want.

I'm not sure I understand your reference to the change in version 0.6.1. I just checked the Help file and didn't see anything there. Maybe I'll find your changelog file, but at the moment, I don't know if this similar feature is a suitable substitute. I found what I assume are the entries you mentioned in about:config—I'll see if I can find the instructions.

It is undocumented - the about:config entries allow to enter custom CSS styles. After you fill in a form, the styles are applied to fields that have been and have not been filled respectively.

My feeling is that my processor cycles are mine to waste as I see fit. I'd be happy with a checkbox to enable the highlighting, with the default being off. With Autofill, the highlighting would remind me that I had autofill capability. If you can do this without wasting cycles, all the better!

Your system resources are surely yours. Yet in my opinion Firefox suffers from too many extensions consuming too much resources. And users often don't relate this to the installed extensions but rather blame Firefox.
I'm not completely against such a feature. Secure Login for instance highlights login form fields by default - the option to disable this feature had only been implemented since version 0.7.2.
For Autofill Forms, even if I implemented this functionality, I would strongly suggest to turn it off. Autofill Forms can fill in every possible form field on every possible form on all websites - it would need to test nearly every page you visit (as today most websites contain a kind of web form) and every field of every form with all the field rules of the current profile until it finds a match or the end of the list is reached.

Thanks. I'll check out dynamic tags. Copying is easy but doesn't solve the problem with changes made after copying that need to go to all profiles.

That's the reason I suggested the use of Dynamic Tags. You could for example use something like

Code: Select all

<email>

Code: Select all

'mail@example.org'

I'm using Autofill Forms 0.7 (as reported by the Extensions dialog). I'll try to find out the exact way to reproduce the problem. I can't do that now because my list window is about 5 pixels high and I haven't got it to resize back to normal size. This interferes with my repeating the steps that caused the problems.

If you install the new version 0.7.0.1 the window resizing problems will be fixed.

You know, it's funny how you can never find the right form when you need it. As soon as I do, I'll try this out.

If you know how, you could as well craft a sample web page and test it on a local server.
If you're just searching for a selection dialog, you might want to test it with the Google preferences:
http://www.google.com/preferences

[TonyFreixas]

Hey, thanks for all the responses! I may not agree with some choices, but I'm not the one writing the code. For a long time, I thought about taking over the Autofill code, but there have always been too many things ahead of it in the queue.

One vague idea I had that you're welcome to steal (or not) is some sort of learning mode: I "teach" Autofill that this field gets filled with this value and it uses some SpamBayes algorithm for evaluating future fields. When it gets things wrong, I can tell it that as well. My spam filter, POPfile, runs like this. I have zero spam filter rules; I just train it on what spam looks like.

[madblueimp]

The learning mode is a nice idea - I'll put it on my list.

[TonyFreixas]

A few quick notes on 7.0.1:

The dialog sizing works well. Thanks!

Pick a rule to edit. Change the value but don't hit return. Select another rule. The value is not saved. I lost a lot of entries when I wasn't being careful about hitting return. When you click on a new entry (or on OK), the current textfield value should be automatically entered.

I was able to reproduce this problem. You have to do these steps precisely:<ul><li>Select an item to edit by clicking on one from the list.
<li>Edit the value by clicking in the Value field and making a change—don't do anything else
<li>Click on the list to select a different value
</ul>The result is that the first item is not changed.

Regarding the use of dynamic tags as a substitute for hierarchical profiles: According to the Help file, dynamic tags need to be entered in the Value field of a field rule. The cases where I would use a hierarchical profile are<ul><li>I want to update a value used by an item in a set of profiles.
<li>I want to add a new item to a set of profiles.
<li>I want to change the Field rule or Site rule for a set of profiles.</ul>I don't see how dynamic tags help except in the first case. To add a new item, I can create a dynamic tag, but I still have to go through each profile to add a field that uses the tag. And I can't use dynamic tags in either the Field rule or Site rule.

Hierarchical profiles are the most generic solution. An adequate solution would be a global profile. This is essentially one hierarchy of one level, but that's actually enough for my use.

Without looking at your code, here's a possible implementation. I'm sure you can improve on it:<ul><li>Add one field in the Advanced section where you select one profile as the "global" profile.
<li>Whenever a global profile exists and a change is made to a profile, run some merge code to create a merged, shadow copy of each profile.
<li>Merging is just a matter of cloning a profile and adding the global items to the clone, except when the global item name is already in the clone.
<li>During fill-in, you use the shadow copy if it exists instead of the normal profile.
<li>Don't worry if the user chooses the global profile as the current profile—more power to him.
<li>If the global profile is deleted, you delete the shadow copies and clear the global profile preference.</ul>

[madblueimp]

I was able to reproduce this problem. You have to do these steps precisely:<ul><li>Select an item to edit by clicking on one from the list.
<li>Edit the value by clicking in the Value field and making a change—don't do anything else
<li>Click on the list to select a different value
</ul>The result is that the first item is not changed.

Confirmed - though I'm not sure if I can do anything about it.
Every textbox of the fieldrule has an attached event handler which should fire on focus lost ("onblur").
But apparently it doesn't fire in this case.


Thanks for your suggestions for the "Global Profile".
I think I'll implement it the following way:
I'll add the "Global Profile" selection on the Advanced Tab, like you suggested.
Maybe I'll also add a checkbox, so users can decide if they wish to use it.
On fill in, the current profile is used first.
Every field that couldn't be filled in gets a second try with the global profile ruleset.
That makes things easy to understand and easy to implement.

[TonyFreixas]

I was able to reproduce this problem. You have to do these steps precisely:<ul><li>Select an item to edit by clicking on one from the list.
<li>Edit the value by clicking in the Value field and making a change—don't do anything else
<li>Click on the list to select a different value
</ul>The result is that the first item is not changed.

Confirmed - though I'm not sure if I can do anything about it.
Every textbox of the fieldrule has an attached event handler which should fire on focus lost ("onblur").
But apparently it doesn't fire in this case.

Hmmm....if this is the only case where there is a screw-up (and it's the only one I found), you might be able to special case it. If there is an "on change" event for the text field, use it to set a flag that the user changed ANY of the text field values (they all have the same bug). Then when a rule on the list is selected, before you copy the values to the text fields, check if the fields are dirty and copy them back to the list before setting the new values.

Thanks for your suggestions for the "Global Profile".
I think I'll implement it the following way:
I'll add the "Global Profile" selection on the Advanced Tab, like you suggested.
Maybe I'll also add a checkbox, so users can decide if they wish to use it.
On fill in, the current profile is used first.
Every field that couldn't be filled in gets a second try with the global profile ruleset.
That makes things easy to understand and easy to implement.

I was thinking about this after I wrote the last message and started to think it might be worth going through some use cases before making any changes.

Here's a real use case for me: I have several profiles and each handles a different credit card number, type, expiration date, etc. Most other fields are identical. I find that the regular expression used to detect the credit card type needs some work and that, for a while at least, I keep having to tweak it on a regular basis. Neither your solution—<strong>or mine</strong>—helps with this use case. I have to tweak each profile individually.

Maybe others have given you some interesting use cases where things could be simplified by some sort of "global" settings. You can then step through each use case and see how an implementation would help or hinder the task.

Some other use cases: <ul><li>I have my various profiles and I want to add a new field to all the profiles.
<li>I have work and home profiles and I want to add a new field to my work profiles.
<li>I moved and want to change my address in all profiles.
<li>I have work and home profiles. I moved and want to change my address only in all my home profiles.
<li>I want to remove a field from all profiles.
<li>Same as above but only from some profiles.
<li>I want to create a set of special fill-in values for one set of sites.</ul>I'm sure you can think of more.

In going through this exercise, it occurred to me that, instead of having a Site Rule, it might be more useful to have a Site Profile: if the site name matches a regular expression, then a particular profile is used.

Another thought is that perhaps the Name and Field Rule values should be global to all profiles. The Value would be per profile and a blank Value means skip the field. Looking at the use cases above, I could differentiate between home and work addresses by giving them different names. To give all home profiles the same address I would use a dynamic tag for the value (not because its dynamic but because it is a global value).

There may be even better solutions. So while I've given you some implementation ideas, I'm actually stepping back from proposing solutions to defining the problems I'd like to see solved—you can decide which problems you want to solve and how to best solve them.

Again, thanks for your willingness to tackle Autofill. It's nice to see someone actually working on it!

[madblueimp]

Hmmm....if this is the only case where there is a screw-up (and it's the only one I found), you might be able to special case it. If there is an "on change" event for the text field, use it to set a flag that the user changed ANY of the text field values (they all have the same bug). Then when a rule on the list is selected, before you copy the values to the text fields, check if the fields are dirty and copy them back to the list before setting the new values.

Good idea - but unfortunately, the onchange event is even fired after the onblur event:
http://developer.mozilla.org/en/docs/DO ... t.onchange
Seems neither the onblur nor the onchange event gets fired in this case (I've tested this out).

I was thinking about this after I wrote the last message and started to think it might be worth going through some use cases before making any changes.

Might be I'm staying with my last "Global Profile" suggestion as I like to keep things simple but I'm taking into account all your suggestions.
At least most of the use cases are matched this way.

Again, thanks for your willingness to tackle Autofill. It's nice to see someone actually working on it!

Thanks, but Autofill Forms is still not Autofill. It's a completely new extension.

[TonyFreixas]

Again, thanks for your willingness to tackle Autofill. It's nice to see someone actually working on it!

Thanks, but Autofill Forms is still not Autofill. It's a completely new extension.

Oops! To re-phrase: Thanks for tackling the autofill problem!

[fitzt]

I lost my basic form setting, that came with Auto Fill. Now that I have upgraded my Macintosh to a Intel version, I not longer have it. Call any one help??

[gasyoun]

Than what about http://www.roboform.com/browsers.html#browser_mozilla ?

[madblueimp]

I lost my basic form setting, that came with Auto Fill. Now that I have upgraded my Macintosh to a Intel version, I not longer have it. Call any one help??

If the Autofill Forms FAQ doesn't help, maybe you could try installing Autofill Forms in a fresh Firefox Profile.