Open Bug 1222725 Opened 9 years ago Updated 2 years ago

Firefox can't play renamed .mp3 file

Categories

(Core :: Audio/Video: Playback, defect, P3)

Unspecified
Windows
defect

Tracking

()

Tracking Status
firefox45 - affected

People

(Reporter: arni2033, Unassigned)

References

()

Details

(Keywords: dupeme, parity-chrome, regression)

Attachments

(1 file)

STR: (Win7_64, Nightly 45, 32bit, ID 20151107030439, new profile) 1. Download this .mp3 file > https://dl.dropboxusercontent.com/s/azwo7orgayzyu5l/koivikkosami_sapphire_02_sapphiredasopawasrem.mp3?dl=0 2. Open saved local file in a new tab 3.A) Right-click free space around the <video> element, click "View Page Info", select "Media" tab in "Page Info" window, click "video" file, click "Play" in "Media Preview" section. 3.B) Create a copy of saved file with name "koivikkosami_sapphire_02_sapphiredasopawasrem.m4a" or "koivikkosami_sapphire_02_sapphiredasopawasrem", open that copy in a new tab Result: After Step 2 audio controls display "1:11/1:11" and file can not be played After Step 3 audio file appears to be 6:04 in length and is played normally Expectations: After Step 2 audio controls should display real length of the audio and the file should start playing Just like it starts playing in GoogleChrome (browser) and AIMP 3 (audio player) Note: It was regressed (/changed its behavior) 3 times (three): (1) The .mp3 file opened correctly before this pushlog between 2013-12-03 and 2013-12-04. After those changes, it started to display the message "File couldn't be played because it's corrupted" (but I still was able to play the file by setting pref media.directshow.enabled -> false) > http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8648aa476eef&tochange=9688476c1544 ^ Bug 945947 (2) I was able to play the file by setting pref media.directshow.enabled -> false BEFORE this pushlog between 2014-08-26 and 2014-08-27. After those changes, the .mp3 file started to open Windows' open/save dialog (if the pref above was set to false) If that pref was set to default [true], the .mp3 file still said "File is corrupted". > https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dc352a7bf234&tochange=0753f7b93ab7 (3) The .mp3 file said "File is corrupted" (if media.directshow.enabled was set to default) and opened Windows' save/open dialog (if that pref was set to false) BUT After this pushlog (between 2015-10-02 and 2015-10-03) the audio controls started to display wrong length of the audio (1:11), and the file still couldn't be played. > https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c7933be0b031390aaa4e70676124ba28f9cb6278&tochange=ecbe6589d36e490fe8d3c9b5b2d88de394f6918c ^ Bug 1209410, bug 1209388(?) If that's how it should work, please break the audio playback in Page Info window too for consistency
Sounds like we're inconsistent about when we apply the sniffer.
Priority: -- → P2
Has STR: --- → yes
Flags: needinfo?(ajones)
Reproducible on Windows, not on Mac.
OS: Unspecified → Windows
Daniel - P2 is the correct priority because neither the current nor the past behaviour was by design. It happened to work in the past but that doesn't make it a regression.
Flags: needinfo?(ajones)
How do I get this off the list?
Flags: needinfo?(dveditz)
> It happened to work in the past but that doesn't make it a regression. From a user's POV it is. We're tracking these because we're concerned about user perception that the new release is of lower quality than a previous one, but check with the release team who is the one doing the tracking. > How do I get this off the list? I assume you don't mean by lying to the queries (because that's easy). Comment 3 is a great answer. Triagers should see that next pass through and make the appropriate changes. I'm trying by setting the "tracking" flag to "minus" for this release. That wasn't enough to get it off the list on Monday but we've reported that as a bug in the queries.
Flags: needinfo?(dveditz)
I've got more important things to fix than an edge case where someone does something stupid and it worked at one point on Windows. I'd rather focus on the user perception that YouTube worked better on Flash than it does on HTML5 for some users. The plan is for regressions not to unintentionally slip into a release. This is not a regression and I can live with it going to release if we don't have time to fix it.
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #6) > edge case where someone does something stupid and it worked at one point on Windows That is kind of rude. That "someone" who implemented good old playback mechanism is your co-worker after all. I sometimes see comments like "this monkey-written code was implemented in 2006", and I don't understand how it's possible to work with such attitude to each other. If by any chance you meant the reporter (which is also rude), please have some respect maybe? I know it's a common practice to say "edge case" as a synonym to bugs you simply don't want to fix, but it's rather stupid to make such statement when you don't see the use case (like you did) The use case: There was a site which stored ALL music in .mp3 format. However, <audio> tag was able to play it properly. So, I wrote a new STR specially for you, Anthony. Consider this page: > data:text/html,<audio controls src="https://dl.dropboxusercontent.com/s/azwo7orgayzyu5l/koivikkosami_sapphire_02_sapphiredasopawasrem.mp3"> STR_2: 1. Open the "data:" url above in a new tab 2. Right-click the audio, click "Save Audio As", click "Save" in Windows modal dialog. 3. Open downloads panel, drag just downloaded file from downloads panel between any two tabs. STR_3: 1. Open the "data:" url above in a new tab 2. Right-click the audio, click "Copy Audio Location" 3. Open new tab, right-click urlbar, click "Paste & Go". I'm looking forward to learn what step is the most stupid in your opinion. If you care for _my_ opinion, the really stupid thing is to implement more and more (buggy) brand new stuff in Firefox when there're thousands of long-standing bugs. Btw I filed 827 bugs. But seriously, "I report - you fix". There's no place for calling each other stupid. I hope that from now on, everybody will be a bit more polite.
(In reply to arni2033 from comment #7) > (In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #6) > > edge case where someone does something stupid and it worked at one point on Windows > That is kind of rude. That "someone" who implemented good old playback > mechanism is your co-worker after all. I sometimes see comments like "this > monkey-written code was implemented in 2006", and I don't understand how > it's possible to work with such attitude to each other. I do stupid things all the time. That is not the same as me being stupid. What I said was badly worded and I apologise for that. I was trying to convey that relying on undefined behaviour is unwise. This is in relation to whether this issue is a regression or a compat issue. It is a compat issue because the current behavour has always been our intent yet sites appear to be relying on the buggy behaviour. > If you care for _my_ opinion, the really stupid thing is to implement more > and more (buggy) brand new stuff in Firefox when there're thousands of > long-standing bugs. Btw I filed 827 bugs. ... and only two of them are media playback.
Mass change P2 -> P3
Priority: P2 → P3
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [parity-Chrome] [dupeme] → [dupeme]
Keywords: dupeme
Whiteboard: [dupeme]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: