Closed Bug 414310 Opened 17 years ago Closed 17 years ago

Windows Media Player is not embedded in Firefox 3 (beta)

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 395110

People

(Reporter: ice, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012604 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012604 Minefield/3.0b3pre

<object data="midi.mid" type="application/x-mplayer2" width="300" height="45">
<param name="volume" value="-100">
<param name="autostart" value="true">
<param name="loop" value="false">
<param name="balance" value="0">
<param name="autorewind" value="true">
</object>

Above html does not embed Windows Media Player online, although when tested locally the player is embedded. The WMP version is 11.0.5721.5145.


Reproducible: Always

Steps to Reproduce:
1. Visit URL http://www.teanow4pm.co.uk/midi/midiload.htm
2. Select song title
3. Play in default player

Actual Results:  
In Firefox 3 beta nothing happens. The player is not embedded.


Expected Results:  
The song should play in embedded Windows Media Player.
I tried this on WINDOWS XP SP2
Version: unspecified → Trunk
For example this file :
http://www.teanow4pm.co.uk/midi/jazz1/unsq.mid 
is send by the server with "Content-Type:	audio/midi" and if you look in about:plugins you will notice that the Media-Player doesn't support this mime-type:

Microsoft® Windows Media Player Firefox Plugin

    File name: C:\Program Files\SeaMonkey\plugins\np-mswmp.dll
    np-mswmp
application/x-ms-wmp 	np-mswmp 	* 	Yes
application/asx 		* 	Yes
video/x-ms-asf-plugin 		* 	Yes
application/x-mplayer2 		* 	Yes
video/x-ms-asf 		asf,asx,* 	Yes
video/x-ms-wm 		wm,* 	Yes
audio/x-ms-wma 		wma,* 	Yes
audio/x-ms-wax 		wax,* 	Yes
video/x-ms-wmv 		wmv,* 	Yes
video/x-ms-wvx 		wvx,* 	Yes

-> invalid
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
If the server sends it with audio/midi, why? Look at the frame source. The file type is application/x-mplayer2, which works like a charm in Netscape 7.2, 8, 9, Firefox 1, 1.5, 2 (and in 3 beta, provided it's local).
Note: Windows Media Player won't be the default player if the following check returns false:

// Media Player Netscape 7.1 & Firefox plug-in
if (win&&ns71up) {
wmp7n = navigator.mimeTypes && navigator.mimeTypes["application/x-mplayer2"] && navigator.mimeTypes["application/x-mplayer2"].enabledPlugin}

var ns71up=(gecko)?(parseFloat(ua.split("GECKO/")[1])>=20030600):false; // also FF 

var gecko=(geckold&&window.find); // NN7+,FF

var geckold=document.getBoxObjectFor;

If wmp7n is false (default), then:

// See if the Mime type has a plugin; usually midi doesn't
midimime = (navigator.mimeTypes && navigator.mimeTypes["audio/midi"] && navigator.mimeTypes["audio/midi"].enabledPlugin)?true:false;

// Crescendo could be installed
cresmime = (navigator.mimeTypes && navigator.mimeTypes["music/crescendo"] && navigator.mimeTypes["music/crescendo"].enabledPlugin)?true:false;

a content-type given by a server overrides a content type given in the object tag.
If you use the test locally, then you don't have a content type override.
Firefox is using either the type from the object tag or registry values (I don't know).

Media Player is the default plugin in my case (wmp7n=true)because my installed Media Player plugin supports "application/x-mplayer2" and is enabled.

How do you know the server is doing that?

Why doesn't the server do that (if it does) when other browsers are used?

To be honest, I have never heard of a server overriding the content type.

BTW, the bug? is on another server too. http://www.teanow4pm.demon.co.uk/midi/midiload.htm exhibits the same strange behavior.

Believe me, if Windows Media Player is in the browser's plugins array and application/x-mplayer2 is enabled - both should be the case on Windows XP with Netscape 7.1 or above and Firefox - the server has no business overriding the content type.

You can see the content type send by the server for example if you open http://web-sniffer.net and enter http://www.teanow4pm.co.uk/midi/jazz1/unsq.mid .

Again, you want to play audio/midi with a plugin that only supports application/x-mplayer2 (and a few other mime types). The server gives a browser the information what type of content the file contains and it's a audio/midi file. If the media player supports playing midi files then the plugin have to report that to the browser.
This behavior is a must by the http RFC and yes, IE violates the spec like many others in this case because it's doing content sniffing.
You have to fix the server to send the correct mime-type for example with a .htaccess file. 

just open http://mversen.de/mozilla/midi/unsq.mid and the file should playing in Firefox (compare the mime-type with web-sniffer.net). 



The server has no business overriding the content(mime)-type.

True, www.teanow4pm.co.uk (server 1) and www.teanow4pm.demon.co.uk (server 2) do not recognize unsq.mid as an application/x-mplayer2 file. I would recommend setting the midi mime-type on your server mversen.de to audio/midi too, rather than application/x-mplayer2, unless you always want midi to play/open/save in Windows Media Player, ie. audio/midi is more universal in theory. In practice audio/midi might not be associated with a player/plugin.

I tried web-sniffer. Thanks.

The problem is this:

wmp7n means nothing as far as web-sniffer is concerned. It only cares about the file served. When you tell a browser to parse "wmp7n = navigator.mimeTypes && navigator.mimeTypes["application/x-mplayer2"] && navigator.mimeTypes["application/x-mplayer2"].enabledPlugin", it returns true or false. True embeds Window Media Player. Firefox 3 beta does not embed Windows Media Player online. Either it can't or it refuses. If it can't it's a bug, if it refuses, ... 

I don't think the server has anything to do with it. I hope my analysis makes sense.

All right, I tested the "server overrides the mime-type" theory.

I installed Crescendo MAX in Firefox 3 beta (Minefield). To reproduce the experiment download Crescendo MAX:

http://www.midistudio.com/Crescendo/c51unimx.htm

and also install it in Firefox 3.

Use http:/www.teanow4pm.co.uk/midi/midiload.htm, the same as before, to link to the midi page. When you play a song it will be a different mime-type. Crescendo MAX is the default player.

cresmime = (navigator.mimeTypes && navigator.mimeTypes["music/crescendo"] &&
navigator.mimeTypes["music/crescendo"].enabledPlugin)?true:false;

supercedes:

wmp7n = navigator.mimeTypes && navigator.mimeTypes["application/x-mplayer2"] &&
navigator.mimeTypes["application/x-mplayer2"].enabledPlugin

Here is the object tag on the html page that embeds the midi file:

<object data="jazz1/dona.mid" type="music/crescendo" width="200" height="55">
<param name="volume" value="90">
<param name="autostart" value="true">
<param name="loop" value="false">
<param name="balance" value="0">
<param name="autorewind" value="true">
</object>

Result: The embedded Crescendo plugin plays/streams the selected midi song online. That is how it should be and that is how it is.  

Conclusion: Windows Media Player is not embedded in Firefox 3 (beta) = bug.

Please open "about:plugins" (as URL without the "") and tell me which mime-types are supported by the Crescendo plugin. I bet that the plugin reports that it can play audio/midi.

And for my server: This is only a test and i changed the mime-type for only that directory on the server because audio/midi is the correct mime-type for midi files. 

Your JS sniffing doesn't do anything. You can just use an object tag to play the file and Firefox will pick up a plugin that supports playing audio/midi.
It will fail if there is no installed plugin.


You're right, I was wrong:

From about:plugins:

LiveUpdate Crescendo version 5.1

    File name: NPMIDI32.DLL
    LiveUpdate Crescendo

MIME Type 	Description 	Suffixes 	Enabled
audio/x-songsafe 	Crescendo SongSafe 	cre 	Yes
audio/songsafe 	Crescendo SongSafe 	cre 	Yes
audio/midi 	LiveUpdate MIDI 	mid 	Yes
audio/mid 	LiveUpdate MIDI 	mid 	Yes
audio/x-midi 	LiveUpdate MIDI 	mid 	Yes
application/x-midi 	LiveUpdate MIDI 	mid 	Yes
audio/x-mid 	LiveUpdate MIDI 	mid 	Yes
music/crescendo 	LiveUpdate MIDI 	mid 	Yes
audio/midi 	LiveUpdate MIDI

I find it unreasonable. Why on earth would anybody embed a player if that player can't play the media? Windows Media Player obviously does play midi files. I don't know what the guidelines are, but if they state the browser should ignore the html object tag, the guidelines are wrong. Embedding the player, even if it doesn't support the file type, is better than not embedding the player, because that surely won't play the file. Give me one good reason why that should be done.

Bottom line, Firefox 3 by implementing this, is treating me, the designer like a machine. There are enough incompatibility issues in the world without forcibly creating new ones.

I will simply have to exclude Firefox 3 from embedding WMP. It that really necessary?

The problem here is that Media Player supports playing midi files (which is fine) but the Plugin from Microsoft doesn't tell Firefox that it accepts audio/midi.
This is the fault of the plugin.
The whole plugin handling is not different from Netscape6.X/7.X, Mozilla1.X or Firefox 2.X.
There is only a different plugin with older Media Player Versions and i think this plugin supported playing midi files.
We would not discuss this problem if the Media Player wouldn't fail in this case.


Media Player 7+ is the modern player. Before version 7 Media Players came with a different ActiveX control.

The navigator plugin is the same in every browser that uses it. WMP never tells the browser it accepts audio/midi (on the "about:plugins" page anyway). I think Firefox 3 is just being more fussy than other browsers, not allowing the plugin to be embedded.

Netscape 7.0 and earlier Netscape versions didn't support the plugin. There were crashes and other frequent misadventures. Since Gecko/20030600 Gecko browsers do support it. All that may be about to change, if you're unlucky enough to have an audio/midi mime-type.

Is it a bug? I'm not sure anymore. A plugin-handling bug?

Adding application/x-mplayer2 and disabling midi/audio in my local Apache configuration proves you were right. I wonder why Firefox 3 needs this.
I don't know about the ActiveX control, Mozilla, Firefox does only support npapi plugins and I think WMP before Version7 came with a different npapi plugin. They don't use all the same kind of plugin. IE5+ is using an ActiveX plugin while Firefox, Opera, Safari, Konquerer, IE4, Netscape6, Netscape4 are using NPAPI plugins. It's possible that Netscape added a ActiveX to npapi wrapper in Netscape7 to support playing activeX Plugins. The reason for this is that MS released the npapi plugin only some time ago.

You can use .htaccess in the directory with the midi files to change the content type only in the directory with the midi files and not on the whole server.
Create a .htaccess file with this content in the midi file directory: 
AddType application/x-mplayer2 .mid
I used that in my example in comment#7 but this is just a a workaround for the broken Microsoft Media Player Plugin.

I'm surpirsed why you ask why this is needed after all the discussions,
Firefox requests http://test.example/test.midi and the server responds with the content type audio/midi. Firefox now looks in the list of installed plugins (you can see the list in about:plugins) if there is a plugin that supports audio/midi.
It fails because The Media Player doesn't support it or better it doesn't told firefox that the plugin can play this mimetype.
If you cange the mime-type to application/x-mplayer2 on your server then Firefox looks in the installed plugin list and it finds the Media Player Plugin that supports this content type. The Media Player gets the file and plays.

I will stop the discussion now because this is no bug in Firefox, it's an error in the WMP plugin. It still works if you have another plugin installed that supports playing midi files.


I don't dispute it's an error in the WMP plugin. Always was, always has been. The question is why does Firefox now with the release of version 3 pending suddenly after all these years, going on five if my calculations are correct, decide application/x-mplayer2 isn't good enough anymore, and that the mime-type, which never bothered anyone previously, has to be audio/midi, which as far as I know isn't supported by any other plugin with the exception of Crescendo MAX that stopped being distributed in 2003. We're talking about MIDI! The format that musicians use to record music before its turned into wave sound. Sure, I can fix it on the server, and break Crescendo MAX in Firefox 3. Why? Why now? There's an old saying: if it ain't broke, don't fix it.

Bug, in my opinion. 
Sorry, the discussion is useless if you don't read.
There changed _NOTHING_ in Firefox3 for this plugin handling.
The plugin handling in such a case is exactly the same as with Firefox2, Mozilla1.0, Netscape6.0, Mozilla0.6 or earlier
BTW: Mozilla1.0 was released on June 5, 2002.
Your server reports audio/midi and there is no plugin installed for audio/midi if you only have the media player plugin installed. How should Firefox know that this Plugin supports audio/midi if it doesn't tell Firefox that ?
This is a very simple logic and I don't know why you still can't follow that logic after i did my best to explain this.
If you want to get this fixed then you have to ask Microsoft to fix their broken npapi plugin.

Mozilla is a Gecko browser; I haven't tried it. The turning point for Netscape was 20030600. Before embedding WMP caused problems.
 
application/x-mplayer2 is fairly common, not just for embedding midi files. Assuming someone embeds an avi that way, they'd experience the same issue.

Does Firefox 2 embed the player when you go to http://www.teanow4pm.co.uk/midi/midiload.htm? Sorry, I have to ask you this again. You sound very convinced Firefox 2 does not embed WMP.

When I try, Firefox 1.x, 2.x, and Netscape 7.1+ embed the Media Player.

Isn't this bug a duplicate of bug 395110?
It is. No mention of WMP and application/x-mplayer2. A lot of pages are going to notice it.

Somebody could do some market research before making up new rules.

Reverse this. There, I've cast my vote.
Resolution: INVALID → DUPLICATE
> Somebody could do some market research before making up new rules.

You mean before applying the rules required by the HTML specification?
The situation only happens when server mime-type and the <embed> or <object> tag specified mime-type don't match each other.

So follow the HTML spec and make allowances for when there is a conflict, that could include certain mime-types exempted from the spec and could be an area for market research.

New and undefined mime-types deserve better than to be misrepresented by servers. Another scenario: what happens when there are two or more mime types for the same file type (music/crescendo, audio/midi)? Can servers handle that or do the only allow one definition per file type? I would suggest, though not an expert, allowances for some generic mime-types like text/html and text/css, and also popular non-standard mime-types like application/x-mplayer2.

Collected data (from market research) headed: "how often do servers mistakenly identify mime-types?" - could be submitted to the W3C. Just an idea.

Saved by the embed tag I've been trying to avoid so much. Where the embed tag is used and the content-type specified within the tag does not match the type on the server, the server does not override the content-type. Embedding files with the embed tag seems to be a valid workaround. I wish I had known before. The HTML5 spec is looking more and more unfounded, inconsistent. How come the object tag and not the embed tag? I'm not complaining. <embed> works, or I've really fluffed it here, big time.

I'm fixing the URL that supposedly demonstrates the bug. Don't be surprised.
You need to log in before you can comment on or make changes to this bug.