Braintree-web: Payment fields not rendering with hosted fields

[gerryhigh]

We are randomly seeing cases of users reporting that the 3 hosted fields (credit card number, cvv, & expiration date) are not rendering.

I'm posting this here to see how many others are seeing reports of this. We are using the 3.4 SDK but we've seen it on the 2.x SDK and other 3.x versions.

I've also opened support tickets with Braintree on this but so far they are unable to find out why this is occurring. It is not reproducible and occurs on various browsers & operating systems.

[crookedneighbor]

We have received a few reports of overzealous anti-virus software preventing the Hosted Fields iframes from loading. In these cases, a warning message from the antivirus is loaded into the field iFrames. Because the warning message is designed to be shown on a full page, this often manifests as a slightly off-color field.

Do the fields just appear blank or do they render an off-color background? Are there errors displayed either in the fields or in the browser's console?

[gerryhigh]

The screenshots I've seen have been either
a) boxes rendered but can't type in those fields
b) nothing rendering

In neither case are they off-color or showing errors in the fields. I haven't been able to get anyone to send anything from their console log. We do use a javascript logger and so are able to capture some errors. However, due to an issue with how Braintree hosts (no crossorigin support, see https://www.w3.org/TR/html5/scripting-1.html#attr-script-crossorigin ) their JS files we sometimes get the generic script error vs a detailed stack trace.

[crookedneighbor]

So far, there is not enough information for us to do anything. We'll leave this open for a while in case anyone else reports this issue so we can have more data about what is going on.

[Mneroen]

I've found this bug too. It happens with the latest Opera mini browser on mobile.
User agent: Opera/9.80 (Android; Opera Mini/20.1.2254/37.9172; U; hu) Presto/2.12.423 Version/12.16
https://play.google.com/store/apps/details?id=com.opera.mini.native

You can see the input fields or the input fields border, but the inputs actual height is only 2 pixel.
So you can't see what you type in those fields.

[skunkworks]

@Mneroen Although we expect that Opera Mini should work with Hosted Fields, we cannot provide support because it is not one of our currently supported browsers.

@gerryhigh We are closing this issue for now. If you receive more information that sheds more light on this issue, please feel free to reopen.

[eschie]

@skunkworks We have also been experiencing this intermittent issue. It happens most often on Internet Explorer 11 (similar to this issue), possibly when the preflight options request is aborted and blocks the frame from loading, yet works fine after refreshing the page.

[skunkworks]

@eschie Thanks for the additional info.

[skunkworks]

@eschie We are interested to see if the TCP preconnect workaround from https://github.com/braintree/braintree-web/issues/166#issuecomment-274580932 fixes this issue as well.

[eschie]

@skunkworks Will keep you posted. The IE Fix is in production so if it reduces errors we'll roll out to all browsers.

[cornellouis]

I reproduced this issue today twice in IE11 in < 30 min after we got reports from several users in several browsers (Edge, IE11, Chrome, Samsung Internet 3.1, on computers, phones, and tablets). I experienced it in Mac Chrome during development. Inspecting the javascript, I found that the hosted fields instance was successfully created (as was the PayPal instance I also created), and the iFrames were successfully injected, but the javascript in those iFrames never created an input field. There were no errors in the JS console. Most of the time it does not happen. The PC I reproduced it on was a slow budget PC laptop.

[lilaconlee]

We're taking a look at this issue with the folks on our API Support team! We'll continue to keep you updated if we find a fix.

[cornellouis]

wrapping the hosted fields instantiation in a setTimeout(function () { [hosted fields js] }, 500); seems to solve the problem. I tested in Chrome and IE. Chrome would reproduce with 0 but not with 500. We're calling the braintree instance creation and hosted fields instantiation when a script containing client.js and hosted_fields.js emits the "load" event.... so it looks like maybe hosted fields isn't always finished with its setup when the load event is emitted.

[crookedneighbor]

@cornellouis could you provide a full code snippet for how you're setting it up so we can debug it on our end?

[cornellouis]

@crookedneighbor Ok:

http://pastebin.com/w4bBLpd2

[skunkworks]

@cornellouis If you remove the setTimeout and the task queueing/running, does the behavior improve? It's a bit unclear to me what JSQueue and runTask are used for in your example.

[cornellouis]

We have a single page web app that dynamically downloads and reacts to JS when people click through to a payment page. JSQueue just stores handlers and waits for different JS scripts to emit "load." When the script element for braintree emits "load", the corresponding function passed into runTask() is executed. That's how we avoid race conditions between the script loading and using the window.braintree variable.

If the payment page is loaded directly via url, the braintree script is already in the dom and marked with "defer." My understanding is that deferred scripts run in order, so in that case there is a final deferred script that calls everything that's been passed into runTask() so far. In that scenario, I haven't been able to reproduce it today even without the setTimeout.

[skunkworks]

Thanks for the detailed response -- we will investigate further.

[cornellouis]

This probably has continued to occur in production even w/ the 500ms delay around the hosted fields instantiation. We've found it to be very reproducible when the cache is disabled in Chrome and there is no setTimeout() wrapping the hosted fields instantiation. The particular mode of failure is the canceled load of hosted-fields-frame.min.js. That's why it claims braintree isn't defined. The output from Chrome's net internals is:

{"params":{"priority":"HIGHEST","url":"https://assets.braintreegateway.com/web/3.6.3/html/hosted-fields-frame.min.html#46904ff6-0de8-4ef6-9216-2cf96fbd9233"},"phase":1,"source":{"id":690276,"type":1},"time":"298075886","type":2},
{"params":{"delegate_blocked_by":"NavigationResourceThrottle"},"phase":1,"source":{"id":690276,"type":1},"time":"298075886","type":100},

[skunkworks]

Thanks for the additional info @cornellouis. Do you mind passing along your production site URL to us via [email protected]? This might help us reproduce this on our end.

[cornellouis]

We were previously in contact with support (ticket #1455806) but it didn't seem to go anywhere. I think that includes the information for our sandbox.

[skunkworks]

Sorry about that -- we'll take a fresh look at this.

[crookedneighbor]

@cornellouis Thanks for your patience and exploration on this issue. We still haven't been able to reproduce it, but the screenshots you provided in the ticket clearly show that although the iframe is being loaded, the script file inside the iframe is failing to load.

We're working on a solution to write the contents of the JavaScript in that script file directly inside the iframe when we build the html files. This should ensure that the braintree object is present in the iframe before braintree.hostedFields.create is called.

This will be available in the next release and should solve the issue. I'll update this issue when it has been released.

[eschie]

@cornellouis We've had luck reproducing more often in Firefox or Safari with a freshly cleared cache.

[crookedneighbor]

3.16.0 now dumps the code directly into the iframe, so there's no external request to get the script (hopefully solving the cause of the issue that @cornellouis was able to reproduce).

Could those of you who were able to reliably reproduce the issue try with 3.16.0 and report back your findings?

[cornellouis]

We were able to reproduce. When QA tried, the console showed:

http://imgur.com/a/Iw5ue

When I tried, my console showed:

http://imgur.com/a/50fFc

[crookedneighbor]

@cornellouis can you respond to ticket you opened (#1455806) and provide a staging site with steps to reproduce? We still have not been able to reproduce locally.

[cornellouis]

@crookedneighbor I responded to the ticket w/ the info on our staging server and reproduction steps.

[crookedneighbor]

For our reference in the future, the new ticket number is 1529535

[RikdeBoer]

Is there any further news on this?
What at this stage is the recommended solution, workaround or alleviation of the issue of hosted fields not fully rendering?

[crookedneighbor]

We still have not been able to reliably reproduce the issue on our end, which makes it difficult to track down precisely _what_ the issue is.

Our initial hypothesis was that for some reason script files in the iframes were not loading, so we changed it to inline the JavaScript into the files in version 3.16.0 and higher.

If you have a site and a way to reproduce it reliably, we'd love to be able to take a look at it.

Also, does anyone who is having these issues have a content security policy in place? If so, make sure that you're following the guidelines here in the section about content security policies: http://braintree.github.io/braintree-web/current/

[intelliot]

@cornellouis Our support team replied to your ticket # 1529535. Hopefully, the content security policy suggestion resolved your issue. If not, please follow up with our support team, or open a new issue here on GitHub.

@RikdeBoer In version 3.19.1 (July 5, 2017), we've inlined JS in the HTML files, which could make loading more reliable.

If you're still able to reproduce the issue, please open a new issue or support ticket with a sample app or staging site that demonstrates the problem. We'll investigate from there. Thank you!

[crookedneighbor]

I was just able to reproduce this, and I think I have a fix for it. I'll update here when it is released.

[crookedneighbor]

🤞 This is now fixed with version 3.20.0 https://github.com/braintree/braintree-web/blob/master/CHANGELOG.md#3200

Please report here with reproducible steps if you are still running into this issue and I'll re-open it.

[simeyla]

@crookedneighbor have you had similar issues with vpn software? We just had someone who said disabling NordVPN allowed them to enter their card (hosted fields). I can do some investigating of this but was surprised not to see a single mention of VPN in your past issues. I saw from my logs that the script had an error loading but couldn’t see what it was.

[crookedneighbor]

I've never had SDK issues with vpn software.

If you can find a way to easily reproduce and let us know the error, please open a new issue so we can investigate it.