User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0 The local WebM videos don't show controls even with the K-Lite Codec Pack installed. The video plays but it doesn't show the controls. Changing to Full Screen the controls show. Reproducible: Always Steps to Reproduce: 1. Install K-Lite Codec Pack: http://www.free-codecs.com/K_Lite_Mega_Codec_Pack_download.htm 2. Download the WebM file from: http://videos-cdn.mozilla.net/serv/firefox4beta/AudioAPI.webm 3. Drag the AudioAPI.webm into Firefox 4 Beta 4. The video starts playing but the controls don't show. 5. Change to Full Screen. Actual Results: The video starts playing but the controls don't show. Expected Results: The video's controls should show as they do in Full Screen.
Works for me without any plugin and codec Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110311 Firefox/4.0b13pre ID:20110311030408 Maybe this is K-Lite Codec Pack issue. And maybe related to Bug 610484.
Summary: Local WebM videos don't show controls → Local WebM videos don't show controls with K-Lite Codec Pack
K-Lite bundles Windows Media Player Classic, which installs a default MIME handler for *.webm (and *.ogg) files and Firefox honours that when loading local files. We can easily have Firefox not defer opening local video to the default handler by moving the entries for video from extraMimeEntries to defaultMimeEntries, in nsExternalHelperAppService.cpp (http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp#510). The question is, do we want to do that? I think yes, because video support is native in Firefox, and deferring the video handling to the OS registered default is surprising to the user. If they opened a video using Firefox, they'd expect it to load in Firefox since Firefox has in-built video support. If they wanted the video to load in the default handler, they would have loaded the video directly from the default handler (or from the shell/explorer). roc,doublec,kinetik: what do you guys think?
I think yes too.
(In reply to comment #1) > Works for me without any plugin and codec > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110311 > Firefox/4.0b13pre ID:20110311030408 > > > Maybe this is K-Lite Codec Pack issue. > And maybe related to Bug 610484. Ah, yes! It worked for me too without plugins and codec! But it should work fine with the codec and it doesn't: the controls don't show.
Created attachment 519084 [details] [diff] [review] Patch
Assignee: nobody → chris
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #519084 - Flags: review?(roc)
Attachment #519084 - Flags: review?(roc) → review+
I know it was like this originally, but why are the Ogg entries always included but the WEBM one's #ifdef'd?
Created attachment 519246 [details] [diff] [review] Patch v2 (In reply to comment #7) > I know it was like this originally, but why are the Ogg entries always included > but the WEBM one's #ifdef'd? Oh yeah. I've added #ifdefs guards for WebM in defaultMimeEntries. I realized we actually still want the entries in extraMimeEntries, without guards, so that when media support is disabled we can map the extension to a descriptive type-name to show in the "open file with helper application" dialog, so I re-added them. Carrying forward r=roc.
Whiteboard: [fx4-unco-bugday] → [fx4-unco-bugday][needs landing post ff4]
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [fx4-unco-bugday][needs landing post ff4] → [fx4-unco-bugday]
Target Milestone: --- → mozilla2.2
No longer able to reproduce this bug in the latest nightly -- VERIFIED FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.