Turbolinks: Turbolinks and stripe

Created on 14 Sep 2017 · 17Comments · Source: turbolinks/turbolinks

I am getting the following console error after turbolinks loads in chrome.

(index):1 Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://js.stripe.com') does not match the recipient window's origin ('http://localhost:3000').

It looks like turbolinks is trying to access something it can't access however the integration is working. I reproduced the error on https://jsfiddle.net/qvugw049/

Removing Turbolinks from the app solves the issue or moving to stripe js V2.The stripe help channel informed me that this is because js.stripe.com/v2 used html elements and js.stripe.com/v3 uses an Iframe.

Has anybody had this issue ?

Source

stefatkins

👍22 😕4

Most helpful comment

I've had this issue and even contacted Stripe about it, with no success. They basically told me not to worry about it, but I didn't like seeing the error message everywhere.

What I've done is only load the Stripe API on certain pages, and I added a certain meta tag on that page. The meta tag basically forces Turbolinks to do a full refresh on that page or when navigating away from that page. One downside is that this forces the page to be rendered twice, as it gets loaded once, then Turbolinks sees the meta tag, and then loads the page again (to do a full page refresh).

I have this in my _head.html partial:

<% if @stripe_refresh %>
  <meta name="stripe-refresh" content="<%= Time.zone.now.to_i %>" data-turbolinks-track="reload">
<% end %>

Then, on any page which uses stripe, I enable that meta tag:

<% @stripe_refresh = true %>

It might not be the most ideal solution, but this worked for me. Hope it helps.

mike1o1 on 19 Sep 2017

👍10 😄4 😕1

All 17 comments

I've had this issue and even contacted Stripe about it, with no success. They basically told me not to worry about it, but I didn't like seeing the error message everywhere.

I have this in my _head.html partial:

<% if @stripe_refresh %>
  <meta name="stripe-refresh" content="<%= Time.zone.now.to_i %>" data-turbolinks-track="reload">
<% end %>

Then, on any page which uses stripe, I enable that meta tag:

<% @stripe_refresh = true %>

It might not be the most ideal solution, but this worked for me. Hope it helps.

mike1o1 on 19 Sep 2017

👍10 😄4 😕1

@stefan694 We have this issue too. I saw your conversation in the Stripe help channel.. did Stripe engineering get back to you with anything?

bryanrite on 26 Sep 2017

@bryanrite Unfortunately they did not have a solution :(.

stefatkins on 28 Sep 2017

😕1

We have the same issue. The error doesn't seem to be affecting Stripe functionality in our page.

lordofthec4ctus on 13 Oct 2017

If there were an option in Turbolinks to a flag a dynamically create iframe element to be 'stored' between renders, flagging/keeping the stripe iframe, should solve this.

leifcr on 13 Oct 2017

I tried adding 'data-turbolinks-permanent' to do that @leifcr, but the Stripe JS seems to be removing/adding it again, no matter what I try.

On my Macbook, Safari and Chrome don't show JS errors if you don't have the developer console open - so IMO, its a better experience to have those errors firing in the background rather than reload the checkout page - as long as the average user is oblivious to them.

I think I remember Internet Explorer showing those errors though. I wonder if Edge still does this.

gregblass on 11 Apr 2018

What a shame though that Stripe won't prioritize this.

gregblass on 11 Apr 2018

I even tried silencing them by overriding the console.log function of the iframe, but you can't do that due to cross-site security stuff.

gregblass on 11 Apr 2018

I ended up disabling turbolinks on stripe payment pages.

leifcr on 13 Apr 2018

I can't decide what's worse - a full page reload, or a JS error. Stripe should take care of this.

gregblass on 13 Apr 2018

Here's the design patern I came up with to only reload the page on the visit AFTER the checkout page (saves reloading the checkout page):

app/controllers/concerns/turbolinks_reload_control.rb

module TurbolinksReloadControl
  extend ActiveSupport::Concern

  private
    def ensure_page_reload
      session[:reload_page] = true
    end
end

application.html.erb

<head>
  <%= turbolinks_reload_control_meta_tag %>
</head>

application_helper.rb

def turbolinks_reload_control_meta_tag
  if session[:reload_page] == true
    session[:reload_page] = false

    tag :meta, name: 'turbolinks-visit-control', content: 'reload'
  end
end

checkout_controller.rb

after_action :ensure_page_reload

checkout.html.erb (bottom of the page)

<script async src="https://js.stripe.com/v3/" onload="initializeStripe()"></script>

gregblass on 17 Apr 2018

👍1

Still a damn shame that stripe can't silence that error. Wasted a lot of time on this.

gregblass on 17 Apr 2018

😕4

Still a damn shame that stripe can't silence that error.

This is not ideal 😞 but handled as best as we can by https://github.com/turbolinks/turbolinks/pull/349

domchristie on 26 Sep 2018

Still no solution for this?

rept on 7 Sep 2019

👍1

I encountered this specific console error today debugging our emerging Turbolinks implementation and found this GH issue. Great job documenting, everybody! 💯

As I understand it, the issue is that when once Stripe has been loaded by adding https://js.stripe.com/v3/ to the page, that script adds an iframe to the page that when removed by the body-replacement of normal Turbolinks function will trigger the Failed to execute 'postMessage' on 'DOMWindow' several seconds later. As such, it's not the page that loads Stripe that is the problem, it's the page _after_ that needs to be reloaded. Right?

As such, the Turbolinks turbolinks-visit-control meta tag implemented in #349 only assists via the the session workaround in https://github.com/turbolinks/turbolinks/issues/321#issuecomment-382098878 .

From my understanding, it seems like the preferable avenue would be to allow the Stripe page to load via Turbolinks, but then shutdown Turbolinks for subsequent navigation -- whether that be a link-click or back/forward history manipulation.

To this end, I tried calling Turbolinks.controller.stop() after loading Stripe, and indeed this changed Turbolinks.controller.started to false and Turbolinks stopped doing history-navigation, but Turbolinks kept loading pages via subsequent link-slicks. (What am I missing here?)

Here's the solution that I came up with. Is there some way this could be improved?

function stopTurbolinks() {
  // This stops forward navigation from using Turbolinks.
  document.addEventListener('turbolinks:click', function(e) {
    e.preventDefault();
  });

  // This stops history navigation from using Turbolinks.
  Turbolinks.controller.stop();
  window.addEventListener('popstate', function () {
    window.location.reload();
  });
}

Thanks, all!

johnmaxwell on 27 Sep 2019

We were in contact with Stripe support around this issue. I asked them if their engineering can chime-in on this issue after their support said that

The issue does seem to be a problem with Turbolinks here. It must be trying to make a post request or access the iframe associated with Elements which is blocked for security reasons but it does not hinder your ability to use Elements.

Hopefully a more direct communication between the project and Stripe could be established here, rather than indirectly this way. Without knowing the details, I'm pretty sure there's a solution to this somewhere :)

gingerlime on 2 Oct 2019

Hey people, I also had this issue and after a lot of reading I failed to solve it nicely.

I solved it not nicely by adding the attribute data-turbolinks="false" to the anchor element ( <a> )linking to the checkout page. So basically turbolinks loads every page except that one, and the stripe card input works as normal.