Closed
Bug 786119
Opened 12 years ago
Closed 11 years ago
YouTube website opens videos in YouTube app, not HTML5 video in browser
Categories
(Web Compatibility :: Site Reports, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: cpeterson, Unassigned)
References
()
Details
STR: 1. Load http://www.youtube.com/html5 2. Opt-in to HTML5 Trial 3. Play some YouTube videos AR: YouTube opens the videos in the YouTube app. ER: When we support WebM and H264 video, YouTube should serve us HTML5 video in the browser instead of opening the YouTube app. * B2G bug 780821 is basically the same issue as this bug, but B2G does not have the fallback options of YouTube app or Flash video.
Reporter | ||
Comment 1•12 years ago
|
||
If I change Firefox's User-Agent string to copy the Android stock browser, then YouTube serves us HTML5 video as expected.
Comment 2•12 years ago
|
||
This is expected behaviour. We requested that YouTube serve Firefox this content to support the launch of Firefox for Android. We will need to make a clear request to YouTube on the requested content type for Firefox. Specifically, do we want to request H.264 content on Android and play content in browser or do we want to continue to kick out to the standalone player on that platform?
Blocks: youtube.com
Comment 3•12 years ago
|
||
(In reply to Lawrence Mandel [:lmandel] from comment #2) > This is expected behaviour. We requested that YouTube serve Firefox this > content to support the launch of Firefox for Android. We will need to make a > clear request to YouTube on the requested content type for Firefox. > Specifically, do we want to request H.264 content on Android and play > content in browser or do we want to continue to kick out to the standalone > player on that platform? Given Brendan's comments on the FF OS equivalent bug to go back on including "Android" in the UA for FF OS, the approach that has to be considered here has to satisfy both platforms, so kicking out to the standalone player simply isn't going to work. We need YouTube to serve us H.264 content to our browser instead to satisfy the needs of both FF OS and FF Android.
Comment 4•12 years ago
|
||
cc Karen and Mark to comment on the Android product requirements. In general, we shouldn't compromise the Firefox for Android (H1) experience for our B2G (H2) product. We do need a solution that works for both platforms. I'll let Karen and Mark comment on what is the desired experience on Android. We can then work on a strategy to satisfy the requirements.
Updated•12 years ago
|
Comment 5•12 years ago
|
||
Does anyone know what happens if the youtube app isn't installed? Does it play in the browser instead, or does it prompt the user to download the app? (I'm just trying to think through of the various workflows / scenarios)
Comment 6•12 years ago
|
||
(In reply to Karen Rudnitski from comment #5) > Does anyone know what happens if the youtube app isn't installed? Does it > play in the browser instead, or does it prompt the user to download the app? > (I'm just trying to think through of the various workflows / scenarios) I think bug 777633 happens in that case.
Comment 7•12 years ago
|
||
On most devices you can't uninstall the YouTube app. On devices running a custom ROM it might be possible to remove or not install the YouTube app. The other case would be unoffical Android devices.
Comment 8•12 years ago
|
||
Thinking this through, both UX (Ian) and I agree that it would be best that a user remains in the browser and doesn't get kicked out to the stand-alone app. Let's keep it within the browser experience - we support it so we should use it, plus it's one less step seen by the user.
Comment 9•12 years ago
|
||
(In reply to Karen Rudnitski from comment #8) > Thinking this through, both UX (Ian) and I agree that it would be best that > a user remains in the browser and doesn't get kicked out to the stand-alone > app. Let's keep it within the browser experience - we support it so we > should use it, plus it's one less step seen by the user. We thought the opposite when we initially requested that Youtube send us content that would spawn out to the standalone player. At the time, the standalone player was the best UX, from the user's point of view. Youtube content in Firefox was a less than stellar experience. I assume that if we request H.264 content, which would keep us in the browser, that the UX of Youtube in Firefox is now considered the best experience?
Comment 10•12 years ago
|
||
(In reply to Karen Rudnitski from comment #8) > Thinking this through, both UX (Ian) and I agree that it would be best that > a user remains in the browser and doesn't get kicked out to the stand-alone > app. Let's keep it within the browser experience - we support it so we > should use it, plus it's one less step seen by the user. Two thoughts on this: 1. I don't think that H.264 playback is smooth on all devices at this point. Can we hold off on making this change until we're confident in our playback solution? 2. We don't yet have an H.264 decoder story for Android releases less than ICS. Gingerbread is in progress and I'm not aware of plans for Froyo. How will we support Firefox users on older Android releases?
Comment 11•12 years ago
|
||
(In reply to Mark Finkle (:mfinkle) from comment #9) > (In reply to Karen Rudnitski from comment #8) > > Thinking this through, both UX (Ian) and I agree that it would be best that > > a user remains in the browser and doesn't get kicked out to the stand-alone > > app. Let's keep it within the browser experience - we support it so we > > should use it, plus it's one less step seen by the user. > > We thought the opposite when we initially requested that Youtube send us > content that would spawn out to the standalone player. At the time, the > standalone player was the best UX, from the user's point of view. Youtube > content in Firefox was a less than stellar experience. Hm, perhaps I am remembering a conversation incorrectly. I thought that it was flash video that made for a poor experience, but that the h.264 player worked better in the browser. Is that not the case?
Comment 12•12 years ago
|
||
(In reply to Ian Barlow (:ibarlow) from comment #11) > (In reply to Mark Finkle (:mfinkle) from comment #9) > > (In reply to Karen Rudnitski from comment #8) > > > Thinking this through, both UX (Ian) and I agree that it would be best that > > > a user remains in the browser and doesn't get kicked out to the stand-alone > > > app. Let's keep it within the browser experience - we support it so we > > > should use it, plus it's one less step seen by the user. > > > > We thought the opposite when we initially requested that Youtube send us > > content that would spawn out to the standalone player. At the time, the > > standalone player was the best UX, from the user's point of view. Youtube > > content in Firefox was a less than stellar experience. > > Hm, perhaps I am remembering a conversation incorrectly. I thought that it > was flash video that made for a poor experience, but that the h.264 player > worked better in the browser. Is that not the case? At the time, we did not have any H.264 functionality, so I'm not sure we saw the in-browser player using anything but Flash. Also, Youtube was sending Firefox desktop content.
Comment 13•12 years ago
|
||
> At the time, we did not have any H.264 functionality, so I'm not sure we saw > the in-browser player using anything but Flash. Also, Youtube was sending > Firefox desktop content. Alright, I must be remembering things wrong. I think in that case, I would agree with Lawrence in comment 10, that we should hold off on changing the UX to keep people in Firefox for YouTube videos, until we are confident that the experience is better and smoother across all our supported devices.
Comment 14•12 years ago
|
||
Please do not force in-product playback. I bought a Google Android device and I expect it to make use of the supplied Google applications that provide superior functionality outside of the browser to my phone. The native Google Maps application experience is vastly superior to the current experience in-browser; why should we settle for less?
Comment 15•12 years ago
|
||
To follow the android design, firefox should sent an intent when trying to access the youtube page. This way, the user should see an application picker with all the applications that handle these url (all the browsers and the youtube native app). This way, the user would have the choice between staying in firefox or going to the native app. Actually, firefox should do that for every url as the native browser and chrome doest.
Updated•12 years ago
|
Component: Evangelism → Mobile
Product: Firefox for Android → Tech Evangelism
Version: Firefox 17 → unspecified
Comment 17•11 years ago
|
||
I spoke with Karen, Brad, and Mark about how Firefox for Android should interact with YouTube last week. The conclusion was that on Android we want Firefox to pass YouTube playback to the YouTube app. AFAIK, this bug should be resolved won't fix at this point.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Comment 18•11 years ago
|
||
(In reply to Lawrence Mandel [:lmandel] from comment #17) > I spoke with Karen, Brad, and Mark about how Firefox for Android should > interact with YouTube last week. The conclusion was that on Android we want > Firefox to pass YouTube playback to the YouTube app. AFAIK, this bug should > be resolved won't fix at this point. There's the case for CyanogenMod users who lack Google Apps (Play Store) w/YouTube (as an official native Google application); the intents fired aren't handled and the user is SOL watching YouTube.
Comment 19•11 years ago
|
||
I don't think there's a perfect solution here. If we play YouTube videos in the browser, ARMv6 devices will be SOL. I had previously suggested that we play videos in the browser and, if we detect that h.264 is not supported on the platform, we fall back to sending the user to the YouTube app. This solution is also hacky and wouldn't be perfect. At the very least we should try to devise and document some sort of workaround for these cases.
Assignee | ||
Updated•5 years ago
|
Product: Tech Evangelism → Web Compatibility
Assignee | ||
Updated•1 month ago
|
Component: Mobile → Site Reports
You need to log in
before you can comment on or make changes to this bug.
Description
•