New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mobile issue with Stripe Integration (Retrieving stripe.js from the incorrect URL?) #1057

Closed
jaspuduf opened this Issue Feb 24, 2017 · 22 comments

Comments

Projects
None yet
6 participants
@jaspuduf

jaspuduf commented Feb 24, 2017

EXPLANATION OF THE ISSUE

Hi there,

I was asked by Tim in the sharks forum to post this here. We have been getting several reports from users that are trying to sign up for an account on mobile that they are having a problem inputting their billing information with Stripe. This affects only about 1 in 20 sign ups, but we have had 6-7 report it and couldn't sign up.

When they click on the add billing from mobile, the entire screen goes "dull" or grayed out and they can't put in their information at all. The ones where it works correctly get a new window that pops up and are able to input their information.

I spoke with Tim (KTS915) at the wpsharks forum and he said to talk to Stripe about an error code he was seeing from the Chrome console. This was that error code:

https://js.stripe.com/debug/cdninfo?callback=scdnrumjsonp_httpsjsstripecomdebugcdninfo
Failed to load resource: the server responded with a status of 404 (NOT FOUND)

He recommended reaching out to Stripe for an answer. This was their response:

Hi there,
Hopefully I can help clear up your confusion.

It appears that the s2member code is attempting to retrieve stripe.js from the incorrect URL.

As you can read in our docs (https://stripe.com/docs/elements#setup) stripe.js should only be loaded from the URL of https://js.stripe.com/v2/ or https://js.stripe.com/v3/. You can read about the distinction between the two versions at the link I mentioned above.

I would suggest that s2member ensure that their code isn't malforming URLs and that they are attempting to load Stripe.js from the correct location.

I realize that this probably isn't the answer that you wanted to hear, but I think it should be enough to get you going.

Good luck and happy hacking!
-zach

STEPS TO REPRODUCE THE ISSUE

I haven't been able to replicate the issue myself on any of my devices or any other programs, but I have seen a screenshot it. Our domain is http://pluginvegas.com and we are getting the issue on all of our Join pages. Here is a link to one of the join pages: http://pluginvegas.com/7forever/

The issue happens when they click on the add billing slot to put in their credit card number. It is only for mobile phone users and only like 1 in 20 people.

BEHAVIOR THAT I EXPECTED

It should pop open a brand new window on mobile, but doesnt for some users.

Here is the link to the wpshark forum post if you need it at all for any reason:

https://forums.wpsharks.com/t/cell-phone-sign-up-issues/1600

Edit: Here is the screenshot that I got from someone a while ago when it happened: They are unable to type anything anywhere

pivimage

Edit2: Newest version of WP and s2member, though we have had reports of this in the past with older versions of s2member.

@raamdev

This comment has been minimized.

Contributor

raamdev commented Feb 24, 2017

@jaspuduf I just ran your site through a few tests and the Stripe checkout form seems to be behaving as expected. Here's a video showing both a Desktop test and a Mobile test: http://quick.as/nk9quDLov

I did not find any error in the JavaScript console on the checkout page of your site, or anywhere else on your site for that matter.

As you can read in our docs (https://stripe.com/docs/elements#setup) stripe.js should only be loaded from the URL of https://js.stripe.com/v2/ or https://js.stripe.com/v3/. You can read about the distinction between the two versions at the link I mentioned above.

s2Member doesn't use Stripe Elements, it uses Stripe Checkout, which the docs show calls for using https://checkout.stripe.com/checkout.js, which is what s2Member uses.

When Stripe's JS detects that a Mobile Browser is trying to load the Checkout modal, it redirects the user to a separate page where they can insert their payment info. The fact that the screenshot you supplied shows that the desktop modal tried to load on a mobile device tells me that Stripe's JS did not properly detect that a mobile device was loading the checkout form, hence the issue.

I suggest bouncing this back to Stripe's support, as s2Member is not loading specific elements or doing any mobile device detection here. We're using the Stripe checkout.js, which means other than loading checkout.js, s2Member doesn't handle any of that front-end Stripe payment window.

@jaspuduf

This comment has been minimized.

jaspuduf commented Feb 24, 2017

Thanks @raamdev . I forwarded this on to Stripe and will update when I get a response.

I personally haven't been able to reproduce it either, but we've gotten a few more with the problem since I posted.

@jaspuduf

This comment has been minimized.

jaspuduf commented Feb 24, 2017

This might not be of much help to the discussion, but I was finally able to reproduce the issue in Chrome inspector.
123455

@raamdev

This comment has been minimized.

Contributor

raamdev commented Feb 25, 2017

@jaspuduf Thanks for sharing the screenshot. That does still look like an issue with Stripe's mobile detection. I'm not even sure where the js.stripe.com/debug/ is coming from, as that doesn't appear anywhere in s2Member's source code.

@jaspuduf

This comment has been minimized.

jaspuduf commented Mar 2, 2017

Hey! Here is the most recent response from Stripe about the issue:

Hi Jason,
I haven't forgotten about you - I've been digging and bugging other engineers for their thoughts on what may be going on here.

The https://js.stripe.com/debug/cdninfo?callback=scdnrumjsonp_httpsjsstripecomdebugcdninfo URL was previously used for some internal CDN statistics that we used to collect but no longer do. I suspect that s2member is using a deprecated URL for fetching the Checkout scripts or a deprecated version thereof. As this functionality is only in the Pro version, I cannot inspect the code to determine the exact URL that s2member is using.

I would suggest that s2member verify that they are loading Checkout directly from https://checkout.stripe.com/checkout.js, and that they aren't passing any query string parameters.

If I find anything more from my digging on our side, I'll reach back out to you, but I suspect that the root cause of this is entirely within the s2member Pro source and how they are loading Checkout.

@jaswrks

This comment has been minimized.

Member

jaswrks commented Mar 2, 2017

I would suggest that s2member verify that they are loading Checkout directly from https://checkout.stripe.com/checkout.js, and that they aren't passing any query string parameters.

That is correct, yes. Stripe can review the pro source code here if they'd like to confirm.
https://github.com/websharks/s2member-pro/blob/170221/src/includes/separates/gateways/stripe/stripe.js#L41

@jaspuduf

This comment has been minimized.

jaspuduf commented Mar 10, 2017

Hey! I just wanted to follow up with Stripe's last response.

Hello,
I have tried many times, and I cannot recreate this use the chrome inspector, nor can I recreate this on any of my mobile devices. I'm sticking with my initial thought here that the users that get this behavior are likely using an outdated unsupported browser.

Given that there are no additional reports of this issue, this could also be caused by some other JS on your page.

Though I hate to redirect you, Stripe didn't build this plugin, so I'm afraid we don't have much insight here. The issue you are seeing is assuredly either an error caused by s2member or something else on your page.

We've tried moving the purchase form to its own page with nothing else on it to see if that would fix the problem.

https://pluginvegas.com/7-forever-purchase/?s2-ssl=yes

Unfortunately, we started running another sale this weekend and have had 5 or 6 reports already. We've had about 20 successful registrations in that time frame today as well. I am going to try and get information from people on what type of device they are using and hopefully that might help?

The first two were on a new ZTE from MetroPCS and a Galaxy Tab 4 10.1"

EDIT: It looks like a lot of random platforms so far.
ZTE from MetroPCS
Galaxy Tab 4 10.1"
LG K7
Samsung galaxy 7

Could it somehow be related to our theme we use? We use the Divi theme from Elegant Themes
Divi.zip
https://www.elegantthemes.com/

EDIT2: I was also seeing this error in the Chrome console when testing mobile. Not sure if this is related at all because most of this is way over my head.

Unable to preventDefault inside passive event listener due to target being treated as passive. See https://www.chromestatus.com/features/5093566007214080

It happens when I start scrolling some of the time using the mobile console on Chrome

I googled these and there are some current comments. Sorry if this has nothing to do with it. Trying my best to help :)
Mango/slideout#205

@KTS915

This comment has been minimized.

KTS915 commented Mar 10, 2017

@jaspuduf @jaswrks @raamdev The last comment in the thread to which the last hyperlink provided by @jaspuduf links suggests that this is an issue with Chrome.

So, @jaspuduf, are you able to confirm that all the users who have experienced this have been using Chrome?

@jaspuduf

This comment has been minimized.

jaspuduf commented Mar 10, 2017

My bad I think on attaching that link... We've still had zero issues from any desktop or laptop. That was just a thread I saw linked to an error code I got when using the chrome console for mobile tester. Probably a decent chance it's unrelated (I'm not super knowledgeable on all of this).

It's looking like it's coming from a lot of different devices, but all mobile or tablet. I've recently tried taking everything out of the headers and shutting down non -essential plugins to see if that fixes anything.

@KTS915

This comment has been minimized.

KTS915 commented Mar 10, 2017

@jaspuduf But is the common thread that they are all using Chrome on those devices?

@jaspuduf

This comment has been minimized.

jaspuduf commented Mar 10, 2017

I actually just asked them which phone or tablet they were using (was assuming they were using the standard that comes on each). We are running the sale through the weekend so we'll have plenty more and I will start asking for browser information as well :)

@jaspuduf

This comment has been minimized.

jaspuduf commented Mar 10, 2017

Doesn't look like any common thread with which browser is being used or which device. They're all over the place. Shutting down all the other non-essential plugins didn't seem to fix either

@KTS915

This comment has been minimized.

KTS915 commented Mar 10, 2017

@jaspuduf Honestly, I think the identity of the device is a red herring. My guess is that this is about operating system and/or browser. And what you think is "all over the place" might not be. Chrome, Safari, and Opera, for example, share a lot of code (though Opera Mobile is quite different from regular Opera).

@jaswrks

This comment has been minimized.

Member

jaswrks commented Mar 11, 2017

I just took a closer look at this, and while I have been unable to reproduce it myself, I did notice something that has changed on the Stripe side at some point, which may explain the screenshot that was posted earlier.

In the IFRAME that Stripe produces, Stripe is now setting z-index: 2147483647 on the IFRAME as an inline style. That's a very, very large number. That's fine though, and I can understand why they do that given the priority that site owners associate with checkout.

<iframe frameborder="0" allowtransparency="true" src="https://checkout.stripe.com/m/v3/index-178d6d6af7182f292611bb0bf6abb95e.html?distinct_id=105bb88f-a115-0276-86cf-2d779f5471fe" name="stripe_checkout_app" class="stripe_checkout_app"

... style="z-index: 2147483647; display: block; background: rgba(0, 0, 0, 0.00392157); border: 0px none transparent; overflow-x: hidden; overflow-y: auto; visibility: visible; margin: 0px; padding: 0px; -webkit-tap-highlight-color: transparent; position: fixed; left: 0px; top: 0px; width: 100%; height: 100%;"></iframe>

However, the s2Member source code contains the following line of CSS styling.

iframe.stripe_checkout_app {
    z-index: 999999 !important;
}

This line of CSS in s2Member, is/was designed to promote Stripe, just to avoid the sort of problem that is being reported in this issue. It was added before Stripe started using the inline style to set z-index. However, now it appears that it has the potential to cause a problem.

In short, the z-index adjustment that s2Member makes was designed to promote Stripe higher, not to demote it to a lower z-index inadvertently, which is what's happening now.

So my theory is...

Now that Stripe is setting z-index so high in their own code, they may have another modal overlay routine somewhere — one that is triggered on some devices, or in some scenarios. And, since their developers would assume that z-index: 2147483647 is set on the main IFRAME (i.e., not being overridden by s2Member) it's possible they have an overlay that is given a z-index that's higher than the value of 999999 that s2Member is forcing upon the main IFRAME.

That would result in the modal overlay sitting on top of the input fields, and would prevent any sort of input from occurring in any of the form fields. In other words, this could be s2Member's fault, we shall see.

Testing my theory...

Add the following to your theme's stylesheet and see if this corrects the problems being reported by mobile users. Make sure that you open Chrome's developer console and confirm that the rule is in fact being applied. If not, make sure the CSS is added after that of s2Member itself; e.g., move this CSS to the footer somewhere, just to be sure it's applied at the end and will override what s2Member sets by default in the current release.

iframe.stripe_checkout_app {
    z-index: 2147483647 !important;
}

Regardless, I am going to remove the z-index property from s2Member's CSS, as it is no longer necessary or desirable. However, I'd still like to know if this is the underlying cause of the problem being reported here, because at this point it's nothing but a theory; i.e., I cannot reproduce the issue myself.

@jaspuduf

This comment has been minimized.

jaspuduf commented Mar 11, 2017

Thanks so much for taking another look at this, it's extremely appreciated. I've added that to our themes CSS sheet but am having trouble locating it with the Chrome inspector. Is there somewhere in particular I should be seeing it?

https://pluginvegas.com/2-person-7-membership/?s2-ssl=yes

If not, do I just place into the footer as is or is there a special hook or something like that I need to add to it? I'm not the brightest when it comes to a lot of this stuff :)

@jaspuduf

This comment has been minimized.

jaspuduf commented Mar 11, 2017

I viewed the page source and saw this. Would this mean it is applied correctly or do I need to find it in the console as well?

}
</style>

  <style type="text/css" id="wp-custom-css">
  	iframe.stripe_checkout_app {
z-index: 2147483647 !important;

}

p#footer-info {display:none;}

@jaspuduf

This comment has been minimized.

jaspuduf commented Mar 11, 2017

I don't want to jinx it, but we've had about 30 sign ups since adding that to the CSS and zero reports of issues :) I'll update at the end of the sale to make sure that stays the case, but it's looking like you may have nailed it

Edit1: About 60, no errors reported. Looking like this fixed it. Thank you so much. I'll still update at the end of tomorrow to fully confirm

jaswrks pushed a commit to websharks/s2member-pro that referenced this issue Mar 12, 2017

jaswrks

@jaswrks jaswrks added this to the Next Release milestone Mar 12, 2017

@jaswrks jaswrks self-assigned this Mar 12, 2017

@jaswrks jaswrks added bug and removed cannot reproduce labels Mar 12, 2017

jaswrks pushed a commit that referenced this issue Mar 12, 2017

jaswrks
@jaswrks

This comment has been minimized.

Member

jaswrks commented Mar 12, 2017

Next Release Changelog

  • (s2Member Pro) Stripe Bug Fix: This releases corrects a seemingly rare conflict between s2Member and Stripe on certain mobile devices and in certain scenarios. In a case we examined, there was a problematic CSS z-index setting in the s2Member source code that was, at times, causing problems in the stacking order, which resulted in a user's inability to enter details into the Stripe popup form. In this release, s2Member's customization of the z-index stacking order has been removed entirely, as it is no longer necessary in the latest revision of the Stripe popup, which already handles z-index adequately. Props @jaspuduf and @KTS915 for reporting and for helping us diagnose the problem. See Issue #1057.
@raamdev

This comment has been minimized.

Contributor

raamdev commented Mar 14, 2017

@jaswrks Nice catch!

@jaspuduf @KTS915 Thanks for reporting this and helping us confirm a fix! Much appreciated. 😄

@gnuhest

This comment has been minimized.

gnuhest commented Mar 29, 2017

Following, as i had to disable payment on mobile devices, for a new streaming service.
Great job on the troubleshooting!

@hybridwebdev

This comment has been minimized.

hybridwebdev commented May 22, 2017

MEGA Huge thanks to @jaspuduf for this information. Myself and another professional dev were banging our heads against this issue all day. This is the one and only thread I could find and sure enough setting the z-index fixed the issue. Oddly, our issue was occurring only when the site was loaded through a link click in the facebook app. When opened externally, the normal behavior of the stripe opening in a popup occurred. However, when loaded through the app the modal loaded instead, causing this issue.

Again, mega thanks jaspuduf, people like you make the community great and save the rest of us from an early grave :)

@raamdev

This comment has been minimized.

Contributor

raamdev commented May 24, 2017

s2Member v170524 has been released and includes changes from this GitHub Issue. See the v170524 announcement for further details.


This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#1057).

@raamdev raamdev closed this May 24, 2017

@websharks websharks locked and limited conversation to collaborators May 24, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.