#toki-elements-readonly

1 messages · Page 1 of 1 (latest)

brittle shellBOT
odd marlin
#

Hello 👋
Are you using any third-party UI components while rendering Elements on the same page?
Like a modal or something? It's possible that some other component is stealing the focus away from the element inputs

brittle shellBOT
pine niche
#

So, I checked and it seems there is a couple of third-party UI components such as Zendesk, Elfsight, etc. Are any of these known to be conflicting with Stripe?

I'm checking for any more other third parety apps being used on the page

knotty heath
#

toki-elements-readonly

pine niche
#

In the codebase, we also try to make sure that when we initialize stripe, we make sure it loads first (using loadStripe(stripeKey, {}), and use a .then.

So essentially we have a function

waitToLoadStripe() {
return loadStripe().then((stripe) => {return stripe}
}

knotty heath
#

@pine niche we can't really tell you much here. The first step is to debug this on your end to figure out what's happening, what's blocking the input, etc.
You haven't really given much details yet you just say it doesn't work. Like does the UI element render at all? Do you get an empty iframe? What exactly is happening?

pine niche
#

Thanks for giving me the information needed.

  1. What's happening:
    Stripe Element card input sometimes allows users to type in their card and sometimes not

  2. What's blocking the input:
    I'm trying to figure out the same thing. As mentioned, it could be either a third-party app or what I mentioned is something to do with the promise/loading of the element

  3. The UI element renders?
    So it does render, but as titled, it seems to be a read-only (refer to iamge)

  4. Empty iFrame?
    Refer to second image, the div here is empty where when it loads it contains more within the second image's div

image.png image.png
knotty heath
#

So it does render, but as titled, it seems to be a read-only (refer to iamge)
what does that mean "as titled"?

pine niche
#

We've dealt with this issue before, we thought we fixed it by replacing the library using {loadStripe} from @stripe/stripe-js to switching it to @stripe/stripe-js/pure

knotty heath
#

That screenshot is definitely strange. You're using PaymentElement right?

pine niche
#

As titled meaning the thread name is elements-readonly

#

StripePaymentElement, that's correct

knotty heath
#

Is it easy to reproduce? Like do you have a URL where I can make that happen?

pine niche
#

Do you mind if I DM you the website link?

#

It's easy to reproduce, just have to refresh until the bug happens

knotty heath
#

yep go for it, I'll see if someone on my team can help repro and debug with me

pine niche
#

Issue seems to be fixed for now, thank you!

knotty heath
#

oh do you know what it was?

#

also your phone number entry is not properly validating the max length of the phone

#

and then rejects multiple of my attempts 😅

#

I'm mostly curious because when we get reports like this it can be a variety of things and it helps us to have some potential new root caue

pine niche
#

Ah I see, I'm trying to get some info from how it was resolved. I'll update in a sec

knotty heath
#

no rush

pine niche
#

So we're using Webflow, and it's related to loading a script on the website first which is just:

<script async src="https://js.stripe.com/v3/" id="stripe-script"></script>

Which is added to a 'Custom Code' embed on the website. So essentially, the fix was that window.Stripe needs to be loaded on the page from the stripe script tag before our code executes.

On some page the script was "defer" instead of "async". This doesn't fix the issue, but limits the cases when window.Stripe is missing on the checkout form.

Overall, it's almost fixed but I think it's up on my end since it's related to mostly loading the stripe script, such that I need to find a way to wait for window.Stripe to be loaded before loading Checkout Form (to make window.Stripe load asap).

I hope this is enough information and could help!