Refactor autofill form fields.

Refactor autofill form fields.

1, Add FormField::MatchType and ParseText() use to match the input.
2, Erase some unndeeded function in FormField.
3, Make new MatchWithType() function.
4, Added FormField::is_text_input to drag the info to check the matching.

BUG=
TEST=

[honten.org, 2011-05-17 04:41:18]

Please review.

http://codereview.chromium.org/7038003/diff/1/webkit/glue/form_field.cc
File webkit/glue/form_field.cc (right):

http://codereview.chromium.org/7038003/diff/1/webkit/glue/form_field.cc#newco...
webkit/glue/form_field.cc:78: }
It's not clean ;-(

But lots of unit tests use this constructor, and changing it at once is really
messy.

How should I do?

[dhollowa, 2011-05-17 16:47:20]

http://codereview.chromium.org/7038003/diff/1/webkit/glue/form_field.cc
File webkit/glue/form_field.cc (right):

http://codereview.chromium.org/7038003/diff/1/webkit/glue/form_field.cc#newco...
webkit/glue/form_field.cc:78: }
We should simply have a helper function that does this.  Probably a method in 
|form_field.cc| in an anonymous namespace.  In general it is bad practice to
store a derived value.  Unless there is an explicit reason to cache.

On 2011/05/17 04:41:18, honten wrote:
> It's not clean ;-(
> 
> But lots of unit tests use this constructor, and changing it at once is really
> messy.
> 
> How should I do?

http://codereview.chromium.org/7038003/diff/1/webkit/glue/form_field.h
File webkit/glue/form_field.h (right):

http://codereview.chromium.org/7038003/diff/1/webkit/glue/form_field.h#newcode45
webkit/glue/form_field.h:45: bool is_text_input;
This is a derived field, we shouldn't be storing this value.  It can be derived
from |form_control_type|.

[honten.org, 2011-05-17 18:45:22]

http://codereview.chromium.org/7038003/diff/1/webkit/glue/form_field.cc
File webkit/glue/form_field.cc (right):

http://codereview.chromium.org/7038003/diff/1/webkit/glue/form_field.cc#newco...
webkit/glue/form_field.cc:78: }
Actually, I wanted to find the function in |form_field.cc| and
|form_manager.cc|, but I cannot find it.

It might be the following function is the candidate in |form_manager.cc|, 
bool IsTextInput(const WebInputElement* element) {
  if (!element)
    return false;

  return element->isTextField() && !element->isPasswordField();
}

But as you see here, the value is derived from isTextField().

I want to drag the flag, but as you know, it is not good idea:-(

Do you have any idea?

Thanks,
On 2011/05/17 16:47:20, dhollowa wrote:
> We should simply have a helper function that does this.  Probably a method in 
> |form_field.cc| in an anonymous namespace.  In general it is bad practice to
> store a derived value.  Unless there is an explicit reason to cache.
> 
> On 2011/05/17 04:41:18, honten wrote:
> > It's not clean ;-(
> > 
> > But lots of unit tests use this constructor, and changing it at once is
really
> > messy.
> > 
> > How should I do?
>

[honten.org, 2011-05-18 03:34:14]

Is this better? 

What do you think?

[dhollowa, 2011-05-18 14:35:54]

You'll need to *create* the function, not find it.

On 2011/05/18 03:34:14, honten wrote:
> Is this better? 
> 
> What do you think?

[honten.org, 2011-05-18 19:42:21]

Oops,

Last night upload didn't succeed in some way.

I'll update again tonight...

On 2011/05/18 14:35:54, dhollowa wrote:
> You'll need to *create* the function, not find it.
> 
> On 2011/05/18 03:34:14, honten wrote:
> > Is this better? 
> > 
> > What do you think?

[dhollowa, 2011-05-18 19:54:34]

Takano-san, after looking at form_field.h a little more closely, I'm going to do
some refactoring in there before we build on it further.  The interface is in
need of simplification and generalization.  So please hold off on further
changes to this until we've got a better foundation to work from.

On 2011/05/18 19:42:21, honten wrote:
> Oops,
> 
> Last night upload didn't succeed in some way.
> 
> I'll update again tonight...
> 
> On 2011/05/18 14:35:54, dhollowa wrote:
> > You'll need to *create* the function, not find it.
> > 
> > On 2011/05/18 03:34:14, honten wrote:
> > > Is this better? 
> > > 
> > > What do you think?

[takano.naoki_gmail.com, 2011-05-18 19:56:20]

Ok,

I wait for a while.

If you have any other bug or refinement to assign me, please let me know.

On Wed, May 18, 2011 at 12:54 PM,  <dhollowa@chromium.org> wrote:
> Takano-san, after looking at form_field.h a little more closely, I'm going
> to do
> some refactoring in there before we build on it further.  The interface is
> in
> need of simplification and generalization.  So please hold off on further
> changes to this until we've got a better foundation to work from.
>
> On 2011/05/18 19:42:21, honten wrote:
>>
>> Oops,
>
>> Last night upload didn't succeed in some way.
>
>> I'll update again tonight...
>
>> On 2011/05/18 14:35:54, dhollowa wrote:
>> > You'll need to *create* the function, not find it.
>> >
>> > On 2011/05/18 03:34:14, honten wrote:
>> > > Is this better?
>> > >
>> > > What do you think?
>
>
>
> http://codereview.chromium.org/7038003/
>

[dhollowa, 2011-05-18 20:14:44]

http://crbug.com/55786 might be interesting to you...

On 2011/05/18 19:56:20, takano.naoki_gmail.com wrote:
> Ok,
> 
> I wait for a while.
> 
> If you have any other bug or refinement to assign me, please let me know.
> 
> On Wed, May 18, 2011 at 12:54 PM,  <mailto:dhollowa@chromium.org> wrote:
> > Takano-san, after looking at form_field.h a little more closely, I'm going
> > to do
> > some refactoring in there before we build on it further. &nbsp;The interface
is
> > in
> > need of simplification and generalization. &nbsp;So please hold off on
further
> > changes to this until we've got a better foundation to work from.
> >
> > On 2011/05/18 19:42:21, honten wrote:
> >>
> >> Oops,
> >
> >> Last night upload didn't succeed in some way.
> >
> >> I'll update again tonight...
> >
> >> On 2011/05/18 14:35:54, dhollowa wrote:
> >> > You'll need to *create* the function, not find it.
> >> >
> >> > On 2011/05/18 03:34:14, honten wrote:
> >> > > Is this better?
> >> > >
> >> > > What do you think?
> >
> >
> >
> > http://codereview.chromium.org/7038003/
> >

[Ilya Sherman, 2011-06-04 01:56:50]

Closing, as I think these changes have all been incorporated into other CLs.