Please provide us with sample webpages/ testcases for the ease of finding regressions.

I could reproduce this issue with the tweak that the iframe was loaded dynamically not as part of the initial page load. The attached example, once staged on a web server, shows the issue. Also demonstrated on the screenshot, which captures the page after pressing "Add frame".

Deleted: 669045_repro.tar.bz2 929 bytes

669045_repro.tar.bz2 929 bytes Download

Deleted: frames.png 50.4 KB

	frames.png 50.4 KB View Download

This is indeed a bug.

Normally, the frame which registers the first user interaction notifies the  ChromeAutofillClient::OnFirstUserGestureObserved, which in turn notifies all frames of that tab.

But this only happens once, since then all frames are considered notified. Adding a frame later does not trigger the notification. That's what I'm going to fix.

I had forgot to mention that the iframe was dynamicly added, sorry for that ...
Anyway, I can confirm this is exactly my use case (a sign in page loaded in a iframe modal)

Thanks vabr !

Thanks for the confirmation (and the report, in the first place)!

Sorry for the delay, some other work takes most of my days recently.
The fix itself here will be easy, but the tests will be a challenge, which is why it may take longer. Still on it, though.

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

commit 603bbb6727a01a230ec804a2367537dd9aa11dc5
Author: vabr <vabr@chromium.org>
Date: Fri Dec 23 13:37:52 2016

Add user-gesture-related tests for ContentAutofillDriver

The methods ContentAutofillDriver::FirstUserGestureObserved and
ContentAutofillDriver::NotifyFirstUserGestureObservedInTab do not seem to be
tested yet. This CL adds tests for that.

This is in preparation to fixing  https://crbug.com/669045 , to avoid inflating
the CL with the fix by adding tests for existing code.

BUG= 669045 

Review-Url: https://codereview.chromium.org/2603583002
Cr-Commit-Position: refs/heads/master@{#440624}

[modify] https://crrev.com/603bbb6727a01a230ec804a2367537dd9aa11dc5/components/autofill/content/browser/content_autofill_driver_unittest.cc

The fix is https://codereview.chromium.org/2603623002 (works locally with my reproduction case). It is blocked on a refactoring needed to make testing possible: https://codereview.chromium.org/2606473003/.

I'm afraid landing the fix will take a while, because (1) most of reviewers are currently on holiday, and (2) the refactoring might be a bit controversial (testing this part of code turns out to be challenging https://groups.google.com/a/chromium.org/d/msg/chromium-dev/EMMjQcJacvo/4ICuw0xjDwAJ), and (3) I expect to be away for a longer period soon.

Sorry for the delay, I was on a long leave. Now back at work. My first step here is to propose a necessary refactoring of ContentAutofillDriverFactory to allow reasonable tests for the fix (https://codereview.chromium.org/2603623002) to the autofill team (I scrapped the idea from https://codereview.chromium.org/2606473003/, because it only worked by good luck). Once agreed, I'll make that refactoring and land the fix.

The refactoring proposal is https://docs.google.com/a/chromium.org/document/d/1CZRzRv5p1SnClgOYydZ7epVpEqYxJdgRSCEpRXml-xU/edit?usp=sharing. It should be accessible to all @chromium.org accounts. Feel free to let me know if you need to view this but cannot. I will update this bug once the proposal is accepted and implemented.

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

commit f68e6ab0d88250d9547590aadc0d885399979158
Author: vabr <vabr@chromium.org>
Date: Wed Feb 22 23:08:42 2017

Split non-//content parts from ContentAutofillDriverFactory

This CL extracts the logic for managing AutofillDriver instances from
ContentAutofillDriverFactory and puts it in a separate AutofillDriverFactory
class. The goal is to achieve better testability. More details are in the
design doc
https://docs.google.com/a/chromium.org/document/d/1CZRzRv5p1SnClgOYydZ7epVpEqYxJdgRSCEpRXml-xU/edit?usp=sharing.

BUG= 669045 

Review-Url: https://codereview.chromium.org/2715483002
Cr-Commit-Position: refs/heads/master@{#452258}

[modify] https://crrev.com/f68e6ab0d88250d9547590aadc0d885399979158/components/autofill/content/browser/content_autofill_driver_factory.cc
[modify] https://crrev.com/f68e6ab0d88250d9547590aadc0d885399979158/components/autofill/content/browser/content_autofill_driver_factory.h
[modify] https://crrev.com/f68e6ab0d88250d9547590aadc0d885399979158/components/autofill/core/browser/BUILD.gn
[add] https://crrev.com/f68e6ab0d88250d9547590aadc0d885399979158/components/autofill/core/browser/autofill_driver_factory.cc
[add] https://crrev.com/f68e6ab0d88250d9547590aadc0d885399979158/components/autofill/core/browser/autofill_driver_factory.h
[add] https://crrev.com/f68e6ab0d88250d9547590aadc0d885399979158/components/autofill/core/browser/autofill_driver_factory_unittest.cc

The refactoring landed (#13 here) and I will be able to adapt the fix https://codereview.chromium.org/2603623002/ and land that hopefully on Friday.

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

commit ce7eba36c420dabb86b57f1851d5c86115d7d13c
Author: vabr <vabr@chromium.org>
Date: Mon Feb 27 17:41:47 2017

AutofillDriverFactory manages information about user gestures

When a password field is autofilled, the value is not accessible to JavaScript
until the user clicks or types in the page. To keep track of this, the frames
report such user gestures, and ChromeAutofillClient distributes such a signal
to all other frames in the same WebContent, via their common
AutofillDriverFactory.

This does not work when a new frame is added later, because the browser process
does not keep track whether the user gestures were seen already. Newly added
frames never learn about the user already having clicked in the page.

This CL fixes that by modifying AutofillDriverFactory to remember the
user gestures and notify also drivers added later. The flag is reset on main
page navigation.

The CL also makes parts of the AutofillDriverFactory API public, as long as they
do not modify the drivers map. This results in a slight reordering of methods.

BUG= 669045 

Review-Url: https://codereview.chromium.org/2603623002
Cr-Commit-Position: refs/heads/master@{#453245}

[modify] https://crrev.com/ce7eba36c420dabb86b57f1851d5c86115d7d13c/chrome/browser/ui/autofill/chrome_autofill_client.cc
[modify] https://crrev.com/ce7eba36c420dabb86b57f1851d5c86115d7d13c/components/autofill/content/browser/content_autofill_driver.h
[modify] https://crrev.com/ce7eba36c420dabb86b57f1851d5c86115d7d13c/components/autofill/core/browser/autofill_driver.h
[modify] https://crrev.com/ce7eba36c420dabb86b57f1851d5c86115d7d13c/components/autofill/core/browser/autofill_driver_factory.cc
[modify] https://crrev.com/ce7eba36c420dabb86b57f1851d5c86115d7d13c/components/autofill/core/browser/autofill_driver_factory.h
[modify] https://crrev.com/ce7eba36c420dabb86b57f1851d5c86115d7d13c/components/autofill/core/browser/autofill_driver_factory_unittest.cc

#15 should have fixed this issue on trunk. This means it reaches Canary in a day or two. Luckily, branch point for 58 is soon, so it should not take long for this to reach beta (as soon as it hits version 58).

If people still can see this issue in Chrome 58 the day after tomorrow, please update this bug or e-mail vabr@chromium.org.