You mean M56 stable, right?

Yes, sorry. M56.

I tested this with the test credit card number (Visa	4111111111111111) and the form submitted ok. I received a Credit card payment declined message as seen in the attached screenshot which was expected.

mardini@, is there additional information available about the failure message that was received?

Deleted: Simulator Screen Shot Feb 2, 2017, 1.53.04 PM.png 245 KB

	Simulator Screen Shot Feb 2, 2017, 1.53.04 PM.png 245 KB View Download

I tried again on my iPhone 6s running 10.2.1 and got an error (attached). Lindsay: are you able to reproduce this?

Deleted: IMG_3640.PNG 107 KB

	IMG_3640.PNG 107 KB View Download

Yes I am able to repro this issue on iPhone7 with iOS 10.3. 

I would suggest don't try to repro with a fake card, fake cards are a different path to get auto declined. Use a real card, and if you are worried about cost (should your purchase go through) you should expense the cost as bug investigation. All is needed is to CC your TL on this bug and give them a heads up before you submit the expense report. Keep the donation amount to $35 each try. 

I understand the code paths may be different, but mardini was able to repo the error with the fake credit card number previously. (I may need to reproduce this a lot before I can pinpoint a cause so that repo path is more ideal.)

That said, I tried with a real card and there was no problem submitting the form. I did NOT have the send me emails boxes checked and I entered $5 as the donation amount.

I can't reproduce it on my side at all. I tried with an iPhone5s on iOS 10.2.1 (and 10.1 before it was updated.) (Could this potentially be a server side issue?)

If the error is consistently reproducible, are there any steps that can be done to make it work, like unchecking the email boxes or trying $5 which was the state when it worked for me?

I left the email box unchecked and selected the suggested amount box of $35 and it repro's for me each time.

lindsayw@, can you confirm steps above are exactly correct and possibly provide screenshots of data entered (you can leave credit card section blank). I'd like to try exact steps to reproduce. Maybe this is not reproducible in MTV?

I tried both on stable and dev build from Xcode and couldn't repo in either case.

Here are the exact steps I've taken which result in the error. Below is a link to the screenshot.

App version: 58.0.3005.0
iOS version: iOS 10.3 beta 2
Device: iPhone7

Steps to reproduce: 
1. Load https://action.aclu.org/secure/donate-to-aclu
2. Tap Make a One-time Gift
3. Fill all required fields:
  select $35, 
  uncheck "send me emails" box
  fill in the address, 
  and use a fake or real CC number. 
  I used the fake cc number 4111 1111 1111 1111, with exp Feb 2020 and CID: 111
4. Tap Submit

Observed behavior: 
Page says: 
"
We had problem with the form:
There was a problem with your form
submission. Please refresh the page
and try again.
"
Screenshot: https://drive.google.com/file/d/0By4O1f2IQqQ_YkdzTDdqS01sM28/view

I am following the same steps and am still unable to reproduce on device or simulator here.

lindsayw@, Does this repo in Chrome on the iOS Simulator as well? It looks like the site is using "fastly.net" which presents a different site IP based on location.

For example of the various IPs, please see: https://geopeeker.com/fetch/?url=https%3A%2F%2Faction.aclu.org%2Fsecure%2Fdonate-to-aclu

I'm pretty sure that this is a server side bug and we should contact webmaster and close it.

Alternatively we can ask Lindsay to use Charles (or something similar) to capture HTTP request so we can take a look if it is correct. However I don't think it worth the effort.

Does it reproduce in webshell? 

I think we've figured out the steps needed to reproduce the problem.

The user needs to be a) signed in to their corp account AND  b) have the Google Apps Device Policy installed under Settings > General > Device Management. 

Lindsay and Chris: Could you please confirm that you satisfy these two criteria in your reproduction cases? 

I tried on a new phone, no accounts corp or gmail installed on the device. With a real credit card the transaction went through successfully. 

With a fake credit card I got the following error:
"
We had a problem with the form:
Credit card payment declined. This 
transaction has been declined.
"
 
With a real credit card the transaction also goes through successfully on the WebView app set to WKWebView.

On the sam device if I login to corp account, the same steps and failure as outlined in comment #11 occur.

So it sounds like the criteria I outlined in #15 are correct?

I am now able to reproduce this by signing into a corp account (on device only). Still investigating, but it appears that the there are two referrer fields that do not get filled out properly in the broken case. The page loads with the fields empty, but likely filled in via javascript. They are hidden input fields with ids: "edit-submitted-referrer" and edit-submitted-initial-referrer.

It actually doesn't look like the issue is related to the referrer fields having a value or not.

I was just able to submit the form with an empty referrer value while NOT signed in, and I saw the credit card declined error, which means the form can be successfully submitted both with and without values in these form fields.

I haven't pinpointed the exact problem, but it looks like this is related to autofill. I can workaround this issue if I comment out the contents of |initWithBrowserState:webState:| in //ios/chrome/browser/autofill/autofill_agent.mm

CCing others who may have insight into what could be causing this breakage.

tl;dr autofill appears to break submitting this form, but only when signed in with a corp account.

+ rogerm@ who I believe is owning autofill now? (more context is in the description and comments) 

Thanks, Michael! 

I believe you need to be signed in with a corp account *and* have the Google Apps Device Policy installed. I was unable to reproduce it if I am just signed in to my corp account. 

Can we reach out to them to ask them what about the request is failing in the signed in case vs not?

A couple notes:

- I've never signed into a corp account on this phone, so I don't believe that it is related.
- Autofill was active for me on that form when the failure happened.

Thanks beckmann for that info, it prompted me to try the following which lead me to believe this is simply a breakage caused by autofill.

While signed in, I tried filling out the form twice as described here:
1. I used autofill to fill out the form (except credit card) and the "form submission problem" was displayed.
2. I manually filled in all fields, and I saw the credit card auth error. In this case, the autofill suggestion was present, but I did not choose to use autofill to fill in the form.

The issue is that autofill fills out a field with id "edit-aclu-name". It is hidden form view, and there is a note in the page source to keep it blank. (Please see attached screenshot.) Although this doesn't repo on Chrome desktop for me, I am able to repo on desktop if I manually edit the element value for the form element before I submit the form.

Deleted: Screen Shot 2017-02-15 at 4.34.00 PM.png 2.6 MB

	Screen Shot 2017-02-15 at 4.34.00 PM.png 2.6 MB View Download

Is there anyone on Autofill team who'd like to take this bug?

this is dup of issue 132135

Thanks everyone for tracing down the root cause. It seems it was associated with being logged in to corp accounts for some of us because auto-fill was not active in the other cases. Also, when there is no MDM certificate, sync doesn't work, so auto-fill doesn't kick in and the form submission works. 

While the broader issue of hidden form fields continues to exist, perhaps we could explicit mark this field as unfillable from the server. Roger?

A manual override of this field's classification is in flight.

I'll post an update here once it takes effect.

Ok, this should be fixed now.

Please retest in an incognito window to ensure you're not using cached field classifications (i.e., it was previously being assigned a "first name" type).

Looks good to me, validated in incognito.