This issue seems to affect iOS only, but we are seeing it in all browsers (Safari, Chrome, Firefox).
Once the user begins interacting with the credit card field using the iOS keypad, the element scrolls off the page and seemingly disappears. Since our user-base is mostly older and is over 40% on iOS, this is a major issue.
We've tested several potential solutions, but none work in iOS. The behavior of the number keypad in iOS seems to override any JS we try to attach to the
I understand that for security purposes, Stripe cannot allow access to an onChange event, but the way this component is created, we really cannot fix this from the outside.
Hi @toddmyphoto, thanks for reporting this issue. It does seem concerning, and we would love to fix it.
Do you have more information, including:
I'm not able to repro on our examples page: https://stripe.github.io/elements-examples.
Hi @atty-stripe @toddmyphoto ,
I'm experiencing a similar issue. You can duplicate by going to the following demo:
https://test.givz.com/donate/bol
The example I've include below is run in Safari on an iPhone 8 Plus running iOS 11.3
The issue can also be duplicated on other iPhone devices.
Steps to reproduce are as follows:
I've included images named in chronological order (1.png, 2.png, etc.).
Let me know if any more details are required!





Thanks @oscarafuentes! I am indeed able to repro on your page on an iOS 11.4 simulator. I haven't been able to repro in iOS 12 though. We will investigate and follow up here.
I provided code samples to the Support team, but no luck so far... you can test the code (please don't complete checkout, just test the fields) here: https://frontend.staging.myphoto.com/checkout?uid=05275ae4-7bd9-11e8-adb9-0a8e5afe9a72
Once you choose Checkout with Credit Card (on mobile, iOS), then try typing in the credit card field, the field jumps off the screen.
We've isolated so that it doesn't do this as you keep typing, only on the first keystroke, and seems to possibly be fixed in iOS 11.4.1, but is a bug in earlier versions. So reproducing it is spotty, now, but still makes checkout near impossible and our conversion rate is severely down as most of our clientele is on iOS and not everyone is using the latest versions.
Code is
<div id="ccform2">
<h4>Credit Card</h4>
<CardElement {...createOptions(12)} />
</div>
where createOptions is defined: const createOptions = (fontSize) => {
return {
style: {
base: {
fontSize,
display: 'block',
margin: '10px 0 20px 0',
maxWidth: '500px',
padding: '10px 14px',
borderRadius: '4px',
background: 'white',
color: '#424770',
letterSpacing: '0.025em',
fontFamily: 'Source Code Pro, Menlo, monospace',
'::placeholder': {
color: '#aab7c4',
},
},
invalid: {
color: '#9e2146',
},
},
};
};
Just reporting that I can reproduce the problems on both of these pages with an iPhone 6s on iOS 11.4.1. (I cannot reproduce either of the problems on the Simulator for iOS 11.2.)
It appears that the unexpected jumping happens only in the case where the input was low enough on the screen that it had to be repositioned when it was focused and the numeric keypad was shown. Even after triggering that initial condition, scrolling the page so the input is higher on the screen can also prevent the jump.
I don't see any code in this repo that might be implicated, so I'm going to try to reproduce with a plain Stripe.js integration not use react-stripe-elements and see if it happens there.
I recreated the RSE demo without using React or react-stripe-elements, just using Stripe.js, and the problem reproduces there. So this is not an react-stripe-elements bug but a Stripe.js one. Looking into it.
Thanks @asolove-stripe for keeping us in the loop and pressing forward on this issue.
Research note: this appears to not be Stripe.js-specific but a bug in iOS 11.4 Safari. I have jsfiddled a minimal reproduction that shows the components that I believe trigger the bug: an input in an iframe, the iframe in a scroll container other than the document body, and the input having to be scrolled up when the keyboard becomes visible.
I can reliably reproduce this in 11.4. It appears to not be present in iOS 11.2 or 11.3 and also to be fixed in iOS 12 previews. We will file a radar with Apple but may have to wait for iOS 12 for the fix.
I am going to investigate whether Stripe.js can detect the faulty scroll jump and correct it ourselves, but that is a finnicky business and may not be possible.
We had this same issue with other input fields in our form and adding an onChange={e=>{e.preventDefault()}} action to each input fixed this. We cannot access the event (e) on the Stripe Element for obvious security reasons, but perhaps you can work this in to the onChange and onFocus events for the input?
Ooh, @toddmyphoto, thanks for the tip! Unfortunately, it appears that if I add preventDefault to my demo with the input in the iframe, it does not prevent the scroll jump...
(Update: Ah, looks like calling preventDefault inside onKeyDown does prevent this.)
@asolove-stripe -- Nice catch. Yeah, for my Input elements, I had to use onChange, but the Stripe field is a bit different... and being in an iFrame and all...
Another FYI -- we're seeing this across all browsers in iOS -- so I would say it is an iOS bug and isn't specific to Safari.
Yeah, good reminder. Since all browsers on iOS have to use the WebKit engine as their base layer, this does impact all of them.
End of day update: it does not appear that we can safely prevent the scroll jump. I can prevent it by completely ignoring input, but I can't do so safely while still receiving and handling the key input event. I also tried adding a hack to detect if scroll position changes unexpectedly, but there are a host of reasons why this isn't safe for some possible integration paths. I'm sorry but for the moment it looks like we're stuck on Apple fixing this at the WebKit level.
Unfortunately i am faced with the same issue, i just add card number, expire date and cvc elements and found that my iOS screen is jump two time in a row when i click inside input. I think it can be linked with https://q.stripe.com/?event=elements.event.focus and https://q.stripe.com/?event=elements.event.blur requests.
One thing we did to help mitigate this -- move cc field as close to top of page as possible. When users choose to pay with CC, we scroll cc field into top part of page.
The bug, I've found, only occurs if they click or type in the field while it is in lower part of screen. Keep it near the top and no one will notice this bug.
I am facing the same issues and the work arounds with preventDefault aren't working for me.
The site scrolls on iOS to the top of the page, when the user clicks outside the field and triggers the blur event.
I'm getting the same behavior on Firefox for Android currently.
We've seen this behavior in Firefox Android, but it seems to be a bug in the current stable version of Firefox. We cannot reproduce it in the beta version, which I believe will become beta in a couple weeks, and it only triggers on some devices.
My investigation indicate that the scrolling bug in Firefox Android doesn't occur if the height of the iframe is 20px or more. You can influence the height through the lineHeight or fontSize styles in the Element's options.
Closing this as it's a relatively old issue and this project has migrated to React Stripe.js. If you believe this is still important, please re-open it there.
Most helpful comment
One thing we did to help mitigate this -- move cc field as close to top of page as possible. When users choose to pay with CC, we scroll cc field into top part of page.
The bug, I've found, only occurs if they click or type in the field while it is in lower part of screen. Keep it near the top and no one will notice this bug.