60688 - JavaScript reports MIME type missing when it is not

Status: VERIFIED DUPLICATE of bug 58811

(Core :: DOM: Core & HTML, defect, P3)

Description

[David Shochat]

When attempting to activate a streaming mp3 link on mp3.com, a page is 
displayed claiming that there are missing MIME types.

Yet, the xmms helper application is correctly associated with the required
MIME type (audio/x-mpegurl), as can be seen by going into the page source,
and copy/pasting an actual m3u URL into the browser's URL entry field. This
causes xmms to be invoked and the music to be played.

The failure is due to the use of a javascript function to check whether the
browser supports the required MIME type. Evidently it reports that the type
is not supported even though it is.

The problem has existed in every build I've tried it on. These are all
CVS builds, on 11/11, 11/17, 11/18, and most recently 11/19/2000 (12:46 EST).

Comment 1

[Phil Schwartau]

Confirming with 20001105xx commercial and Mozilla binaries on WinNT.
However, note:  the same problem occurs for me with NN4.7 !!!
On my WinNT box, only IE 4.7 is advancing to the next page properly.


Steps to reproduce: 

1. Go to http://www.mp3.com/
2. Click on "Play Music Now!" (upper-right on page)


Here is the JavaScript function involved. I did some debugging to find 
out which case we fall into in NN4.7 and N6; indicated by arrows below: 


function checkMimetype(mimetype,theURL) {
  failURL = "http://www.mp3.com/help/diagnosis/diagnosis1.html";
  if (navigator.appName.indexOf("Netscape") != -1) {
    getCookie('mp3_mimetypecheck','off');
    if (window.CTCcookieget=='off') {
      location.href=theURL;
      return false;
    }
    if (! navigator.mimeTypes) {
      setCookie('mp3_mimetypecheck','on','9999');
      location.href=failURL;
      return false;
    }
    if (! navigator.mimeTypes[mimetype]) {
      setCookie('mp3_mimetypecheck','on','9999');
      location.href=failURL;
      return false; <<<<<<<<<<<<<<<<<<<<<<<<<<< IN NN4.7 AND N6, WE END UP HERE
    }
    if (! navigator.mimeTypes[mimetype].suffixes) {
      setCookie('mp3_mimetypecheck','on','9999');
      location.href=failURL;
      return false;
    }
  }
  var referring = refurl();
  var modurl = theURL + '?refer=' + referring + '&brwsk=ie.m3u';
  location.href=modurl;
  return false;
}



Reassigning to DOM Level 0 for further triage -

Comment 2

[Phil Schwartau]

On my WinNT box, this is what I get with N6 and a Mozilla trunk binary: 


Iterating through navigator.mimeTypes[i].description in N6:

i = 0     RealPlayer(tm) as Plug-in (*.rpm)
i = 1     Flash (*.swf)
i = 2     FutureSplash Player (*.spl)
i = 3     Netscape Default Plug-in (*.*)
i = 4     HP Peripheral Interrogator Files(*.hppi)


Same thing with a Mozilla trunk binary:


i = 0     RealPlayer(tm) as Plug-in (*.rpm)
i = 1     Flash (*.swf)
i = 2     FutureSplash Player (*.spl)
i = 3     Mozilla Default Plug-in (*.*)


NOTE: if I do this with NN4.7, I get HUNDREDS of navigator.mimeTypes !!!

Comment 3

[Phil Schwartau]

Attachment: For convenience, here is the HTML iterating the mimeTypes -

Comment 4

[Phil Schwartau]

Compare bug 58811 - "navigator.mimeTypes object is not filled out in javascript"

Comment 5

[David Shochat]

In Netscape 4.75 (Linux), the javascript query returns the right answer (the
MIME type association having been set up), xmms comes up and the music plays. So
it's not just IE that does it right.

Comment 6

[Phil Schwartau]

Attachment: A more sophisticated HTML file iterating the mimeTypes

Comment 7

[Phil Schwartau]

[e-mail] :

Out of curiosity, in Mozilla does the MIME type association you set up for xmms
show up correctly in Edit|Preferences|Navigator|Helper Applications ?

Is that how  you made the association? Thanks -

Comment 8

[David Shochat]

In reply to Phil Schwartau:
Yes, the association does show up correctly in Edit|Preferences|Navigator|Helper
Applications.
And yes I set it up using that dialog but specifically:
1. I navigated to the application using the Choose... button. It perhaps needs
   a full path currently.
2. After setting up the association, I had to select the MIME type I had just
   added and then Click the Edit button. That allowed me to UNcheck the
   "Ask me before opening ..." checkbox. It never worked until I discovered
   that. That option had not been available when setting up the new type in
   the first place. The checkbox was visible, but could not be activated.

Comment 9

[Terry Hayes]

*** Bug 61289 has been marked as a duplicate of this bug. ***

Comment 10

[David Shochat]

I rebuilt Linux Mozilla with CO date 2000-11-30 12:56:17 PST,
and now I can no longer reproduce the original problem. Has someone fixed
this bug? I'm only talking about the top-level behavior I originally described.
In other words, the streaming links at mp3.com now work for me even with JS on.
Based on a quick look at the page source, they still seem to be doing the JS check.

Comment 11

[Phil Schwartau]

[e-mail]: 

What happens when you click on the attachments at 11/19 and 11/22 above?
Do they correctly show the MIME type now? In other words, is the MIME type 
correctly showing up in the navigator.mimeTypes array now?

Comment 12

[David Shochat]

My mistake. When I click on the attachments, none of the helper app-related
MIME types show up.
So I took another look at the javascript code mp3.com is using. It now includes
the following:
...

    //NS 6 fails at this line, see bugzilla:
    // http://bugzilla.mozilla.org/show_bug.cgi?id=60688
    //therefore, if NS 6, return TRUE -- tylerv 11/30/2000
    if ((navigator.appVersion.indexOf("5") == 0)  ||
        (navigator.appVersion.indexOf("6") == 0)) {
        location.href = theURL;
        return true;
    }

So they have simply put in a workaround. Sorry.

Comment 13

[Johnny Stenback (:jst)]

*** This bug has been marked as a duplicate of 58811 ***

Comment 14

[Phil Schwartau]

Marking Verified as duplicate -