Closed Bug 464822 Opened 16 years ago Closed 16 years ago

mpeg4 video will not play in browser window on Mac

Categories

(Core Graveyard :: File Handling, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: goddard, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3

Clicking on a link to a mpeg-4 video file with file extension .mp4 does not play the video in the browser window.  Instead a dialog appears asking to if the file should be opened with QuickTime Player.  The "Do this automatically for files like this" switch is enabled but is not respected.  (Another Firefox bug report mentions this is due to a content-disposition header but there is no such header value when using the example .mp4 URL.)  The dialog says the file "is MPEG-4 media" so it has correctly deduced the file type even though the Content-Type header is wrong.   The header has "Content-Type: text/plain" instead of the correct video/mp4.  Five web unrelated sites I tested all send the incorrect content-type apparently because the commonly used web servers (Apache) do not recognize file extension mp4 as video/mp4.  The Applications pane of Preferences lists the default behavior for "MPEG-4 media (video/mp4)" as "QuickTime Plug-in 7.5.5 (in Firefox)". Because the browser has correctly inferred the file type (listed in the dialog that pops up), why does it not use the video/mp4 in browser playback?  Safari and IE both play the video back in the browser.  Using Firefox / Open File... to open the same file from a local disk does play it in the browser window.

So the bug is that Firefox infers the correct content-type for an .mp4 file inspite of incorrect content-type header of text/plain but does not respect the Application settings for displaying the inferred data type.

Reproducible: Always

Steps to Reproduce:
1. Get example url given above.

Actual Results:  
Video does not display in browser.

Expected Results:  
Video plays in browser using QuickTime Plug-in 7.5.5 which is specified under Preferences / Applications as the action for video/mp4

Same file downloaded to local disk will play in browser using Firefox / Open File..., using QuickTime Plug-in 7.5.5 as the Application for video/mp4.
Example URL is a bit hard to find in the bug report.  Here it is.

http://goddard.users.sonic.net/images/madrid-mezcala-sep08-g.mp4
You have found the third reason (there are only 3) that the file save as doesn't save the selected action:

1) content-disposition attachment
2 [review]) file is send as application/octet-stream
3) we never, never do content sniffing (look at the file and try to find the filetype based on that) except one single case: A default apache configuration that sends this file as text/plain, and only for this default configuration we correct it but you can't save the decision in that case. The reason for this is simple: The users and webmaster should not think that everything is ok with this file. That means that this is no bug, it's expected.

Example that firefox does this content sniffing only for the default apache configuration:
http://mversen.de/mozilla/text/mozilla.rar (would be the same with mp4)

marking invalid because it's by design
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Product: Firefox → Core
QA Contact: file.handling → file-handling
Resolution: --- → INVALID
Version: unspecified → Trunk
Thanks Matthias for clarifying the problem.  I believe it is still a Firefox user interface bug because Firefox is suppressing an error condition and presenting a completely misleading dialog that with "Do this automatically..." enabled.  The user sees a dialog appear where they previously turned on a switch that says "do not show this dialog again".

I will propose a specific fix.  When the "What should Firefox do with this file?" dialog is shown with the "Do this automatically for files like this" switch enabled because the web server provided a "content-type" of text/plain or application/octet-stream which Firefox believes is wrong, then the dialog should contain additional text below the "Do this automatically..." switch that says:

"Action was not taken automatically because Firefox believes the file type provided by the web server "text/plain" is incorrect and should instead be "video/mp4".

While adding this text would resolve the bug it would not do so in the best possible way.  I further suggest that in the wrong content-type scenario the "Do this automatically for files like this from now on" switch should instead read "Do this automatically for files like this from now on when the file type is inferred from the file suffix."

While my first proposed fix would resolve the bug it would not be up to the standards of competing commercial web browsers which silently handle this wrong content-type scenario.  The additional second part of the fix would exceed the standards of the commercial browsers by both informing the user of an important error in web server configuration and allowing them to still attain optimal browsing performance in future accesses to such files.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
>I believe it is still a Firefox user interface bug

The bug is not about this issue (UI). It's about that this file doesn't use an installed plugin. You would never see a save as dialog if Gecko would wouldn't see this special case like content-disposition:attachment.
The bad UI for the attachment case is a different bug and already reported
The fix is simple: The checkbox will be greyed out, we have a bug for that. 
We have also a different bug about that you can save the decision for content-disposition:attachment but that would be against the http specification and that is currently discussed. Such a wrong content-type will not be the same as a correct content type if we allow such a decision to be stored because it will always use a helper application and not a plugin.

marking invalid again because the cause is the wrong content-type. Search for the other 2 bugs in bugzilla if you want know more.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → INVALID
You cite two other bug reports about the "content-disposition:attachment" case.  That is a different problem.  Searching for wrong content-type turned up no bugs concerning the scenario I described.  I'm unclear about why you mark my bug report has invalid/resolved.  Is it that 1) this UI bug should be handled by means of additional comments to the "content-disposition:attachment" bug reports (my case does not have a content-disposition:attachment header), 2) this bug is miscategorized as file handling, 3) there is some other bug report that I could not find that already addresses this precise issue?
A couple more guesses as to why you think this bug is invalid.  You say

> The bug is not about this issue (UI).

True it started out being a bug about why a plugin is not used to play video.  Would it help if I submitted a new bug report that instead just discusses the UI problem with the "file save" dialog in the context of wrong content-type rather than content-disposition:attachment?

Another guess about why you mark this bug invalid.

> marking invalid again because the cause is the wrong content-type.

That sounds like "not our problem".  Because the web server gave wrong information then the firefox ui can do any bad misleading thing it wants.  That can't be what you mean.

Enough guessing.  Could you clarify what steps I should take to help the Firefox developers fix the UI bug described here?  The problem has annoyed me for quite some time and there is much discussion on the web about it that is years old so I am surprised it has not yet been addressed.
>Would it help if I submitted a new bug report that instead just discusses the
>UI problem with the "file save" dialog in the context of wrong content-type
>rather than content-disposition:attachment?
The initial issue is the wrong content type and firefox will correct that but will use this new content type like the server send a content-disposition:attachment. The summary "mpeg4 video will not play in browser window on Mac" together with the wrong content-type makes this invalid because this exact behavior of firefox is by design (not a bug = invalid).

It's a different issue if you talk about the UI then you are talking about the bad UI in the content-disposition:attachment case. 
I told you that there are two open bugs:
a) disable the checkbox to store the decision
b) let the user save the decision (unlikely to happen for all cases)

a) will not fix the issue in the summary and b) will also not resolve it because firefox will still use a helper application and not a plugin.
The only solution would be to just silently correct the content type and that will not happen.

If you want to know bug a) and b) you have to search the database.
and I forgot a third bug reported by me that the save as dialog should contain information why the user got the save as dialog in the case of a content-disposition:attachment case but the UI designer doesn't seem to like such an idea.
Now I think I get it.

> firefox ... will use this new content type like the server send a
> content-disposition:attachment.

So the wrong content-type handling is treated by firefox as if the web server sent a content-disposition:attachment header.  That seems twisted since the server did not send such a header in response to the get in my case.  But I don't understand "content-disposition" headers so perhaps it all makes sense.

I do think that simply graying out the checked "Do this automatically ..." switch is just as confusing as the current behavior.  The user is still denied an explanation of what is behind this malfunctioning.  So I think the third bug report you mention (that you submitted) to include additional info in the save-as-dialog to explain that this is a web server problem is essential.  I'll add such a comment to the content-disposition:attachment bug that proposes to just gray out the "Do this automatically..." switch.  Hiding the true cause of errors from the user and then behaving in confusing ways is a hallmark of lousy software.

Thanks for your detailed explanations.  Sorry it took so much of your time to explain it all.
A content-disposition:attachment header is used if the server wants a file to be saved. Such a header will force a save as dialog.

Seamonkey does display the reasons in the file save as dialog but not firefox.
But i think the short notice in Seamonkeys UI is still to complicated and most users and they don't understand what "attachment" or content-sniffing is (looking at the file itself and not the server header for the file).
But without showing anything it's worse.

But I'm wrong with the statement that I created a bug (i did that for the disabled password manager (bug 456255)  I will write a new one if i can't find an existing bug but I believe that there is somewhere such a bug
I've read a dozen bugzilla content-disposition:attachment bug reports and think the case I describe is not covered by any of those.  The example URL I provided

http://goddard.users.sonic.net/images/madrid-mezcala-sep08-g.mp4

does not send a "content-disposition:" header.  I verified this with the following web site that shows the headers.

http://www.rexswain.com/httpview.html

Your comment #7 says that firefox is treating the wrong content-type (text/plain instead of video/mp4) as if the web server sent a header "content-disposition:attachment". It apparently decides the content-type: text/plain is wrong based on content-sniffing or file suffix (.mp4).  You also suggest that it is intended firefox behavior that wrong content-type be treated as equivalent to a server-provided header of "content-disposition:attachment".  Do I understand your statements correctly?

It is wrong to treat inferred incorrect content-type as equivalent to "content-disposition:attachment".  The requirements of RFC 2183 for that header prevent optimal handling of incorrect content-type header values.  The web server did not send "content-disposition:" in my example so firefox need not enforce the requirements of RFC 2183 in this case.  Wrong content-type should be handled better by firefox and RFC 2183 is not relevant.  I found no existing bugzilla report for this.  Do you still feel this is an "invalid" bug?  If so, how would I formally request that firefox treat incorrect content-type distinctly from content-disposition:attachment?  If that behavior is "by design" is it not legitimate for a bug report to state that the design is flawed?  Would reclassifying this as a change-request instead of a bug be appropriate.  How is that done in this bug tracking system?  Thanks.
The web server sends text/plain and if firefox would follow the RFCs it would display this binary file as binary file in the browser window like my URL in comment #2. Yes, that would be the only correct behavior for the RFCs. 

In one special case (default apache misconfiguration) Gecko converts it to something like video/mp4 with with a forced save as windows like content-disposition:attachment because this happens frequently and we want a forced save as window. We treat it internal like content-disposition attachment for tzhis reasons and based on the spec we would never have this case, we would display the binary file as text/plain in the browser window.

The design is not flawed at all, the only problem is the UI and I already explained it several times in this bug that that is a different case and handled in other bugs. if the bug about disabling the checkbox wouldn't include this case then a new bug should be created for exactly this UI issue.

Again, this IS INVALID AS ALREADY EXPLAINED.
Your report in short : "Firefox forces as save as for this URL and doesn't use a plugin and you also can not save the decision for the helper application"

And exactly this is by design and that means that this bug is invalid.
I agree that it would make sense if Firefox displayed the binary mpeg-4 file as text in the browser window since content-type is text/plain.  But Firefox tries to do something more useful by presenting the file save dialog.  This bug report proposes that firefox do something even more useful.  There are no "content-disposition:" headers in the scenario covered in this bug so arguments in similar bug reports that cite RFC 2183 as prohibiting inline display or automatic helper application launching do not apply to this bug.  Those are the central arguments in those bug reports -- that a documented standard would be violated.

You have summarized in comment #12 my bug very well.  But your answer

> And exactly this is by design and that means that this bug is invalid.

simply denies that it is a bug.  Is there a reference document that says this is the Firefox design or a discussion of this design issue online?  How do you know the current behavior is "by design"?  Did you design this behavior?  I don't mean to be disrespectful with these questions.  It just seems that this poor user interface is being justified by fiat.  With the similar content-disposition bug reports there is a very sound rationale -- the defining document for content-disposition headers which guides the user interface behavior.  But in the case I describe no such reference or even discussion of user interface merits has been raised.  Your comments suggest the behavior I described in this bug report has been analyzed and agreed to be how Firefox should work.  Could you point me to that design discussion?
This will be the last comment in this bug because I think that has been discussed several times.
Forget content-disposition:attachment that's wrong, sorry for my mistake, it's like an application/octet-stream content-type.
(example URL for comparing : http://mversen.de/mozilla/octet/index.html )

application/octet-Stream means unkown binary data and Gecko detected that the requested document in this case can not be text/plain and must is some kind of binary content. The UI for Firefox is the same ((content-disposition:attachment vs application/octet/stream) in all 3 cases.

>Is there a reference document that says this is the Firefox design or a >discussion of this design issue online?  
Sure, every fix is in bugzilla and I expect that you search for the bug but i send the bug# for the backend browser sniffing fix in the private mail.

>How do you know the current behavior is "by design"?
Because I remember the fix happened several years ago and why it happened ?

You can write a new bug report for Firefox if you want to see the reasons in the UI for the 3 differen cases : application/content-stream , content-disposition:attachment and browser sniffing
but not why Gecko forces a save as (by design).
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.