Takayoshi: please reassign to more relevant person if needed. 

Thanks kolos@ for the report!
tkent@ will be back soon, he will be able to triage this.

Looks like this page prevent all text-input events, and set the value by web-exposed HTMLInputElement.prototype.value setter.  So, DidSetValueByUserEdit should not be called.

tkent@: thanks for explanation, but the password manager has to work anytime a user types something into a password field. How can we fix this issue for such sites?

Perhaps we should listen another method but not DidSetValueByUserEdit, but we have no idea which one)

My rough idea is to add chrome_client->DidChangeValueInTextField() call at the end of HTMLInputElement::setValue() if value_changed && UserGestureIndicator::ProcessingUserGesture().

Seems good.

and thank you very much for the idea :)

https://chromium-review.googlesource.com/c/chromium/src/+/856996

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

commit 6a83c2c4d82e4c1c196580539ac271ae2b592656
Author: Maxim Kolosovskiy <kolos@chromium.org>
Date: Thu Jan 11 11:52:59 2018

[Password Manager] Notify WebAutofillClient even if the page prevents all text-input events


Bug: 798716
Change-Id: I0c2cc3ba143f20cb1211c884be11e3d9dee9311f
Reviewed-on: https://chromium-review.googlesource.com/856996
Commit-Queue: Maxim Kolosovskiy <kolos@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528600}
[modify] https://crrev.com/6a83c2c4d82e4c1c196580539ac271ae2b592656/third_party/WebKit/Source/core/exported/WebViewTest.cpp
[modify] https://crrev.com/6a83c2c4d82e4c1c196580539ac271ae2b592656/third_party/WebKit/Source/core/html/forms/HTMLInputElement.cpp
[modify] https://crrev.com/6a83c2c4d82e4c1c196580539ac271ae2b592656/third_party/WebKit/Source/core/testing/data/input_field_password.html

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

commit 0beb84f6ed32bb09b70bc27a75f5659235df7c19
Author: Maxim Kolosovskiy <kolos@chromium.org>
Date: Tue Jan 16 10:52:53 2018

Revert "[Password Manager] Notify WebAutofillClient even if the page prevents all text-input events"

This reverts commit 6a83c2c4d82e4c1c196580539ac271ae2b592656.

Reason for revert: The CL cause performance regressions 
https://bugs.chromium.org/p/chromium/issues/detail?id=801739
https://bugs.chromium.org/p/chromium/issues/detail?id=801651

Original change's description:
> [Password Manager] Notify WebAutofillClient even if the page prevents all text-input events
> 
> 
> Bug: 798716
> Change-Id: I0c2cc3ba143f20cb1211c884be11e3d9dee9311f
> Reviewed-on: https://chromium-review.googlesource.com/856996
> Commit-Queue: Maxim Kolosovskiy <kolos@chromium.org>
> Reviewed-by: Kent Tamura <tkent@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#528600}

TBR=tkent@chromium.org,kolos@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 798716
Change-Id: I9d025eaec13f1e88c4681898fa2c18825fcbd5b5
Reviewed-on: https://chromium-review.googlesource.com/867830
Reviewed-by: Maxim Kolosovskiy <kolos@chromium.org>
Commit-Queue: Maxim Kolosovskiy <kolos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529396}
[modify] https://crrev.com/0beb84f6ed32bb09b70bc27a75f5659235df7c19/third_party/WebKit/Source/core/exported/WebViewTest.cpp
[modify] https://crrev.com/0beb84f6ed32bb09b70bc27a75f5659235df7c19/third_party/WebKit/Source/core/html/forms/HTMLInputElement.cpp
[modify] https://crrev.com/0beb84f6ed32bb09b70bc27a75f5659235df7c19/third_party/WebKit/Source/core/testing/data/input_field_password.html

If adding IsProcessingUserGesture check doesn't regress performance, it's very reasonable.

If not, we might need asynchronous notification about form value change.

FYI: A large number of pages set .value() on input controls as a part of feature detection and other automatic operations. The change in #12 broke Chrome's HTTPBad feature (resulting in "Not Secure" unexpectedly being shown on a huge number of HTTP pages where the user did not manually interact with the input field.  Issue 803264  adds a browser test to detect future regressions here.) 

In addition to HTTPBad, the DidChangeValueInTextField handler in Chrome also treats calls as a PageImportanceSignal (because typing in a field is considered a signal of the page's importance) so the change in #12 would also impact our page importance logic used for tab discarding, etc.

elawrence@: thanks for your comment, very interesting. Does it mean that we can try to re-land #12 and see whether it cause a regression again?

If you re-land #12, it will re-introduce the functional regressions described in #15. 

 Issue 803264  introduced a browser test which is designed to fail if #12 is resubmitted.