Matt Schwarz

Matt Schwarz Staff

Hey guys,

Upon further investigation we think this may be an issue related to varnish. We're going to investigate further and update you here.

Thanks again for your patience!

***UPDATE*** We've released a fix which should resolve the issue. Please allow 24hrs for it to take full effect.

useronvimeo

useronvimeo

The issue seems to be related to vimeo.com/forums/api/topic:67059 where apparently because of the security alert, the event finished never gets to be fired. Also, the issue seems similar to this one:

vimeo.com/forums/api/topic:72896 where apparently the app grabs a domain that was used in development and the iframe tries to communicate with that domain, even though such domain doesn't appear anywhere in the markup and even though the page the domain's being loaded from is totally different.

Even though the two topics before might be related, they don't fully cover the situation, are old and didn't get any answer to solve the issue, therefore we are opening a new one. I have limited space here for some reason, so please read the whole thing at vimeo.com/forums/help/topic:73823

This issue affects old iBooks even if they're running with the latest version of chrome and most windows computer on both chrome and firefox.

Link: trigion.bitremix.com/apply/3#application/73/questions/test

useronvimeo

useronvimeo

Posting exactly from vimeo.com/forums/help/topic:73823 to make reading easier:

Hey there.
I have problems listening to events using Froogaloop.
The linked fiddle works like a charm using Chrome, Firefox and Safari in Mac OS.
Nevertheless it doesn't trigger any events around 70% of the time in Chrome and Firefox in Windows XP. I also get: "Unable to post message to player.vimeo.com. Recipient has origin fiddle.jshell.net";
Link: jsfiddle.net/sMX6f/27/

We already made sure to have api=1 and make the iframe ID passed in the url to the params. The problem is windows as far as we know. We also have made sure to listen to bind to event after the iframe loads. The fiddle is pretty self explanatory, and we could replicate the issue there, but should you want to dig into our minified staging code feel free to explore trigion.bitremix.com/apply/3
Link: trigion.bitremix.com/apply/3

useronvimeo

useronvimeo

Just to be clear, the problem is that my app requires to know when the player ends in order to continue to the next step. Since there's an error that apparently blocks the trigger of the event, my whole app just dies and the next step never gets triggered.
So this really might look harmless with people only playing video, but when we are building much more complex apps this really cannot happen. We have no idea why it happens only some times and in some OS,(code works at all times on Chrome in OSX but fail 70%+ in Chrome in Windows XP/7) but we really think it's something on your side and we are needing assistance ASAP.

Matt Schwarz

Matt Schwarz Staff

Hi there,

Sorry you've been having trouble. Our developers took a look and it seems that this issue may lie with your app. If you go to player.vimeo.com/playground to test, you should see that everything is working properly, which again may point to a code issue on your end.

If you find something isn't functioning properly, please let us know.

useronvimeo

useronvimeo

The playground doesn't work either, using Chrome 21 in Windows XP S3 it fails roughly 50% of the time, showing in the JS console:

Unable to post message to fiddle.jshell.net. Recipient has origin player.vimeo.com.
player.core.opt.js:65

Just for the sake of showing you that the error is actually on your side, I checked the non opt version of the script (player.core.js), and if you change the line 1642 from:

p = decodeURIComponent(a.request.referrer),

to

p=decodeURIComponent("url.to.your.app")

It doesn't fail one time. Of course that isn't a fix but should give you a heads up on the problem.

useronvimeo

useronvimeo

BTW, checking the Last-Modified HTTP headers from the last four minor versions of the player.core I realised the apparently magical fixes on the behaviour of our app correspond with the change of minor versions.

useronvimeo

useronvimeo

And, I forgot to mention that not using froogaloop solves the problem about half of the time. Because, obviously now the origin problem only happens on the player side.

useronvimeo

useronvimeo

Matt, the error is not in there. If you check the code that is loaded in the iframe you'll see that there's a param in flashvars called "embed_location" that gets the wrong information.

You can check an example of that in the line 20 of the gist I share.

Link: gist.github.com/3791413

David Pelaez

David Pelaez

I'm part of the CVIVE team and I'm using my personal account to conitnue the conversation.This is for sure not an issue in our code. The problem was there and then next day it was gone. We haven't changed the code and the problem's now back! This is a production app and we provided a fiddle that proved the failure on window. What can we do? Can we make a call or something? This is getting out of hand because we had a client not using our app last week and this is now back. Please help us find a solution. We took one of your scripts and replaced it through a proxy and made a change and we stop having the issue 100% of the time. Maybe this has to do with cookies and your CDN serving that domain. We really don't know what it is. But somehow your object finds out the name of other domains used to serve the very same page. This isn't in our code for sure, so there must be something on your side.

You've taken a lot to reply to something very serious. I'm really counting on you here.

Wesley Moore

Wesley Moore

I am seeing this problem too. The response sent back from the Vimeo server appears to be cached by Varnish and contains a possibly incorrect referrer domain in the embedded JSON.

For example this is from response to iframe that embeds a video:

document.getElementById('player_17583382_1551153294'),clip17583382_1551153294 = {config:{"request":{"cached_timestamp":1348521624,"source":"cache","timestamp":1348537939,"signature":"f8f25be869f013de87f52562061c1e98","varnish":1,"cookie":{"hd":null,"scaling":1,"volume":100,"html":null}
,"expiration":21600,"referrer":"http%3A%2F%2Fbellroy-staging.myshopify.com%2Fproducts%2Fslim-sleeve-wallet"...

Note that varnish:1 and the referrer, which is referenced by the line David mentioned above in this case is bellroy-staging... this is not the right domain for which this response taken.

Public Class

Public Class

We're also experiencing problems with the respons:
From error log:
"Unable to post message to 12:3000" target="_blank" rel="nofollow">192.168.0.112:3000. Recipient has origin localhost:3000";
Must be some kind of cache since the local IP isn't currently in use and the request was sent from localhost.
We get this error in Safari 5.0.5 - 6.0 and on Mobile Safari 6.
And as a result, ready event never fires which makes froogaloop unusable.
For us this is really a critical bug.

useronvimeo

useronvimeo

We continue to experience the very same issue. We reported this more than one week ago. It's clear that the problem is in your side, as even the examples in your playground fail under exactly the same bug.

We also have the theory that there's some sort of caching on Vimeo's side for the very same reasons Public Class exposed. Maybe you're caching the uri of the pages embedding the video and trying to use them after that.

Just acknowledge there's an issue and work with the affected people in solving it. Its simply about basic respect for your clients. Plus, this is happening with paid clients that you should take good care off. We are really disappointed about this and we really cannot go and replace the code on your server by our selves, so please help us out because we are crumbling to make our applications work.

Matt Schwarz

Matt Schwarz Staff

Hi there,

Again sorry for the trouble you've been having with the API. Please see my response above for further detail.

CopacinoFujikado

CopacinoFujikado PRO

We had the same issue. The page on which we're calling the Vimeo API worked fine in a local development environment, but when the page has been pushed to a staging server at a different URL, the following error occurs (Chrome OS X version 20.0.1132.57):

Unable to post message to localhost:12573. Recipient has origin staging.copacino.com.

localhost:12573 is the temporary URL that was used for development, and it's not connected to anything any more. The localhost URL occurs nowhere in any of the code running on staging.copacino.com. I've cleared out both browser and Flash caches, to no avail.

While writing this, I re-uploaded the site to staging.copacino.com, and now everything magically works. I say "magically", because I didn't change any of the code. I hope this is because the folks at Vimeo found and fixed the issue while I was writing, but I'm nervous given CVIVE's earlier experience that I'm simply getting lucky and this might break again out of the blue.

Link: staging.copacino.com/peace-of-mind

CopacinoFujikado

CopacinoFujikado PRO

And, in fact, it's not been fixed. Trying from a different machine and browser (Windows Chrome version 21.0.1180.75) yields precisely the same error as before, right down to the localhost:12573 domain. This is almost certainly a caching issue on the Vimeo end; that particular domain occurs absolutely nowhere in the markup and code that make up the page.

This page needs to go live soon (which means to yet another domain), so I'd love to see a solution. Thanks!

Kristaps Horns

Kristaps Horns

@Matt Schwarz Does Vimeo Varnish implementation supports "no-cache" option in the request header?

If it indeed is catching issue there is a possibility that Heroku in general will cause this issue, since it falls under the same IP range when switching between staging, production environments.

useronvimeo

useronvimeo

We've found a workaround: use the deprecated code to embed the flash object directly and interact with it prepending "api_" for the methods needed. It's far from ideal but at least it works for us.

Of course this doesn't work for listening events.

Matt Schwarz

Matt Schwarz Staff

Hey guys,

Upon further investigation we think this may be an issue related to varnish. We're going to investigate further and update you here.

Thanks again for your patience!

***UPDATE*** We've released a fix which should resolve the issue. Please allow 24hrs for it to take full effect.

This conversation is missing your voice. Please join Vimeo or log in.