@matango3rd-- Could you please provide us the sample test url/testcase and screencast of the issue , that would help us in traiging the issue better.

Thanks!

>Could you please provide us the sample test url/testcase and screencast of the issue , that would help us in traiging the issue better.

All web page occor this issue, example this page too.

(1) Set maxlength 5 input tag on this page. (attach file1)
(2) After that input 5 over words for input tag on japaneseIME.(attach file2)
(3) Then out input erea click, insert over maxlength word!(attach file3)

Deleted: file1.png 72.9 KB

	file1.png 72.9 KB View Download

Deleted: file2.png 81.0 KB

	file2.png 81.0 KB View Download

Deleted: file3.png 99 KB

	file3.png 99 KB View Download

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on Windows 10 using chrome reported version #58.0.3029.110 and latest canary #60.0.3102.0.
Issue is not seen on OS-Mac and OS-Linux.

Bisect Information:
=====================
Good build: 58.0.3004.0    Revision(448183)
Bad Build : 58.0.3006.0    Revision(448862)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/c28047f0537c6ca0718428081abacb913bc106a7..81279cd5b209a34ca4f7702f2a10576faa50fdf9

From the above change log suspecting below change
Review url: https://codereview.chromium.org/2664603002

aelias@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

Example page at https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_text_maxlength

Already shipped to 58 stable, so removing RBS

I was also able to reproduce on Mac

Also very easy to reproduce on Android.  Other example URL: http://output.jsbin.com/hefipumeqa/

changwan@ offered to take a look.

I weirdly haven't been able to figure out yet from code inspection where in Blink maxlength is even applied.  HTMLInputType::maxlengthAttr doesn't seem hooked up to anything.  Not sure what I'm missing since it does work at least for physical keyboard.

FWIW, I had tracked down that the autofill dirty bit I aimed to fix for  http://crbug.com/681822  with the culprit patch was set in HTMLInputElement::SetValueFromRenderer(), so it's likely in that environs.

Ah, looks like there are two separate implementations in  HTMLTextAreaElement::HandleBeforeTextInsertedEvent() and TextFieldInputType::HandleBeforeTextInsertedEvent().  And it's implemented in terms of clamping appended text (even though in a real sense the composing text is already present in the textbox), so I'm not sure it's a great way to do it.

I think the impact of this bug is large. Adding RBS-60.

We're past the early stage of M60 cycle and this is exactly the kind of RBS label usage which is no longer allowed by the new policy in https://docs.google.com/document/d/10Dr_ndtQ-KFS4AGLfqmHLlw3WP3fbsy76wAah_hGfdk/edit .  Please complain there if you want to see the policy changed (I'm complaining on certain points myself and I think it needs more work, although TPMs tell me it's already final and already taken effect).

This affects all text entry (even English) on Android but I haven't seen any other feedback about it after this has been in stable for a long time, so it seems forms that rely on this property are rare in practice.  I'd like to see this fixed too but punting to M61.

Hmm... This may not be related to the regression here, but maxlength seems like another source of editor-IME conflict issue I brought up for  issue 740213  - we need to restart input method to prevent keyboard app from reacting weirdly. But that is preexisting and can be fixed separately.

Uploaded https://chromium-review.googlesource.com/c/576362 for review.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7407bf52fde39b6dcb8f41271d0f664a3abcd683

commit 7407bf52fde39b6dcb8f41271d0f664a3abcd683
Author: Changwan Ryu <changwan@chromium.org>
Date: Wed Jul 19 05:51:13 2017

Clamp composition text when text is too long

input and textarea element can set maxlength attribute to limit the text
length. The desired behavior is to let the IME compose text as much as
they want, and then clamp the text at FinishComposingText() because if
we clamp the text at composition, IME can get confused. Most IMEs do not
seem to care about the change at the finishing stage.

By calling ReplaceComposition(), we get

1) an additional compositionupdate event before compositionend event
2) additional selectionchange events
3) a call to HTML{Input,TextArea}Element::HandleBeforeTextInsertedEvent
   which clamps the text length

Note that this is partially reverting http://crrev.com/2664603002,
and reviving the autofill issue when the text is longer than maxlength.
Autofill clearing + IME is essentially a general IME-editor conflict
issue and may need an additional change to fix it correctly.

BUG= 721666 

Change-Id: I96f24c57e32357248834c756482ffffd4626f29b
Reviewed-on: https://chromium-review.googlesource.com/576362
Commit-Queue: Changwan Ryu <changwan@chromium.org>
Commit-Queue: Yoshifumi Inoue <yosin@chromium.org>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Reviewed-by: Alexandre Elias <aelias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#487768}
[modify] https://crrev.com/7407bf52fde39b6dcb8f41271d0f664a3abcd683/third_party/WebKit/Source/core/editing/InputMethodController.cpp
[modify] https://crrev.com/7407bf52fde39b6dcb8f41271d0f664a3abcd683/third_party/WebKit/Source/core/editing/InputMethodControllerTest.cpp