STR (1) Load youtube.com in browser (2) Tap a video to play it We switch to the video app, but then - the video app scans for video files - displays the results of the scan and only then gets around to playing the youtube video. This is a really bad UX. We should load the requested video immediately, and if required scan videos in the background.

One of the testers reported this issue: when we try to play a video clip in youtube with usb cable attached to PC, it shows a message "videos cannot be played with usb cable plugged in" and then the youtube playback starts. Is it also because of this bug or should it be a separate issue?

Yes, that sounds like another symptom of this bug.

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Dale: I'm gonna take this. If you already have worked on this, feel free to steal it from me.

Yo anthony, I have already done this patch, just been doing some testing on other stuff thats been blocking me from uploading (it also includes fixes for the other bug) Sorry about that

This is taking me longer than I expected... I really want to convert the view activity to inline so that users can return to the browser when they click the back button. If I try implementing the activity with a completely different target file in the gallery app (apps/gallery/youtube.html) then an inline activity works. But audio playback is terrible for some reason. Really jerky. But when I try to convert the Video app itself to use an inline activity with entry point index.html#view then the back button doesn't do anything. I call postResult() on the activity but it doesn't go away. I've got to figure out one or the other of these problems!

The gallery can't use the hardware decoders currently. Please go with option 2 if possible.

Chris, Thanks; that explains the poor playback when I try to add the activity to the Gallery app. So I'll do it as part of the Video app instead. If I start off with a completely separate file in the video app to handle the activity, it appears that I can dismiss the activity correctly, so that's a good start. Note that both the Gallery and Camera apps play videos (from the camera). Should they be given access to the hardware decoders in order to make that more efficient?

In my testing, playback of the 3gp files we record in the gallery was good enough not to warrant the extra permission.

I've made progress on this. The problem with the activity not closing when we call postResult() is that I needed to set returnValue:true in the manifest, and then I needed to do a make reset-gaia to get that manifest change to take effect. I now have a working video player that can be dismissed to return to the browser. I just need to do some code cleanup and figure out one landscape mode visual glitch and I can post a patch.

My work in progress is at https://github.com/mozilla-b2g/gaia/pull/7220 in case anyone wants to take a look. Dale: I basically started with index.html and video.js and copied them to view.html and view.js, then trimmed out all the mediadb and thumbnail stuff until I was left with just the bare UI required to play a video. Each inline activity is launched basically as if it was a separate app, so I'm treating the view activity as a separate, simplified version of the video app. It does mean some code duplication, but it makes things a lot simpler.

This github pull request fixes this bug and also bug 815826 by breaking the video view activity into a separate HTML and JS file. More details on github.

David I assumed the 'dont land yet' was due to the follow up you were doing with the youtube errors, I couldnt find any further work needing done during testing so I landed. If there was any more work to be done then you can reopen this and apologies. Agreed that although I would much prefer to refactor the duplicated code out, possibly to use videoplayer in both video.js and view.js, now isnt the time to be doing such.

Dale, The don't land yet warning was because I created the pull request for comment 12 before I was actually ready to attach it to this bug and get it reviewed. You're right that it is now ready to land. Thanks!

Unable to open YouTube in browser to verify "Unagi" device, build ID:20130103070201