Not allowing user to type more chars than max length value for text field.

Not allowing user to type more chars than max length value for text field.

Added code to handle case When user types chars more than max length value
for input text field. Modified imeAdapter#focusedNodeChanged to get max
length of input field and using max length value to prevent user to type
if text length in input field has exceeded.

BUG=400051

[ankit, 2014-08-04 09:34:11]

@aurmias
PTAL

[aurimas (slooooooooow), 2014-08-04 15:17:31]

On 2014/08/04 09:34:11, ankit wrote:
> @aurmias
> PTAL

I think the fix should be in blink code. Every other platform does the character
limiting there so we should do it there as well.

[ankit, 2014-08-04 15:35:21]

On 2014/08/04 15:17:31, aurimas wrote:
> On 2014/08/04 09:34:11, ankit wrote:
> > @aurmias
> > PTAL
> 
> I think the fix should be in blink code. Every other platform does the
character
> limiting there so we should do it there as well.

@aurimas
Please suggest where in blink side it can be done.

[aurimas (slooooooooow), 2014-08-04 15:41:45]

+yosin who works on editing in blink. yosin, can you advice the creator of this
change of where in blink we have the logic to restrict the length of the input
field? Thanks!

[yosin_UTC9, 2014-08-07 01:31:02]

On 2014/08/04 15:41:45, aurimas wrote:
> +yosin who works on editing in blink. yosin, can you advice the creator of
this
> change of where in blink we have the logic to restrict the length of the input
> field? Thanks!

Blink doesn't provide logic for restrict number of characters intermediate text
composition.
It seems we should not restrict #chars for intermediate text composition.
For Japanese IME, intermediate composition can have more than "maxlength"
characters but final composition fits to "maxlength" restriction, e.g. several
Kana characters to one Kanji character, or some IME can convert ":-)" to Unicode
emotional character. When "maxlength=1" on input field, users can insert Unicode
emotional character for ":-)"

[ankit, 2014-08-07 04:26:05]

On 2014/08/07 01:31:02, Yosi_UTC9 wrote:
> On 2014/08/04 15:41:45, aurimas wrote:
> > +yosin who works on editing in blink. yosin, can you advice the creator of
> this
> > change of where in blink we have the logic to restrict the length of the
input
> > field? Thanks!
> 
> Blink doesn't provide logic for restrict number of characters intermediate
text
> composition.
> It seems we should not restrict #chars for intermediate text composition.
> For Japanese IME, intermediate composition can have more than "maxlength"
> characters but final composition fits to "maxlength" restriction, e.g. several
> Kana characters to one Kanji character, or some IME can convert ":-)" to
Unicode
> emotional character. When "maxlength=1" on input field, users can insert
Unicode
> emotional character for ":-)"

@Yosi
So is it intended behavior not to restrict #chars even if it's exceeding max
length value?
Or we should have some kind of constraint which can handle these scenario. 
Please suggest what should be correct approach in this case.

[yosin_UTC9, 2014-08-07 06:20:03]

On 2014/08/07 04:26:05, ankit wrote:
> On 2014/08/07 01:31:02, Yosi_UTC9 wrote:
> > On 2014/08/04 15:41:45, aurimas wrote:
> > > +yosin who works on editing in blink. yosin, can you advice the creator of
> > this
> > > change of where in blink we have the logic to restrict the length of the
> input
> > > field? Thanks!
> > 
> > Blink doesn't provide logic for restrict number of characters intermediate
> text
> > composition.
> > It seems we should not restrict #chars for intermediate text composition.
> > For Japanese IME, intermediate composition can have more than "maxlength"
> > characters but final composition fits to "maxlength" restriction, e.g.
several
> > Kana characters to one Kanji character, or some IME can convert ":-)" to
> Unicode
> > emotional character. When "maxlength=1" on input field, users can insert
> Unicode
> > emotional character for ":-)"
> 
> @Yosi
> So is it intended behavior not to restrict #chars even if it's exceeding max
> length value?
> Or we should have some kind of constraint which can handle these scenario. 
> Please suggest what should be correct approach in this case.

Yes, this is expected behavior. We don't need to change anything.

Text field automatically truncates users input by no-IME typing, IME typing,
Paste with keyboard shortcut, Paste with context menu. When we use script to set
value, text field doesn't truncate. But, user can't submit form if text field
contains characters more than maxlength.

[ankit, 2014-08-07 06:46:32]

On 2014/08/07 06:20:03, Yosi_UTC9 wrote:
> On 2014/08/07 04:26:05, ankit wrote:
> > On 2014/08/07 01:31:02, Yosi_UTC9 wrote:
> > > On 2014/08/04 15:41:45, aurimas wrote:
> > > > +yosin who works on editing in blink. yosin, can you advice the creator
of
> > > this
> > > > change of where in blink we have the logic to restrict the length of the
> > input
> > > > field? Thanks!
> > > 
> > > Blink doesn't provide logic for restrict number of characters intermediate
> > text
> > > composition.
> > > It seems we should not restrict #chars for intermediate text composition.
> > > For Japanese IME, intermediate composition can have more than "maxlength"
> > > characters but final composition fits to "maxlength" restriction, e.g.
> several
> > > Kana characters to one Kanji character, or some IME can convert ":-)" to
> > Unicode
> > > emotional character. When "maxlength=1" on input field, users can insert
> > Unicode
> > > emotional character for ":-)"
> > 
> > @Yosi
> > So is it intended behavior not to restrict #chars even if it's exceeding max
> > length value?
> > Or we should have some kind of constraint which can handle these scenario. 
> > Please suggest what should be correct approach in this case.
> 
> Yes, this is expected behavior. We don't need to change anything.
> 
> Text field automatically truncates users input by no-IME typing, IME typing,
> Paste with keyboard shortcut, Paste with context menu. When we use script to
set
> value, text field doesn't truncate. But, user can't submit form if text field
> contains characters more than maxlength.

@Yosi
Thanks for clearification.
These changes are not required as the bug reported is not a valid bug.
It is already working as expected.
Closing this issue.