Open athomasmoz opened 5 years ago
Doesn't it get added to the YouTube queue by default and plays after the first video?
@athomasmoz ^
I will test that out. Would that be desirable behaviour though? If someone sees a video on their phone and wants to play it on their TV, does it make sense it's added to the end of a queue rather than just playing straight away? cc @aminalhazwani
For this specific scenario (where you close both Firefox and YouTube) when you cast video B, video B should play. So how @athomasmoz described it.
For what @AaronMT described, if you don't close both apps, and you try to cast a second video the YouTube mobile app prompts you with a modal that asks you if you want to play it immediately or add it to queue.
With Silk, this issue does not occur. It appears that silk restarts the app each time a cast is made, but with FFTV, it looks like the app is coming back from background. In both cases I 'closed' it by pressing the home button.
@psymoon did some investigation and found that on reconnecting the Youtube app to cast again, we're receiving messages for both the previous video, and the new video. This looks like a result of not handling the "disconnect Youtube app" event, but that's something that the OS seems to do, so we need to surface that issue.
@liuche When you disconnect using Silk, you get "Successfully disconnected" prompt
Follow-up here:
Additionally, when we get garbage back as a pairing code, we should prompt the user to try again.
Did some more testing, with cross-browser loading of the Youtube pairing URL:
Here are the Chromium versions with the browsers that I tested: Firefox TV Chromium WebView version: 59.0.3071.125 Silk Chromium version: 70.0.3538.64 Desktop Chrome Chromium version: 70.0.3538.102
The STR before was, every other "Cast" to Firefox would have problems reconnecting and just show the previous video. As an experiment, I put a breakpoint in on this "every other" pairing code that I expected to fail, and sent it to Desktop Chrome instead - the correct video was able to play.
I suspect this has to do with Chromium version - Firefox is using Chromium 59, while both Silk (for which reconnect/disconnect worked) and Desktop Chrome are on Chromium 70.
I'll wait to see if there is any more information from other people testing, but it seems to me that this is related to Chromium version, so I'll pass it onto @Sdaswani to see if there's anything we can do about bumping Firefox TV's Chromium version to be closer to the most recent version.
I wonder if this works better on GeckoView. :/ Anyhow: https://github.com/mozilla-mobile-skunkworks/amazon-roadmap/issues/10
What does an upgrade to Chromium involve? I assume it’s a pretty big task?
If it’s something that could blanket fix a number of media player issues and fix the YouTube Fling issue, it could be worth it.
Thanks, Ashley Thomas | athomas@mozilla.com | Product Manager, Firefox Mobile
On Nov 14, 2018, at 7:01 PM, liuche notifications@github.com wrote:
1234 https://github.com/mozilla-mobile/firefox-tv/issues/1234 also looks like it's a Chromium version problem.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozilla-mobile/firefox-tv/issues/1433#issuecomment-438899658, or mute the thread https://github.com/notifications/unsubscribe-auth/ApVpIDUV-5FJtoLovcrqsdoYQjXtdFTJks5uvNj6gaJpZM4YFdq8.
@athomasmoz we would much more likely upgrade to Geckoview, even if the upgrade to Chromium wasn't a huge task. We really have two options - GV or Amazon Webview.
Steps to reproduce
Expected behavior
See comment https://github.com/mozilla-mobile/firefox-tv/issues/1433#issuecomment-435365493
Actual behavior
Video A continues to play on the Apple TV through Firefox. Video B is added to the queue
Device information