one video all the time

March 27, 2011 9:03 AM

In-page youtube videos only will play the first one I watched. Refreshing or returning lets me play other videos, but after that, it still only lets me play the first one of that session. I'm using google chrome. (Previously)
posted by rebent to Bugs at 9:03 AM (35 comments total)

It does this for me as well with Chrome.
posted by cj_ at 10:01 AM on March 27, 2011

Just chiming in to say that I also have that problem in Google Chrome, but not in Firefox. I'm using Ubuntu 10.04 LTS.
posted by tickingclock at 10:01 AM on March 27, 2011

I've had this problem in Chrome too, actually.
posted by koeselitz at 10:20 AM on March 27, 2011

Yeah, this has been happening to me in Chrome as well - but only within the past couple weeks. Although I do find that refreshing the page and THEN clicking on the second link makes it work.
posted by EmpressCallipygos at 10:22 AM on March 27, 2011

Me too!
posted by torisaur at 10:39 AM on March 27, 2011

This also happens to me in Chrome! I first noticed it in the Duck Tales thread in December, and it really confused me when all the different versions sounded exactly the same.
posted by lilac girl at 10:55 AM on March 27, 2011

Does this happen consistently for anyone or is it every once in a while? And I wonder if it's a specific version of Chrome that has the problem? I can't duplicate it in Chrome 10.0.648.204 on a Mac. Would everyone who's reporting this for Chrome let me know the version/OS/frequency of the problem?
posted by pb (staff) at 11:00 AM on March 27, 2011

I've mentioned this a few times, having the same problem. 10.0.648.151 chrome on xp.
I might have it more frequently if I watched more inline video.
posted by Iteki at 11:03 AM on March 27, 2011

It has happened consistently in chrome on XP for me. Unfortunately, it hasn't happened for me in chrome anywhere else, so I can't test it for you until tomorrow; I can look at it then, however.
posted by koeselitz at 11:03 AM on March 27, 2011

It's a consistent problem for me in Chrome 10.0.648.204.
posted by tickingclock at 11:24 AM on March 27, 2011

I have link problems as well with chrome... I also notice it on facebook where clicking on a link takes me back to the last site I visited instead of to the facebook location I was headed to... I notice this with links other than video links....
posted by tomswift at 11:33 AM on March 27, 2011

This has been happening to me for a while now, consistently. Chrome 10.0.648.204 on Mac OS 10.6.6
posted by carmel at 11:34 AM on March 27, 2011

tickingclock, which OS are you on? And by consistent problem, do you mean every time you try to use the feature this happens?
posted by pb (staff) at 11:45 AM on March 27, 2011

oh yeah, this has been a problem for me for months. I figured it was just me but then chrome upgraded and I still had the same problem.
posted by rebent at 11:57 AM on March 27, 2011

Can't repro on 10.0.648.204 on Windows 7.

To be clear: if I'm on the homepage and clicking on in-page play buttons, what you guys are seeing is that every video is the same one?
posted by wildcrdj at 12:17 PM on March 27, 2011

Oh, and are any of you in the HTML5 beta? If not, try going to youtube.com/html5 and opting in, then see if that had any effect on this bug (remember to opt out afterwards unless you want HTML5, which on non-Linux platforms is probably still inferior to Flash).
posted by wildcrdj at 12:19 PM on March 27, 2011

sometimes happens to me in chrome as well, but not consistently.
posted by milestogo at 12:39 PM on March 27, 2011

To be clear: if I'm on the homepage and clicking on in-page play buttons, what you guys are seeing is that every video is the same one?

Yes, clicking any "inline play" button plays the same video--the first one you loaded.
posted by milestogo at 12:40 PM on March 27, 2011

tickingclock, which OS are you on? And by consistent problem, do you mean every time you try to use the feature this happens?

I'm on Ubuntu 10.04 LTS, and yes, the problem happens every time.
posted by tickingclock at 12:41 PM on March 27, 2011

Thanks, oh, missed that the first time around tickingclock. I'll get my test copies of Ubuntu and XP running and see if I can duplicate it.

Thanks for taking a look on your end wilcrdj.
posted by pb (staff) at 1:51 PM on March 27, 2011

Fwiw i run into it too sometimes on my iPad - iOS 4.3 - it seems to happen especially if i didn't funush watchung a video and try to launch another.
posted by motdiem2 at 1:58 PM on March 27, 2011

Just wanted to report that the inline videos are working fine for me with Chrome 12.0.712.0 on OS X 10.6.6.
posted by cobra_high_tigers at 2:01 PM on March 27, 2011

AND I'M RUNNING SOFTWARE UPDATE RIGHT NOW SO DON'T GET ANY IDEAS YOU BLACKHATS
posted by cobra_high_tigers at 2:07 PM on March 27, 2011

Hmm cant repro on Chrome/Ubuntu either, at least from the Google corp network. Normally this sounds like a caching/proxy issue, although not happening in Firefox makes it a little strange (although Firefox/Chrome might be using different proxy settings for some users).
posted by wildcrdj at 2:07 PM on March 27, 2011

Ah, this has been so irritating to me because this problem's only been showing up every now and then. Finally, I figured out why. On my system, at least, (10.0.648.204 on Vista), the bug only appears after you've returned to the page via the back button. So, to reproduce:

1. In-line view a YouTube video
2. Click on a link to take you to a new page (can even be just the non-inline youtube link)
3. Click the back button
4. In-line view a different YouTube video; it will show the same video from step one

This seems to happen from either the front page or a post page. I'll leave it to someone else to figure out why... something to do with form/JS/cache state?
posted by bunyip at 3:35 PM on March 27, 2011

Interesting. For me, the back button has nothing to do with it. It first appeared with I was viewing videos from a single post, one after another, and at first I was really confused with the phraseology of the post, since I assumed the author had linked the same video twice. So, no 'back-button' actitivty.

But it happens only erratically (Chrome, Win7 x32). I just tried to reproduce it and failed.
posted by milestogo at 4:09 PM on March 27, 2011

Oh hey, bunyip's method works to repro this. Clicked on a inline video on the homepage, followed a link offsite, hit back, and now every video is the one I watched before I went offsite.

Not clear whats going on yet but this repro'd immediately trying it that way.
posted by wildcrdj at 4:38 PM on March 27, 2011

Okay, couldn't resist taking a quick look at the code. I guess the jQuery load function on the lightbox isn't working as desired, and doing a quick google around for jQuery load chrome brings people running into issues with Google's same-domain security model, though typically only when looking at something on the local filesystem. Sure enough, though, I looked at the Chrome console when I triggered the bug, and the following message appeared:

Unsafe JavaScript attempt to access frame with URL http://www.metafilter.com/ from frame with URL http://www.youtube.com/embed/l8wHmpP33s0?rnd=1301269841686&autoplay=1. Domains, protocols and ports must match.

I guess that when the page is brought up from back-button (or perhaps other) access, the security domain associated with the lightbox's iframe becomes that of what was last loaded into it, rather than that in the original source. This is most likely a Chrome bug but it might arguably just be erring on the side of security caution. Thoughts for workarounds would include trying to set the iframe to an about:blank, or generating a new iframe via DOM/innerHTML as appropriate. Maybe a sandbox attribute on the iframe would allow a cross-domain load? (I honestly have no idea)
posted by bunyip at 5:06 PM on March 27, 2011

wow, great find bunyip. I can reproduce it consistently with those steps too. Investigating.
posted by pb (staff) at 5:56 PM on March 27, 2011

Good to hear! Though having more of a look I see that the iframe is actually delivered as part of the yt.cfm content, which makes things pretty weird. Is the error actually happening when the jQuery.html() method (called from .load) tries to clear the current lightbox content? Debugging with the jQuery min stuff isn't really doable! Reading through the code, though, I wonder whether doing an explicit jQuery('#lightbox').empty() before the load would do the trick in case chrome is reacting weirdly to jQuery's attempt to run .cleanData on it, and just terminating the script rather than throwing an exception which would clean things up.
posted by bunyip at 6:05 PM on March 27, 2011

Just coming back into this thread possibly too late, but I offer what i've noticed just for the record:

1. Chrome, on Windows 7.

2. Symptoms: I am in a thread and I click on the Youtube viewer for video A. I watch video A, it ends, I click on "close window" to return to the thread. I see a link to video B in the thread, I click on the link for video B - but it pulls up video A.

3. I have found that refreshing the page and clicking on the link for video B again will make it work. I can often even go on to load video C, video D, and other links in that same thread. But if I then go to another thread, I have the same problem (video A loads fine, but the link for video B goes to video A again).

4. I've also tried clearing my Chrome cache and that clears things up a bit longer (for the rest of that day).

5. This is not a CONSTANT problem for me, but it is frequent. It has been happening for me for about two weeks or so now.
posted by EmpressCallipygos at 7:33 PM on March 27, 2011

Thanks for the ideas bunyip, no luck yet. Tried empty(), and a dozen other things. Very frustrating bug. It looks like everything is firing properly, but the youtube iframe is bringing up the wrong video. I'm not ruling out something on our end, though. I see the "Unsafe JavaScript..." error too, and that's definitely on YouTube's end though I don't think it's causing the problem here.

I'm going to sleep on it and take another look after some coffee tomorrow. Thanks again for all of the reports on this.
posted by pb (staff) at 10:01 PM on March 27, 2011

Yeah, there's something pretty weird going on there. I had the chance to have a quick play with it via the console and the fix seems to be to change the id on the iframe (i.e., ytframe). I'm not sure whether you (or user scripts) have other bits of code/css using that id or not, but adding a random suffix to the frame id would be a pretty quick fix.

On a fresh reload, it seems like you can use the same iframe id over and over again without problems, but the moment you get Chrome into the state that you get in after the back-button move it requires a new id for each iframe. That is, you can successfully load a new iframe with id ytframe2, but then if you want to show yet another video you'll have to switch to ytframe3, as ytframe2 will show that same video you loaded into that frame before. So it's not just a case of some weird state being preserved from the original pre-back-button page, but more that it's just getting in some mood where it's unwilling to load new content for a frame with a previously existing ID. That certainly looks like a Chrome bug to me! Note that this also happens regardless of whether you're using youtube as the iframe src; the same behaviour happens if you use, say, a metafilter.com iframe src.

I'm happy to share any particulars of my testing, if you'd like!
posted by bunyip at 11:24 PM on March 27, 2011

I owe you one, bunyip. I'm now giving the iframe a unique ID for each load and that has cleared up the problem for me in Chrome. I know nothing about browser internals, but I'm wondering if the frame is being saved to Chrome's "Back-Forward Cache" even though it's cleared when the modal is closed—and then can't be overwritten if that cached version is used to render the page. But I have no idea. Thanks for your help, let's see if this improves things.
posted by pb (staff) at 7:43 AM on March 28, 2011

You're welcome. I look forward to clicking on the in-line links without fear in my heart!

And yeah, I have no idea about the browser internals either, but that was my initial thought, too. But then I discovered that it had the same problem with an iframe with a new ID on the page too, which makes me think the problem's a little stickier. Should probably submit a bug report but, eh, I'm sure it'll sort itself out by itself, somehow!
posted by bunyip at 11:17 AM on March 28, 2011