More clear comments at http://jsfiddle.net/0wzvmyfs/

Unable to reproduce the issue on mac 10.13.3 using chrome reported version #70.0.3538.67 and latest canary #72.0.3589.0.
Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to http://jsfiddle.net/xv23q5Lg/
2. Clicked in the text field to autofill the values.
3. Observed that the values got autofilled without any issues.

benrotz@ - Could you please check the attached screen cast and please let us know if anything missed from our end. Also please check the issue on latest canary #72.0.3589.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.
Please let us know if it is specific to OS-mac mojave?

Thanks...!!

Deleted: 898346.mp4 862 KB

	898346.mp4 862 KB View Download

We tested the following in incognito mode:

Machine #1: mac 10.13.6 (High Sierra), chrome 70.0.3538.67 YES bug

Machine #2: mac 10.14, chrome 69.0.3497.100 NO bug

Machine #3: mac 10.14, chrome 70.0.3538.67 YES bug

Machine #3 (same as previous test): mac 10.14, chrome canary 72.0.3590.0 NO bug

I have attached a screencap of the bug. Interesting to note that the dropdown item that normally shows "Manage..." is empty when the bug presents itself. You can see that the cursor does not place itself at the end of the input on the name input, and the email input becomes "locked".

Interestingly enough, the bug does not reproduce if the button in the FIRST form is removed, or is replaced with `<input type="hidden">`, although replacing with `<input type="text">` still produces the bug.

Deleted: autofill_bug.mov 2.0 MB

	autofill_bug.mov 2.0 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Able to reproduce the issue on Mac 10.13.6, Win-10 and Ubuntu 17.10 using chrome reported version #70.0.3538.67 but the same is not reproducible in the latest canary #72.0.3590.0.

Reverse Bisect Information:
=====================
Good build: 71.0.3539.0
Bad Build : 70.0.3538.79
Note: Providing the change log from omahaproxy as the good and bad builds are from different milestone and one of them is a branch build.

Change Log URL: (From omahaproxy)
https://chromium.googlesource.com/chromium/src/+log/70.0.3538.0..71.0.3539.0?pretty=fuller&n=10000

From the above change log suspecting below change
Change-Id: I2d0d156108667d9463263f4e490761a506bf9a13
Reviewed-on: https://chromium-review.googlesource.com/1196924

sebsg@ - Could you please check and merge the fix to M-70 if it is a valid candidate.
Note: Adding stable blocker for M-70 as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

I was able to fill sucessfully, and using the devtools I was able to check that the value was correctly set.

As of the blank suggestion line this is a known issue. Merging this bug into that one.

Great! To be clear, tho, the missing "Manage..." text is a minor issue compared to the actual issue: not being able to actually autofill anything.

Ah, sorry. I'm not sure I understand then. In both videos I saw Autofill seemed to have filled the fields? I also tried it myself and was able to fill the fields and confirmed that the value was set by querying it via JavaScript.

Am I missing something?

In the 2nd video, notice the position of the cursor AFTER the autofill is selected. It treats the value "Ben Rotz" almost like a placeholder (e.g. the actual text is not editable). Indeed, when typing more letters, even though the cursor is in first position, the text disappears. The 2nd input behaves the same.

I have attached a screen recording which shows normal behavior (http://jsfiddle.net/hf7dj3x0/), which happens in the absence of the first form with button, and then the buggy behavior (http://jsfiddle.net/xv23q5Lg/). In the bugged tab, I am clicking repeatedly on the input to try and reposition the cursor to no avail.

Thanks

Deleted: chrome-bug.mov 7.1 MB

	chrome-bug.mov 7.1 MB View Download

In addition to comment #6, able to reproduce the issue on enabling flag #network-service.

Thanks...!!

Thanks for the clarification, I was able to reproduce this as well. This is very strange, I'll have to investigate a bit more, but it looks like the field is stuck in the "preview" state, and is not really in the "filled" state.

Friendly ping! Could you please provide any update on this issue as it has been marked as a stable blocker.

Thank You!

Took me a while but I figure it out.

What happens is that Autofill gets confused with the forms and fields. Since the first form and field match (no name and no id for form and field) Autofill gets greedy and picks the first one.

The consequence is that the actual field remains in a preview state.

I'll start working on a fix. In the meantime, this can be fixed by adding name/id to the form and fields.

Also since this is corner case, I'll remove the release blocker label.

Thanks again for flagging this!

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

commit e39d1178a45f7488b406337465d475f04776d5aa
Author: sebsg <sebsg@chromium.org>
Date: Wed Nov 07 23:56:46 2018

[AF] Only try to replace the triggering element during a re-fill.

There is an issue with the replacing logic if the forms and fields
have no identifier. This CL does not fix this directly, but greatly
reduces the cases where it will happen (only dynamic forms with more
than one form with no id).

Rogerm@ is working on a better way of identifying fields that
should help resolve this: crbug.com/896689

Bug:  898346 
Change-Id: I7e17a6a2009be9e376088640bb14a81549ebbef2
Reviewed-on: https://chromium-review.googlesource.com/c/1319851
Commit-Queue: Sebastien Seguin-Gagnon <sebsg@chromium.org>
Reviewed-by: Fabio Tirelo <ftirelo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606224}
[modify] https://crrev.com/e39d1178a45f7488b406337465d475f04776d5aa/chrome/browser/autofill/autofill_interactive_uitest.cc
[add] https://crrev.com/e39d1178a45f7488b406337465d475f04776d5aa/chrome/test/data/autofill/forms_without_identifiers.html
[modify] https://crrev.com/e39d1178a45f7488b406337465d475f04776d5aa/components/autofill/content/renderer/autofill_agent.cc

This bug requires manual review: M71 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

This is regressed in M70, not a stable blocker per comment #14 and we're very close to M71 stable promotion. Pls target fix for M72.