Unable to reproduce the issue on reported chrome version #70.0.3538.77 using Windows 10 by following below steps.

Steps;
=====
1.Launched chrome.
2.Navigated to "chrome://settings/autofill" and saved the details in name of David.
3.Downloaded and opened "HtmlPage1.html" file.
4.Clicked on "Name" field in Form1 and observed the autofill details.
5.Selected the autofill details and clicked on "Test' against Form1, observed that DOM value is david@david.com.
6.Clicked on "Email" field in Form2 and entered "da" in it later selected the autofill details.
7.Clicked on the "Test" against Form2.
8.Observed that the DOM value is 'david@david.com' but not "da".

Attached screencast for reference.
@reporter: Could you please review attached screencast and let us know if anything is being missed here. Requesting you to check the issue by creating a new person without any apps and extensions in it, reset all flags to default and let us know if it still persists.
Thanks.!

Deleted: 900185.mp4 2.4 MB

	900185.mp4 2.4 MB View Download

This is very strange. I'll send evidence of the behaviour that I've
experienced in two of my machines and a friend's iMac.

On Wed, 31 Oct 2018, 07:55 swarnasr… via monorail <
monorail+v2.3660475610@chromium.org wrote:

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

Unable to reproduce the issue on reported chrome version #70.0.3538.77 using Windows 10 and Mac 10.13.1 by following steps as per comment#0.

Attached screenshots of Mac OS behavior as a reference.
As the issue is not getting reproduce at TE end, hence removing the needs-bisect label and requesting someone from UI>Browser>Autofill team to look into the issue.
Thanks.!

Deleted: version(2).png 232 KB

	version(2).png 232 KB View Download

Deleted: 900185_(Mac).png 122 KB

	900185_(Mac).png 122 KB View Download

Please see the behaviour that I'm seeing.

Deleted: capture-1.mp4 685 KB

	capture-1.mp4 685 KB View Download

My Chrome version says:

Google Chrome	70.0.3538.77 (Official Build) (64-bit) (cohort: Stable)
Revision	0f6ce0b0cd63a12cb4eccea3637b1bc9a29148d9-refs/branch-heads/3538@{#1039}
OS	Windows
JavaScript	V8 7.0.276.32
Flash	31.0.0.122 C:\Users\david\AppData\Local\Google\Chrome\User Data\PepperFlash\31.0.0.122\pepflashplayer.dll
User Agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
Command Line	"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --no-startup-window /prefetch:5 --flag-switches-begin --flag-switches-end
Executable Path	C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Profile Path	C:\Users\david\AppData\Local\Google\Chrome\User Data\Default

With dozens of variations.

Like I've said though, I get this on other computers.

Able to reproduce the issue on chrome reported version# 70.0.3538.77 using Mac 10.12.6, Windows-10 and Ubuntu 17.10 by enabling #network-service flag from chrome://flags, hence providing bisect info

Reverse Bisect Information:
=====================
Last Bad Build : 70.0.3538.93
First Good build: 71.0.3539.0

As the break is between branch and trunk builds, hence providing below manual change log from Omahaproxy
Change log: https://chromium.googlesource.com/chromium/src/+log/70.0.3538.0..71.0.3539.0?pretty=fuller&n=10000
Suspecting: https://chromium.googlesource.com/chromium/src/+/2e8a67679cecb521eee5e76d59d43f8792d08897 from above change log
Change-Id: I2d0d156108667d9463263f4e490761a506bf9a13
Reviewed-on: https://chromium-review.googlesource.com/1196924

Note: Able to reproduce the issue only by enabling the #network-service flag from chrome://flags on reported chrome version, with default chrome settings we are unable to reproduce the issue on chrome reported version, so not adding Release Blocker label to this issue.

@sebsg: Could you please check and merge the fix to M-70 if it is a valid candidate.

Thanks!

 

++ Component

I've no idea what the network service is but I reset all my flags to the default and it doesn't change the behaviour I'm getting.

david@: it's possible that you're in the experiment group for network service, so changing to default won't have any effect. What happens if you go to chrome://flags/#network-service and select "Disabled" in the "Enable network service" option?

 Issue 901015  has been merged into this issue.

Hey Parastoo. This bug happens in M70, but it seems to have been fixed by a CL you landed: https://chromium.googlesource.com/chromium/src/+/97db05cb5fba6275bb9c6bd37d794722da801272/

Could you please check if that's the case? If it is, then could you merge it to the M70 branch? I think the following steps are worth doing:
1. Checkout locally to the M70 branch (.
2. Confirm that the issue is reproducible.
3. Cherrypick your commit.
4. Confirm it fixes the issue.

If so, we can add label Merge-70 to this bug and cherrypick to the release branch once approved. Some useful git commands can be found at http://www.chromium.org/developers/how-tos/drover

Tried to reproduce this on two different machines with Chrome version 70.0.3538.77(Stable) and can confirm that this isn't related to "Network Service", Since I was able to reproduce the issue even with Network service flag disabled.

 - 'Internals>Services>Network' per c#18.

+ Abdul, not sure if this is a real stable blocker for M70.

M71 Stable promotion is coming VERY soon. Your bug is labelled as Stable  ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.

This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Friendly ping to get an update as it is marked as RB stable.
Thanks..!

Reminder M71 Stable is approaching VERY soon. Please review this bug and assess if this is indeed a RBS. If not, please remove the RBS label. If so, please make sure any planned work will be tested in Beta and verified before the Stable date. Thank you.

Requesting to take a look at M71 blockers ASAP due to upcoming Thanksgiving holidays next week.

As we talked offline, since this is already fixed on M71, and it's not a security issue neither causes a crash, it's not worth respinning. Therefore, we'll close it. (Meanwhile, I'm trying to find the root, and a way to avoid this in future.)

The reason it was working on some versions and not the others is this experiment:
AutofillDynamicForms:FullLaunch

Enabled => Bad.
Disabled => Good.

It is disabled by default, and it was enabled between 68.* and 70.*.

See: https://cs.corp.google.com/piper///depot/google3/googledata/googleclient/chrome/finch/studies/AutofillDynamicFormsStable.json

I guess I know which part of dynamic form is causing this, will try to fix it, so that we can enable it by default in future. 

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

commit c5d65c1e555e39252ba0bab71cc773ed843c0eb7
Author: Parastoo Geranmayeh <parastoog@google.com>
Date: Wed Nov 21 05:32:02 2018

[AF] Multiple Nameless/Unowned forms

with repetitive names. The correct form should get filled.

Problem:
1. When an element would go invalid, we would use the section of
elements as one of the hints to find the new version of the old
element in the refill, but only the section of the autofilled fields
were passed. This would break the refills when the visibility of a
field changes. => Set and pass section of all fields.
2. In finding the new version of the old element, the case with more
than two elements with the matching names were not considered.
3. There was a bug in the logic for the nameless forms.

Fixes: https://jsfiddle.net/parastoog/tnh8j9ws/, ~/ds5h7kg4/,
~/w81yc6La/

Bug:  900185 
Change-Id: I26fda7a50b3beb7f7c484a697633ab3b7b5a76d8
Reviewed-on: https://chromium-review.googlesource.com/c/1336492
Commit-Queue: Parastoo Geranmayeh <parastoog@google.com>
Reviewed-by: Sebastien Seguin-Gagnon <sebsg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609921}
[modify] https://crrev.com/c5d65c1e555e39252ba0bab71cc773ed843c0eb7/chrome/browser/autofill/autofill_interactive_uitest.cc
[modify] https://crrev.com/c5d65c1e555e39252ba0bab71cc773ed843c0eb7/chrome/browser/autofill/autofill_uitest.cc
[modify] https://crrev.com/c5d65c1e555e39252ba0bab71cc773ed843c0eb7/chrome/browser/autofill/autofill_uitest.h
[add] https://crrev.com/c5d65c1e555e39252ba0bab71cc773ed843c0eb7/chrome/test/data/autofill/dynamic_form_element_invalid_multiple_noname_forms.html
[add] https://crrev.com/c5d65c1e555e39252ba0bab71cc773ed843c0eb7/chrome/test/data/autofill/multiple_noname_forms_badnames.html
[modify] https://crrev.com/c5d65c1e555e39252ba0bab71cc773ed843c0eb7/components/autofill/content/renderer/autofill_agent.cc
[modify] https://crrev.com/c5d65c1e555e39252ba0bab71cc773ed843c0eb7/components/autofill/content/renderer/autofill_agent.h
[modify] https://crrev.com/c5d65c1e555e39252ba0bab71cc773ed843c0eb7/components/autofill/content/renderer/form_autofill_util.cc
[modify] https://crrev.com/c5d65c1e555e39252ba0bab71cc773ed843c0eb7/components/autofill/core/browser/autofill_manager.cc

Got the update for "Version 71.0.3578.80 (Official Build) (64-bit)".  This is still not working properly.  I'll provide a test link below.

http://jsfiddle.net/pur5box6/

The bug is fixed, but it wasn't merged into 71. There was a little miscommunication over this, the feature was disabled, so I thought we don't need to merge it (the bug happens when dynamic form feature is on), but it got enabled meanwhile.