562625 - The form manager should remember the type of the input when saving its value

Status: RESOLVED WONTFIX

(Toolkit :: Form Manager, defect)

Description

[Mounir Lamouri (:mounir)]

At the moment, the form manager is only saving values from <input type='text'> as password are saved in a different way. With new input types (at least email, url, search and tel for text fields), the form manager should also save the type of the input type so autocomplete could filter the values to match the type of the field.

Comment 1

[Matthew N. [:MattN]]

When I was thinking about this the other week, some questions arose:

1) When we update an existing satchel entry, should we save the type if it was not saved previously?  What about if the type was saved previously and then another form with the same name/value pair gets submitted with a different input type? Should it be updated or should we save them separately?  
For example: a user submit an email address in an input named "email" with type="search" and later submits the same email address in an input with type="email" having the same name.  I think the answer depends on how we are going to use the type to filter/rank matching entries in a follow-up bug.

2) Should we store the input type even if there was no validation on the input?  We probably don't want to suggest invalid values for that input type in the future unless the form being filled also isn't being validated.  This is similar to how we no longer suggest entries longer than maxlength. (bug 444728)

3) Should we migrate existing form history entries on upgrade by adding the appropriate type if they match specific validation patterns?  
For example, we can set the type to "url" or "email" by checking for any entries that match their validation patterns.  Again I think this depends on how we will use the type information to display suggestions.  If we are merely ranking entries with a matching type higher than entries of type "text" or unknown then this would be beneficial.

Just some things to think about

Comment 2

[Mounir Lamouri (:mounir)]

(In reply to comment #1)
> When I was thinking about this the other week, some questions arose:
> 
> 1) When we update an existing satchel entry, should we save the type if it was
> not saved previously?  What about if the type was saved previously and then
> another form with the same name/value pair gets submitted with a different
> input type? Should it be updated or should we save them separately?  
> For example: a user submit an email address in an input named "email" with
> type="search" and later submits the same email address in an input with
> type="email" having the same name.  I think the answer depends on how we are
> going to use the type to filter/rank matching entries in a follow-up bug.

IMO, it depends of the usage of these new types. For example, if 'email' is often used when the field should be filed with an email address, we could consider saving the fields values separately without considering the name. I think considering the input name could be an issue when a name could be used for a a few types. On top of my head, I see "login" or "username" which can be very common and could be used for type='text', type='email' or even type='tel' or type='url'.

> 2) Should we store the input type even if there was no validation on the input?
>  We probably don't want to suggest invalid values for that input type in the
> future unless the form being filled also isn't being validated.  This is
> similar to how we no longer suggest entries longer than maxlength. (bug 444728)

Actually, HTML5 Forms should not be submitted if the form is not valid. So this should happen only when the author asks to not check for the form validity. Only checking form |input.validity.valid| should be enough.

> 3) Should we migrate existing form history entries on upgrade by adding the
> appropriate type if they match specific validation patterns?  
> For example, we can set the type to "url" or "email" by checking for any
> entries that match their validation patterns.  Again I think this depends on
> how we will use the type information to display suggestions.  If we are merely
> ranking entries with a matching type higher than entries of type "text" or
> unknown then this would be beneficial.

I think the migration should depend on the usage too. The user should not see the change so if we filter the saved email addresses to only show them for email addresses and there is not so many email fields, the user isn't going to understand.
If the change is done in a near future, we probably should not migrate the currently saved entries.

Comment 3

[Janika Neuberger [:janika]]

We think the benefit doesn't overweight the effort.