User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 Build ID: 20130408165307 Steps to reproduce: I have a radio website (for example, this one: http://folkradio.ru/nagrani/). I click on mp3 link (mp3 in paretheses). The output has mime type set to audio/mpeg. I have "Save file" action set to mp3 files in (settings->Applications). Actual results: I saw windows media foundation player opened and started mp3 playback. Expected results: Save file request should open.
about:config > media.windows-media-foundation.enabled = false
I don't want to disable entire WMF features. I do want to be able to playback mp3 files when I want to. Currently, I can't see any way to simply DOWNLOAD mp3 file.
http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Responses Content-Disposition: attachment; filename="file.mp3" You need to configure your server to force the download.
Why mime type isn't enough? It was working well until WMF was included in Firefox.
I want the ability for it to ask to save or open back, as my website has a link for each. One to download and a m3u to play.
(In reply to Yuriy Chernyshov from comment #4) > Why mime type isn't enough? It was working well until WMF was included in > Firefox. Use the attribute download: http://davidwalsh.name/download-attribute In addition, set "Content-Disposition" in your header response.
(In reply to Loic from comment #3) > http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Responses > Content-Disposition: attachment; filename="file.mp3" > > You need to configure your server to force the download. I don't operate those web sites and asking end users such as myself to contact the thousands of affected web site operators is patently absurd. Firefox 21.0 Update implemented a behavior change for the worse; please verify / confirm that issue as reported and triage it appropriately.
The fundamental problem is "Application > Options" settings are disregarded; Windows Media Foundation is ALWAYS invoked.
It's invoked because now, Firefox is able to read this MIME type.
(In reply to Loic from comment #11) > It's invoked because now, Firefox is able to read this MIME type. We agree this describes what happens now; but it ignores this creates a poor user experience since previously user controllable behaviors have stopped working.
I must add that ogg and other native-supported format are also affected. They (e. g., ogg vorbis) just weren't as popular as mp3 and didn't caused any problems. I think this can be solved by: disabling auto playback and adding a download button to a player page.
Because websites are bad coded. When you click on a picture link (jpeg or png), you expect your browser to display the picture not to download it. That's what Firefox makes with known MIME types.
Audio is a little bit different thing. At least, it WAS a little bit different. I don't like the lack of control provided by built-in player (no hotkeys, for example). When browser opens an image, you can right-click on it and save it. You can't do this with current audio player.
1. This has nothing to do with website configuration. It's purely an issue of user preferences not being respected. 2. This is not comparable with image files. JPEG, GIF and PNG don't even have entries under Options/Preferences -> Applications. 3. The apt comparison is PDF. Firefox also used to hijack the association for PDFs, but that was fixed in bug 752676. That's what needs to happen here.
tracking-firefox23: --- → ?
tracking-firefox24: --- → ?
Summary: Disabling auto mp3-playback → Applications setting is ignored for MP3 files
This has nothing to do with website configuration. It's purely an issue of user preferences not being respected. +1 This is not comparable with image files. JPEG, GIF and PNG +1 definitively, this is a regression For now, I turn Off media.windows-media-foundation.enabled but I hope that I can chose what to do with some type of link Alain
This is going to require a regression window to be considered for tracking. Even then, we may decide this is expected behavior (albeit new).
I assume this behaviour changed when bug 837859 landed; 2013-02-05 07:37:40 PST.
media.windows-media-foundation.enabled: true ( this problem ! ) need to be: false ( default ) For everyone on web ! Everyone people on web ! all browsers firefox 21. Is this solution. But Google Chrome 100% works, with this html 5 TAG: <audio id="audio-player" src="http://188.8.131.52:8004/;" type="audio/mp3" controls></audio> The only question here is: Why worked in firefox 17 but not working in firefox 21? Simple html 5 Tag, example: <audio id="audio-player" src="http://184.108.40.206:8004/;" type="audio/mp3" controls></audio> Firefox regressed html 5 technology. Is this ? Why a simple tag for Html 5 (which worked fine in firefox 17) does not work in Firefox 21? Work 100% in Google Chrome ! Everyone wants firefox 17 back again ! 21 version is bad. Sorry, but this is the sad reality.
This bug needs to be fixed in the front end code, but will probably require a change to Gecko too. Summary: Some users want to be able to specify in Firefox's application settings that rather than play MP3 files that are linked to directly they'd rather have Firefox just download that content, or redirect it to an external application and have that play the content. For example, click on this link http://pearce.org.nz/video/zurie.mp3 . The MP3 loads and plays in a stand alone document consisting of our built in player. If the user has specified that a MIME type should be redirected to a helper application or downloaded in "Options > Applications", that setting should be respected, ever since we enabled the Windows Media Foundation HTML5 audio/video backend that setting is being ignored. We should also add/have a setting for MP3 and M4A files too. I think the front end should have 3 options: play in Firefox, download, forward to external handler. Whether we want to make UI changes for this is up to the front end Firefox developers, but in terms of Gecko changes, we'd need to patch the IsWMFSupportedType() case in bool DecoderTraits::IsSupportedInVideoDocument(const nsACString& aType) in DecoderTraits.cpp to return false if the MIME type in question has a registered handler, or if the user has opted to download the content instead of playing it. I think we have a service that reports if there's a registered handler? Gavin: How do you feel about prioritizing this? If it's not a priority I can write a small patch to add a pref that controls whether the WMF backend plays or downloads content loaded directly in stand-alone documents, i.e. MP3 files not loaded inside an <audio> element inside a document, but requested directly.
Component: Video/Audio → General
Product: Core → Firefox
Summary: Applications setting is ignored for MP3 files → User should be able to opt to download instead of play MP3/MP4/M4A files in "Settings > Applications"
(In reply to Chris Pearce (:cpearce) from comment #22) > Gavin: How do you feel about prioritizing this? > > If it's not a priority I can write a small patch to add a pref that controls > whether the WMF backend plays or downloads content loaded directly in > stand-alone documents, i.e. MP3 files not loaded inside an <audio> element > inside a document, but requested directly. Doesn't seem like a high-priority bug we need to track, but a simple workaround like you describe could be useful.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
We can consider a low-risk uplift nomination if available.
status-firefox21: --- → affected
status-firefox22: --- → affected
status-firefox23: --- → affected
status-firefox24: --- → affected
tracking-firefox23: ? → -
tracking-firefox24: ? → -
Add a simple pref to work instruct MediaDecoder to not play MPEG files using WMF in nsVideoDocument. This will give users who's usage pattern was disrupted by enabling WMF a work around at least.
Attachment #765024 - Flags: review?(paul)
Sorry, but Yes, it's a bug ! The solution is media.windows-media-foundation.enabled: true need to be: false (default) Google Chrome and firefox 17 with the tag <audio> url streaming works, perfectly! Why not work in 21 version ? This is not logical! Improvisations script on page is not a solution, firefox should adjust media.windows-media-foundation.enabled: false (default).
Comment on attachment 765024 [details] [diff] [review] Patch: Add simple pref to work around problem Review of attachment 765024 [details] [diff] [review]: ----------------------------------------------------------------- ::: content/media/DecoderTraits.cpp @@ +524,5 @@ > (MediaDecoder::IsMediaPluginsEnabled() && IsMediaPluginsType(aType)) || > #endif > #ifdef MOZ_WMF > + (IsWMFSupportedType(aType) && > + Preferences::GetBool("media.windows-media-foundation.play-stand-alone", true)) || Maybe you could add it to all.js as well?
Attachment #765024 - Flags: review?(paul) → review+
Landed work around, with review comment addressed: https://hg.mozilla.org/integration/mozilla-inbound/rev/0d4b46a6de4c From Firefox 24 onwards, users will be able to set the pref "media.windows-media-foundation.play-stand-alone" to false in about:config to disable playback of medi a files in stand alone documents. Marking [leave open] so that a proper fix can be done here in future.
Whiteboard: [leave open]
This is possible in the current version 21, I did it. But the correct, is the default false, for all to users. At installation. So is Google Crhome.
(In reply to Juliano from comment #29) > But the correct, is the default false, for all to users. At installation. I agree that the v21 behaviour is wrong, but simply setting the default WMF to false is also wrong - there will be many occasions when I simply DO want to play the audio in the browser, but others where I want to download it. I do not want to have to remember to go to an about:config setting every time I want to switch behaviour. Even if we take the analogue with images, then we can say simply that there is a fault in the UI, because it does not provide a "save" option. My opinion is that FF needs to supply a user settable selection of play/save/ask as a workaround, and to match the experience with so many other files. The poor user should not have to know how a site is coded in order to know what to expect.
Fails in rev 22 also the same way. Please fix.
Why in SeaMonkey the media.windows-media-foundation.enabled is default FALSE ? But in the firefox default: TRUE ? http://www.seamonkey-project.org SeaMonkey uses Mozilla System Nonsense Firexox developers ¬¬
This is INSANE ! I have a website where visiters can choose to either listen to a church sermon or they can download the mp3 to play on a player for people in nursing homes and such. The way it is now, there is no way to put it on any sort of mp3 player. Please Fix this !
You should be able to just add a "download" attribute to the <a> tag on the download link to do that, but unfortunately this case isn't handled in Firefox yet. :( I filed bug 894556 to track fixing that issue (it's similar but not the same as the issue being tracked in this bug, but has the same cause). Until we can fix this, you can advise your users to right-click/save as...
Ah, you *can* use the "download" attribute links to force a download, provided that the thing your linking to is same-origin (on the same domain). So Tom, you should be able to use the "download" attribute on <a> tags to force the download of your MP3 files provided they're hosted on the same domain.
Chris, thanks for trying to help. I just tried <a href="http://www.******.net/sermons/05.12.13.mp3" download>Download</a> and it didn't work, rather it played instead of downloading. Maybe it's not coded right ?
I tried another example I found <a href="http://www.****.net/sermons/05.12.13.mp3" download="http://www.****.net/sermons/05.12.13.mp3">Download</a> Same result though. I also took a look and I can right click it though and save as, so Thanks.
Still no news on this bug? How long have these MIME type settings been ignored by Firefox, five months? That's nearly half a year for something which should be a pretty simple fix. I mean, I know that Firefox's UX team's long-term goal is to eliminate all user-configurable settings entirely, so that no aspect of Firefox's functionality can in any way be configured by the user, but until that dark day the option is still sitting there in the Applications tab, and I think I speak for 100% of Firefox's userbase when I say I'd like it to actually DO something.
(In reply to SeriousTom from comment #38) > Same result though. SeriousTom, the value of "download=" should simply be a file name with extension, eg download="sermon05.12.13.mp3" This is a nice way to force downloads without changing server headers, and also provides the ability to name files one way on the server but save them under a different name on the browser end. The problem remains, however, that this only works for files on the SAME EXACT domain name...quite unfortunate if you ask me.
(In reply to Daniel Eisener from comment #39) > I mean, I know that Firefox's UX team's long-term goal is to eliminate all > user-configurable settings entirely... Some users may agree with that sentiment, however I think as long as the settings removed from the UI remain available in about:config for advanced users, it's not too bad. To the issue at hand, the easiest solution is to use Right Click > Save Link As... on links you want to download. Perhaps webmasters will write that line of instruction alongside their links again, as was common during the IE4 era lol.
Suppose Firefox's UX team removed the setting to block popup windows, and made it default off. Suddenly, popups everywhere! Oh, but you can always go to about:config to change it, and if you click the "X" on the popup window they'll just go away. That's a suitable workaround, right? And if it's a serious problem, just contact the webmaster of the site and ask them to get rid of the popup. No, the setting should remain there, and it should actually damn well do something. We're talking about a bug in Firefox, not something that webmasters or users aren't doing properly. The setting exists in Firefox, right there under Options->Applications, it's just that some dipshit forgot to make it do anything. For six months. Expecting webmasters or users to compensate for Mozilla's many, many flaws is not a solution. Them spending 30 to 80 minutes fixing the bug themselves is. <rant>And, as an aside, "it's not too bad" is what you say when you accidentally drop a glass and it breaks, but it only breaks into two large pieces rather than shattering into a bunch of tiny shards you need to carefully pick up. It's what you say when someone tears their scrotum open in a skateboarding accident, but the doctor says there'll be no permanent damage after some stitches and a month's convalescence. What the Firefox UX team has done in moving loads of important, useful settings to an inconvenient place where almost no users will ever find them is NOT an accident, it is a series of monumentally, transcendentally stupid decisions made by people I sincerely doubt have the basic competence necessary to dress themselves in the morning.</rant>
(In reply to Daniel Eisener from comment #42) > </rant> It was not my intention to ignite any fury. If you are searching for a perfect browser, the only answer is to develop it yourself. FF developers are not gods and they do make mistakes. Maybe they will fix it, maybe they won't, but it's nice to know that workarounds are available.
Hah, it's not your fault, and my disappointment is directed firmly at Mozilla, not you. I meant no offence to you, personally. It's just an argument I find depressing. When Mozilla's advocates can summon no greater defence than "it's not too bad," it's in a poor way. But, anyway, this really isn't the forum for workarounds. That admirable service is what you do on places like support.mozilla.org and general user support forums. This is, ostensibly, the bug reporting system for Firefox, so discussion should be focused entirely on how to fix the bug--and why the bug hasn't yet been fixed--not helping a typical user work around the bug. In short, it's for helping Mozilla, not for helping their users. Proposing that webmasters modify their websites or users modify their behaviour to work around this bug is unhelpful: it distracts from the real problem (the bug) by transferring responsibility for fixing it onto the victims of the problem (webmasters and users). What we need to be doing right now is discussing the unseemly delay in responding to the bug, which hopefully will encourage someone familiar with that part of the project to fix the damn thing.
(In reply to James Donohue from comment #40) > (In reply to SeriousTom from comment #38) > > Same result though. > > SeriousTom, the value of "download=" should simply be a file name with > extension, eg download="sermon05.12.13.mp3" > > This is a nice way to force downloads without changing server headers, and > also provides the ability to name files one way on the server but save them > under a different name on the browser end. The problem remains, however, > that this only works for files on the SAME EXACT domain name...quite > unfortunate if you ask me. I appreciate your taking the time to help but I'm sorry to say that that didn't solve it. I was prepared to go ahead and change all the links but it didn't work. Maybe I'm still doing it wrong. This is what I used: <a href="http://www.********.net/sermons/05.12.13.mp3" download="sermon05.12.13.mp3">Download</a> I didn't put the real address for some reason, Thanks ... Tom
I realized I botched the above link and tried again with : <a href="http://www.********.net/sermons/05.12.13.mp3" download="05.12.13.mp3">Download</a> But it still plays instead of downloading. This is really annoying, I would fix it if I could. Does anyone from the Firefox team read these things or am I just wasting time here ? What is that Patch thing up above ? I have no idea how to use that, why aren't there instructions if it is a Patch ?
(In reply to Serious Tom from comment #46) > Does anyone from the Firefox team read these things or am I just wasting > time here ? It's unclear if they read these reports, but even if they do, I'm sorry to say this isn't the place for what you're trying to do. Trying to force a link to open as a download is an HTML or server configuration issue, not a Firefox issue; it'd be done the same way on all browsers. You should ask at a webmaster's forum for help relating to HTML or server configuration. (Although, while I'm here, try changing it to <a href="http://www.********.net/sermons/05.12.13.mp3" download="http://www.********.net/sermons/05.12.13.mp3">, and if that doesn't work, trying removing the href altogether. If that also doesn't work, then find a forum for webmasters and ask them how to force a link to always download instead of opening.) Just to be clear, Firefox not respecting their users' choice for how to handle MP3 files IS a defect specific to Firefox, but until it's fixed your only solution is to force ALL browsers to always download the file instead of playing it (that is, to force all browsers to disrespect their users' choices, but in the way you want). That solution ISN'T a Firefox specific one, hence why you'd want to look elsewhere for help with that. Sorry.
I find that media.windows-media-foundation.enabled = false is no longer working in FX 26.0a2
(In reply to L.A.R. Grizzly from comment #48) > I find that media.windows-media-foundation.enabled = false is no longer > working in FX 26.0a2 Yous should set media.directshow.enabled = false too.
Noticed the behaviour on Firefox ESR 24.2.0. The most confusing part of this is that the visible UI setting(Options > Applications > MPEG Layer 3 Audio File > Always Ask) are overridden by the backend media.windows-media-foundation.enabled=True Setting: This leaves the impression that the application settings set by the user are being ignored. Got to the bottom of it thanks to a post a Mozilla support (https://support.mozilla.org/en-US/questions/960216), but it seems to be only a half implemented feature, and the UI inconsistencies can cause confusion. I'm not a developer, but from a personal End User perspective, I think a possible remedy would be: - Add use Firefox to the Application Action Drop-down list - If set to Always Ask, add a Play in Firefox option to the selection I've made a quick UI Mockup that would tie the front end and back end settings up, which should stop the settings mismatch, and I think would allow all the above users to set their preferred way of handling audio and video links - http://www.digital-rogues.co.uk/open/Bug%20861090%20UI%20Mockup.png
Unfortunately, Mozilla devs don't care about this kind of usability issue. The simple fact of the matter is, you (and many, many other users) want Firefox to work one way, and the devs want it to work another way, and while that could be easily accommodated with a user setting, including customisable options runs counter to the "Do The Right Thing" philosophy that Mozilla is obsessed with. (Short explanation: "Do The Right Thing" means that the developers decide in advance exactly how the software will work in all situations--the "right thing"--and if users want different behaviour, that's too bad, because what the users want is the "wrong thing." This way, no configurable options need to be provided, because by definition anything different from the default laid out by Mozilla is the "wrong thing.") So, the fact that the user settings are being ignored is only a problem in the sense that /having user settings at all is a problem./ Under Mozilla's current philosophy, allowing the user /any/ control over the software is itself a defect. The only way this issue will ever be addressed is by simply removing all the configurable options regarding MP3s from the UI. MP3s will just always be opened the way Mozilla wants, and if you want different behaviour then, well, you should go ahead and make your own competing browser that opens them that way.
No ! It is not wrong my friend. Why change something that worked perfectly before ? (in previous versions). Everyone liked, always has been. Why change something good and right ? Has always existed . Sorry, is not evolution, is wrong . The correct is the default false for all to users, at installation, never other !
Since ver 28's release this no longer works to prevent Firefox from playing mp3 internally. media.windows-media-foundation.play-stand-alone;false My god am I sick and tired of this! And you idiots at Mozilla wonder why users have migrated over to Chrome on mass the last five plus years! :ROLLEYES: PS the flash keyboard focus issues are also BS!
Sadly, the disease that has caused this problem, the "Do The Right Thing" philosophy within UX circles, is endemic to Chrome's developers as well. But, I agree, as long as Firefox's UI continues to get worse and worse, there's increasingly few reasons not to jump ship. I mean, if both Chrome and Firefox are going to have astonishingly poor UIs, but Chrome is faster, why would I ever bother with Firefox?
No longer blocks: 950073
Whiteboard: [leave open] p=0 → [leave open] p=8 [qa?]
Hi all, Please consider giving some priority to this bug, it is truly aggravating.
The old pref was Windows specific, and no longer works for MP3 now that we use DirectShow for MP3. Since we switched from WMFReader to MP4Reader, the old pref won't work anymore on Windows, so this patch creates a new pref "media.play-stand-alone" that works for all platforms/backends/media-types. The old pref media.windows-media-foundation.play-stand-alone is still honoured, and media.play-stand-alone defaults to true.
Attachment #8480312 - Flags: review?(kinetik) → review+
Points: --- → 8
Whiteboard: [leave open] p=8 [qa?] → [leave open]
This caused me a serious amount of grief the other day. Is this bug actually going to get fixed any time soon? I can't believe that explicit settings in the user preferences are blatently disregarded. A simple search in Google for this problem pulls up hundreds of issues that people are having: "I changed the option in User settings but it still plays in the browser. Please, oh please, I'm going mad! How do I switch this frickin' thing off?" It seems to me to be a no-brainer. There is a link here which purports to explain the mess that is now this area: http://kb.mozillazine.org/File_types_and_download_actions Just reading the article made my brain hurt. We really need some reworking in this area to make it simpler and configurable, or at least make the current options work as a normal user would expect.
I'm not getting why this is hard to fix. If an media file (such as mp3) is in an <audio> tag, yes, that should play within the browser. But if an media file (such as mp3) is directly linked in an <a href=""> tag, then the browser should follow what is set in Settings»Applications preference for that content type (for example, mine is set to "Always Ask" which should mean Fx opens a dialog box to ask what it should do — save, open, etc). Currently, Firefox is ignoring Settings»Applications settings if media.play-stand-alone is 'true'. All that everyone is wanting changed here is that if an <a> link is clicked or if someone enters a URL in the URL bar to a media file that preferences in Settings»Application is respected. The <audio> tag, on the other hand, is fine as it currently is. <a> and <audio> or two separate types of actions.
It's a really annoying behaviour. Please, let the user choose what to do with a media file.
(In reply to jorgenota from comment #62) > It's a really annoying behaviour. Please, let the user choose what to do > with a media file. I would suggest to actually do it for _all_ file types (for example, I sometimes want to open images in an external program without saving them explicitly). That is, every MIME type must be configurable in the preferences, somewhat like Dave suggested in comment #50. And an entry "Open link with" should be added to the context menu (right click) to complement the "Save link as" and "Open link in new tab/window/..." options. In that case the user can set the default behavior in the preferences but still have an easy access to all the options for particular links. And even if the developers are boldly moving towards elimination of user settings, this context-menu entry will provide the users with a tolerable workaround.
You need to log in before you can comment on or make changes to this bug.