Doesn’t do that on mine. It simply shows the onebox with “live” but no video playing:
No screen takeover.
Firefox on Windows 8.1 autoplays it. Maybe @ArmandoPenblade is on about desktop Chrome? edit: Nope, he specified Android Chrome.
Yeah, no, every time I opened any of the Stardock threads on here w/ current dev work going on, where Island Dog or others would post a link to their twitch each week for the dev streams, I’d get the thread starting to load, then the phone would flip itself to landscape, show a black screen w/ loading circle (what I take to be a, “I’m about to play you some video, mate” screen), then flip back into portrait and finish loading the thread.
All took place over the course of a handful of seconds at most, but it was super jarring. I just stopped opening them on my phone after awhile.
So the issue with youtube videos going fullscreen in Chrome is probably related to this one, and I sort of fixed it in my script (though I didn’t deploy it to the github so it didn’t auto-update). I meant to make a thread, but I think I can mention it here since it’s so similar.
Basically when you full screen the video, it tries to build that iframe at the top of the page I guess, which causes the site to think you scrolled up there and then it fires off the code to load a new page of content for the one above you. I fixed it by detecting the click on the fullscreen button in the youtube iframe and disabling the scroll event for a couple seconds. This seems to have fixed that issue for youtube fullscreen videos for me.
I mentioning it here so maybe @wumpus sees it. It’s a bit of a workaround rather than an actual fix but it worked. I don’t know enough Ember to make it happen in Discourse and submit a PR but there you go. Maybe something to be investigated.
Thanks for that, I will have @eviltrout take a look and see if that can make a workaround. We get a lot of complaints about this and as I like to practice Complaint Driven Development, I think we should address it.
The other thing I noticed is you guys are putting the youtube src link in as autoplay=true.
This is an issue for Chrome as well. When you click the video img it puts in the youtube video but for some reason the autoplay does nothing and you have to click the play button again anyways. Then, if you pause it, but scroll up far enough to trigger another page load, the autoplay seems to suddenly work and the video starts playing (not resuming, but restarting). I solved this little issue in my script by rewriting all the youtube tags src to have autoplay=false. Then when you scroll it doesn’t wreck the opened videos and make them all start playing. Sometimes the site scroll will still close the video again and put it back at the beginning, but it won’t start automatically playing after that happens.
How did you do this? Can you share the code?
So as suspected, it’s not really a Chrome issue. Or if it is, it is one so easily worked around that every other site does it as a matter of course. I mean, I was happy to take that at face value, until I realised I have been using Chrome and browsing embedded youtube clips all over the net for years now, without the particular behaviour Discourse seems to exhibit.
No problem. First, and most importantly, always use someone else’s thing: https://github.com/vincepare/iframeTracker-jquery
I’ll post the rest of my code if you want it, but after detecting the click it’s going to be a lot different between what I did:
- set a jquery scroll handler that just eats the event and doesn’t let it bubble to other handlers
- set a window.timeout timer for 2 seconds in javascript to run a function to remove that scroll handler
…and what you should do, which is all in Ember.
I imagine you are most interested in the link at the top here, but if you want I’ll post the code too. :)
I went ahead and committed these changes to my user script, here’s the link for you to see that code if you want (there’s a lot of other stuff in there since it has the theming bits and the ignoring users bits too): https://github.com/matthewboonstra/qt3UserScript/blob/master/QuarterToThreeDiscourseForumHelper.user.js
Also, I generally apologize for all of that code. I haven’t had enough time to make it anything other than cobbled together and gross.
Awesome, thanks for that. I can confirm that the technique works, so I ported it to our lazy youtube plugin here:
Great!
You might want to test with playlist videos. I found that if you post a youtube link to a playlist instead of just a video my thing fails, but I think it’s just because of how I targeted the iframetracker, and I’m guessing your code won’t have this issue since you’re targeting the element differently.
Awesome, this bug drove me up the wall.
OK I deployed that version here with the YouTube chrome hack, so have a go with it.
Also as the first post shows we’ve caught up on almost all the feedback except OMG THE WHITE BACKGROUND SCORCHES MY PRECIOUS RETINAS
Patreon forum perks / recognition should be up next.
Still true! But thank you for working on a lot of others things for us just the same.
This is mitigated on desktop with browser plugins, if you’re inclined to go to the trouble. However still the number one reason I avoid the site on mobile, ie reading in bed. Even w mobile night mode, it’s jarringly bright.
Well, I’m still struggling to get used to the endless scrolling… It just doesn’t work for me. But obviously I’m just an old fart who hates the trend towards mobile optimised web design and the future.
The bit that really makes endless scrolling work for me is this:
The ability to travel in time through a thread without having to guess how far back forward you are navigating, both on desktop and mobile, is so much better than the old pages system.
That and the much better quoting system.
Wendelius
It’s good, but it could be improved… :)
i.e. it’s non-linear. So 0-90% of that bar could represent Jul2-Jul3 2013, and 91%-100% could be October 2016. It’d be nice if those “8 year later” bars you see in threads were visible somehow on this blue bar. And, even if those bars aren’t visible in a thread, at least some kind of date indicator around the 25/50/75% markers? (or 33% or 66%?)
The use case for this is the other day I opened one of those necro threads, and Discourse put me at the start (not entirely it’s fault due to the import), but I didn’t actually know how far to jump down through the thread to get to the latest goods. (Which also implies the grey and blue numbers you see on threads could also be demarked on this line, somehow?)
Yes, these sorts of ideas are definitely on our radar for the timeline.
I like those ideas. They would make it even more efficient to navigate the timeline.
Wendelius