Windows Media in Netscape

Netscape 7.1 has the ability to load the Microsoft® Windows Media Player™ as an ActiveX control, and thus developers can now build multimedia experiences that script the Windows Media Player in Netscape 7.1, just as they do in Internet Explorer. Netscape 7.1 will work with both the Windows Media Player 6.4 ActiveX control as well as versions 7 through 9. This article explains how to embed the Windows Media Player ActiveX control in web pages to support Netscape 7.1, how to control the Windows Media Player ActiveX control using JavaScript and provides working examples. This article deals uniquely with Netscape 7.1 running on the Windows operating system.

Detecting the Right Browser

Like Internet Explorer, Netscape 7.1 and later versions can play Windows Media files using the popular Windows Media Player ActiveX control. This control is widely used to provide inline media support for web pages that provide sound, video and other media. Controls such as Windows Media Player also interact closely with the scripts in a web page. Netscape 7.1 is the first Netscape Gecko™ browser to support the Windows Media Player as an ActiveX control -- previous Netscape browsers did not support any ActiveX controls, and thus detecting which versions of Netscape support the Windows Media ActiveX control is an important first step towards building multimedia experiences using HTML, JavaScript, and the Windows Media ActiveX control. The Windows Media 9 Series SDK documentation for Netscape browsers says that versions of Netscape (including 6.2 and 7.0) support the embedding of the Windows Media Player control using a Java Applet. While that approach works with browsers older than Netscape 7.1, this section introduces the use of the objects that enable deployment of the Windows Media Player directly as an ActiveX control within Netscape 7.1.

This section presents two mechanisms to detect the browsers that support Windows Media Player --

• Detection using JavaScript Objects which is useful for client-side detection
• Detection using the user agent string which is useful for server side detection.

An advantage of the client-side approach is that it is also possible to detect if Windows Media Player is installed.

Client-side Detection Using JavaScript Objects

Internet Explorer implements the ActiveXObject object to create new instances of ActiveX controls. Netscape 7.1 introduces GeckoActiveXObject which can be used in a similar way to create instances of the Windows Media Player.

The following JavaScript illustrates one approach using object detection of ActiveXObject and GeckoActiveXObject to determine if the Windows Media ActiveX control is supported and available for use. JavaScript will dynamically write out what browser you are running, and what kind of Windows Media Player technology you may have.

Example 1: Client-side Detection Scripts

   Browser architecture supports: NetscapePlugin
   Windows Media Player Installed: true
   Windows Media Scriptable: false
   Windows Media Version: PluginVersion

A complete source code listing showing how that detection was done can be found here (devedge-temp). Below, some of the salient points are illustrated in a code snippet:

if (window.ActiveXObject && navigator.userAgent.indexOf('Windows') != -1) {
  // IE for Windows object instantiation -- use of ActiveXObject
} else if(window.GeckoActiveXObject) {
  // Netscape 7.1 object instantiation --use of GeckoActiveXObject
} else if(navigator.mimeTypes) {
  // Plugin architecture, such as in Netscape 4x - 7.02 and Opera browsers
}

Since IE for Mac also exposes window.ActiveXObject it is wise to determine if the browser in question is on Windows.

Both ActiveXObject and GeckoActiveXObject function similarly. The next subsection discusses them in detail.

GeckoActiveXObject vs. ActiveXObject

Both GeckoActiveXObject and ActiveXObject work very similarly, with one key difference:

Both take a Programmatic ID (ProgID) and use it to create a reference to the Windows Media Player. The ProgID of Windows Media Player is MediaPlayer.MediaPlayer.1. While the ProgID cannot be used to create a Windows Media Player object that exposes all its properties and methods, it is useful for rapid detections. Here is a code snippet that shows this:

var player;
try {
  if (window.ActiveXObject) {
    player = new ActiveXObject("MediaPlayer.MediaPlayer.1");
  } else if (window.GeckoActiveXObject) {
    player = new GeckoActiveXObject("MediaPlayer.MediaPlayer.1");
  } else {
    // Plugin code using navigator.mimeTypes
    player = navigator.mimeTypes["application/x-mplayer2"].enabledPlugin;		
  }
} catch(e) {
  // Handle error -- no WMP control
  // Download: http://www.microsoft.com/windows/windowsmedia/download/default.asp
}
if (player) {
  // Windows Media Player control exists
}

Currently, dynamically writing out markup using document.write after using detection mechanisms won't work owing to a bug in Netscape 7.1.

• Both ActiveXObject and GeckoActiveXObject can take WMPlayer.OCX.7 as an argument to create the control if Windows Media Player 7 or 9 are present. Unlike using the ProgID as an argument, using WMPlayer.OCX.7 as an argument to both these APIs creates a fully usable reference to the Windows Media Player 7 or 9 control, with all the methods and properties exposed to JavaScript. Furthermore, you know for certain that you are working with the Windows Media 7 or 9 control -- there is no comparable instantiation for the Windows Media Player 6 control. For the sake of brevity, we've made the following code snippet shorter to illustrate the relevant points about the API:

var player;
try {
  if(window.ActiveXObject) {
    player = new ActiveXObject("WMPlayer.OCX.7");
  } else if (window.GeckoActiveXObject) {
    player = new GeckoActiveXObject("WMPlayer.OCX.7");
  }
} catch(e) {
  // Handle error -- no WMP 7 or 9 control
  // Can use WMP 6 also if necessary, but this is legacy software nowadays
}
if (player) {
  // Windows Media Player control exists and it is version 7 or 9
  // Can use WMP 7 or 9 API -- call versionInfo property, only in 7 and 9
  var versionString = player.versionInfo;
  alert(versionString);
}

• Only GeckoActiveXObject allows for the use of the Windows Media Player classID as an argument. Since classIDs are affiliated with individual ActiveX controls in a unique manner, this allows for unique instantiation of controls. Netscape 7.1 works with both Windows Media Player 6.4 and with Windows Media Players 7 and 9, but they have unique classIDs:
  • Windows Media Player 6.4 has this classID:22D6F312-B0F6-11D0-94AB-0080C74C7E95
  • Windows Media Players 7 and 9 have this classID: 6BF52A52-394A-11d3-B153-00C04F79FAA6

Windows Media Player 6.4 and Windows Media Player 7 and up are not backwards compatible in terms of APIs (and thus have different classIDs).

Here is a snippet of code that illustrates the use of classIDs with GeckoActiveXObject:

function createGeckoWMPObject(clid) {
  var player = null;
  try {
    player = new GeckoActiveXObject(clid);
  } catch(e) {
    ;
  }
  return player;
}
// instantiate players
wmp7or9 = createGeckoWMPObject("{6BF52A52-394A-11d3-B153-00C04F79FAA6}");
if (!wmp7or9) {
  wmp64 = createGeckoWMPObject("{22D6F312-B0F6-11D0-94AB-0080C74C7E95}");
}
 .....

Note that the classIDs must be passed in curly braces "{}".

The name GeckoActiveXObject rather than ActiveXObject was introduced for two reasons:

• GeckoActiveXObject is limited to creating instances of Windows Media Player ActiveX controls. It therefore can not be used everywhere ActiveXObject is used.
• ActiveXObject is used by many web developers to detect the presence of Internet Explorer in much the same fashion as document.all is used. For example

if (window.ActiveXObject) {
  // Internet Explorer only script
}

Server-side Detection Using User-agent Strings

Netscape 7.1's user agent string on Windows has the general pattern:

Mozilla/5.0 (Windows; U; <em>operating system version</em>;
<em>language</em>; rv:1.4) Gecko/20030624 Netscape/7.1 (ax<em>[;optional
comments]</em>)

The "Vendor Comment" (ax) following the "Vendor Version" Netscape/7.1 is an indicator that the browser supports the Windows Media Player ActiveX control.

For example on Windows XP, Netscape 7.1's user agent string may be:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Netscape/7.1 (ax)

If the client was customized by a third party, additional information may be present in the "Vendor Comment" area of the user agent string. For example:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Netscape/7.1 (ax; PROMOSTRING)

Although GeckoActiveXObject is currently available only in Netscape 7.1 on Windows, it may be the case in the future that it will be available in other Gecko-based browsers on other operating systems.

Detecting the presence of the strings Gecko/ and (ax should provide for the ability to detect any Gecko-based browsers which supports GeckoActiveXObject which may be introduced in the future.

For example, a possible regular expression to detect if GeckoActiveXObject is supported could be:

/Gecko\/[^)].*\(ax/

Embedding the Control in Web Pages: Use of the OBJECT element

Netscape 7.1 allows the use of the OBJECT element of HTML to be used to instantiate the Windows Media Player control in the same way it is used in IE. This differs from what previous Netscape Gecko browsers did -- those browsers only supported the Netscape-plugin architecture, and not the ActiveX architecture, and thus the markup used for browsers prior to Netscape version 7.1 (devedge-temp) was distinct.

Example 2: Use of OBJECT Element to Create Control

If you are running Netscape 7.1 and later or IE, and have installed Windows Media Player 7 or above, the snippet of code below should produce a Windows Media control and play a song.

THIS IS THE EXAMPLE: NEEDS TO BE EMBEDDED IN WIKI PAGE (can it just be put here?)
<object id="PlayerEx2" classid="clsid:6BF52A52-394A-11d3-B153-00C04F79FAA6" height="200" width="200">
  <param name="uiMode" value="full">
  <param name="autoStart" value="True">
  <param name="URL" value="media/preludesteel.wma">		
  Your browser does not support the ActiveX Windows Media Player
</object>

The same markup (used above and shown below) will work in both IE and Netscape 7.1.

<object id="PlayerEx2" classid="clsid:6BF52A52-394A-11d3-B153-00C04F79FAA6"
        height="200" width="200">
  <param name="uiMode" value="full" />
  <param name="autoStart" value="true" />
  <param name="URL" value="preludesteel.wma" />	
  Your browser does not support the ActiveX Windows Media Player
</object>

The classid attribute references the clsid of Windows Media Player 7 and above -- Windows Media Player versions before 7 used a different clsid. Examples in this article all assume that the user is running Windows Media Player 7 and later, although Netscape 7.1 supports the clsids of Windows Media Player 6x and later.

It is important to note that in Netscape 7.1, only the classid for Windows Media Player is supported, and no other control can be created. The various param elements that can be used and the functionalities behind them is best described by the Windows Media 9 Series SDK.

In Netscape 7.1, the codebase attribute of the object element cannot be used to initiate a digitally signed download of the Windows Media control, if it is not present on the machine. The section below on scripting the control covers more on how to detect if the Windows Media Player has not been successfully created.

Scripting the Windows Media Player Control

The number of methods and properties that are exposed by the Windows Media Player, including the events that the player throws for handling by scripts in the web page containing the control, are covered in detail by the Windows Media Player SDK. This section covers relevant issues concerning the invocation of methods and properties from within web pages that are embedding the Windows Media control.

Detecting Successful Creation of the Control

Often, usage of ActiveX controls in IE involve the use of the object element along with a codebase attribute that initiates a download of the component if it is missing from the machine running the web page. The Windows Media 9 Series SDK doesn't provide a URL to use with the codebase attribute for retrieval of the component in IE, and on Netscape 7.1 the codebase attribute isn't supported for such retrieval. Therefore detecting whether the component was successfully instantiated can help provide users with the right component if a failed instantiation is detected. The code listing below provides a mechanism to to this.

<object id="PlayerEx2" classid="clsid:6BF52A52-394A-11d3-B153-00C04F79FAA6"
        height="200" width="200">
  <param name="uiMode" value="full" />
  <param name="autoStart" value="true" />
  <param name="URL" value="preludesteel.wma" />		
</object>
<script type="text/javascript">
if(!document.PlayerEx2.versionInfo) {
  // Control Not installed -- the versionInfo property returns null
  // Redirect users to http://www.microsoft.com/windows/windowsmedia/download/default.asp
} else {
  //Control was correctly created
  //Proceed with scripting calls, etc.
}
</script>

Note that if the control is correctly instantiated, you will know that it is a version of Windows Media Player 7 and up, since the clsid used with the object element reflects the unique component in this version range.

Scripting the Control

Namespacing issues are the most important distinction between scripting the Windows Media control in IE and Netscape 7.1. In code deployed for IE, invocations of the sort Player.controls.play(); are common, where Player is the id of the object element. In Netscape 7.1, plugins and ActiveX controls are not exposed to the global namespace, but rather as properties of the document object. Accessing properties and controls from the document object works well with IE also, and thus, in order to deploy cross-platform code, avoiding syntax that makes use of global namespace is important.

Here, for example, is a code snippet that works equally well on both Netscape 7.1 and IE:

<object id="Player" height="0" width="0"
  CLASSID="CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6">
  <param name="autoStart" value="true">
</object>
<input type="button" name="PlayMedia" value="Play" OnClick="StartMediaUp()">
<input type="button" name="StopMedia" value="Stop" OnClick="ShutMediaDown()">
<P>This example shows a minimally-functional player
<script>
<!--
function StartMediaUp () {
  document.Player.URL = "preludesteel.wma";
  document.Player.controls.play();
}
function ShutMediaDown () {
  document.Player.controls.stop();
}
-->
</script>

More extensive examples of working cross-browser code can be found in the examples section at the end.

Qualifying references with document. is sufficient to resolve the namespace issue. So for example, an object can be called from IE and Netscape 7.1 like this: document.Player.controls.play(). For programming convenience, the object could be assigned to a temporary variable, e.g.

var thePlayer = document.Player; 
thePlayer.controls.play()'

Programmatic Creation of the Control and Scripting

As mentioned above, both GeckoActiveXObject and ActiveXObject can be used to create instances of the control. Here's an example of directly instantiating the control programmatically (without an object element) and scripting it:

try {
  var player = null;
  if (window.ActiveXObject) {
    player = new ActiveXObject("WMPlayer.OCX.7");
  } else if(window.GeckoActiveXObject) {
    player = new GeckoActiveXObject("WMPlayer.OCX.7");
  }
} catch(e) {
   ;
}
if (player) {
  player.currentPlaylist = player.mediaCollection.getByName('preludesteel');
  player.controls.play();
}

Callbacks from Within Windows Media Player To Web Pages: Script For Event

Netscape 7.1 supports IE's <script for="ActiveXControl" event="ActiveXControlEvent"> script elements. No Netscape browser prior to Netscape 7.1 has supported this non-standard way of writing scripts that handle information sent by a plugin or control.

A good illustration of the use of this non-standard script element syntax is in creating closed captioning of media content. Automatic closed captioning does not work in Netscape 7.1 as it does in IE. In IE, a named HTML element such as a DIV may be given to the Windows Media Player control and it will be automatically updated with caption data. This does not work in Gecko because it requires IE DOM functionality that has not been implemented. Fortunately, Windows Media Player also fires a ScriptCommand() event for closed captioning, which means content may update the caption manually with a small piece of JavaScript.

For example, in IE it is possible to do this:

Player.closedCaption.CaptioningID = "CapText";

Here, "CapText" is the id of an HTML element, assigned to the CaptioningID property of the Player. Instead of doing that, this is the recommendation and workaround for Netscape 7.1:

<script FOR="Player" EVENT="ScriptCommand(type, param)">
  if (type == "Text") 
  {
    var cap = document.getElementById("CapText");
    cap.innerHTML = param;
  }
</script>

More detailed examples are available in the final section on examples and sample code.

Important Caveats and Usage Scenarios

This section covers some of the common usages in conjunction with Windows Media Player and IE that should not be used with Windows Media Player and Netscape 7.1.

Detection Strategies

Proper detection strategies are important for cross-browser development using ActiveX controls in Internet Explorer and Netscape 7.1. Browser Detection and Cross Browser Support provides a good introduction to the general issues involved.

Using object-based detection to detect the vendor and version of a browser and its support for ActiveX controls can lead to problems. For example, if you use document.all to detect Internet Explorer 4 and later and the availability of ActiveXObject you will not support Netscape 7.1.

Bad Approach

if (document.all) {
  // use ActiveXObject or write IE only OBJECT markup
} else {
  // use Netscape Plugins
}

Better Approach

if (window.ActiveXObject) {
  // ActiveXObject is supported
} else if (window.GeckoActiveXObject) {
  // GeckoActiveXObject is supported
} else {
  // use Netscape Plugins
}

Use of Microsoft's MSXML in Conjunction with the Windows Media Player

Remember that Windows Media Player is the only ActiveX control that Netscape 7.1 supports. Use of Microsoft's MSXML in conjunction with use of Windows Media Player is common, particularly since both are offered to the developer community as ActiveX controls for IE browsers. In particular, the XMLHttp object is a popular one for establishing dynamic channel communication. Netscape 7.1 offers its own XMLHttpRequest object; here is a snippet of cross-browser code that can be used:

if (window.ActiveXObject) {
  req = new ActiveXObject("Microsoft.XMLHTTP");
} else if (window.XMLHttpRequest) {
  req = new XMLHttpRequest();
}
// req can be used in a cross-browser way -- the actual objects are similar
// Caveat emptor: look out for the case of methods and properties -- IE uses
// capital letters where Gecko uses lowercase

Other popular uses of Microsoft's MSXML objects are for in-memory manipulation of XML documents via XSLT, perhaps to construct dynamic data for the Windows Media Player. Netscape Gecko based browsers such as Netscape 7.1 provide comparable implementations of XSLT transformations in memory via JavaScript. Use of HTML Behaviors in Conjunction with Windows Media Player

The only IE emulation that Netscape 7.1 does in terms of HTML usage is with respect to the object element usage with clsid and script for="" event="" syntax.

DHTML behaviors can be used in Internet Explorer to perform ActiveX control detection. For example, the following uses DHTML behaviors to associate a set of behaviors with a SPAN element, which is then interrogated for its version number (the script attempts to verify that the Windows Media Player control is at version 9):

<span style="behavior:url(#default#clientCaps)" id="cc"></span>
<script language=JavaScript>
var cv = cc.getComponentVersion(
  "{6BF52A52-394A-11D3-B153-00C04F79FAA6}",
  "componentid"
);
if (cv == null || cv == "") {
  top.location.href = "http://foo.bar.foo/checkref";
}
</script>

Netscape 7.1 does not support IE's DHTML Behaviors. In order to use the Windows Media Player control in both Netscape 7.1 and IE, you need to avoid browser-specific detection mechanisms like this.

Summary: Cross Browser Use of Windows Media Player in IE and Netscape 7.1

1. Don't use proprietary DOM sniffs such as looking for document.all-- this will rule out Netscape 7.1.
2. When scripting the player, ensure that you use the syntax document.PlayerElementName.property as opposed to PlayerElementName.property. Merely adding document. as a prefix to player scripting calls solves the namespacing difference between Netscape 7.1 and IE.
3. Both Netscape 7.1 and IE handle the nonstandard HTML format script for event in script HTML tags. An example is the usage of close captioning. In the case of close captioning media content, the player API Player.closedCaption.CaptioningID = "CapText"; is not supported, and the workaround is to capture events fired by the Media Player in script using script for event.
4. Do not use IE only markup or IE only features, such as DHTML Behaviors or use MSXML in conjunction with the control.

Examples of Usage in Netscape 7.1 and IE

All these samples consist of one page of markup (and script) that works in both IE and Netscape 7.1. No code forking has been used.

• The min-object-usage.html sample shows a minimalist control manipulated by scripting and HTML buttons. An object element creates the controls.
• The embedded-audio-video.html shows both scripting the control and callbacks.
• closecap-outtakes.html shows the closed captioning workaround and scripting.