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

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:

  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:

• 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:
  Note that the classIDs must be passed in curly braces "{}".

1. GeckoActiveXObject is limited to creating instances of Windows Media Player ActiveX controls. It therefore can not be used everywhere ActiveXObject is used.

2. 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

Server-side Detection Using User-agent Strings

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

operating system version;
language; rv:1.4) Gecko/20030624 Netscape/7.1 (ax[;optional
comments])
]]>

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:

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:

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:

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 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.

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

  
  
  	
  Your browser does not support the ActiveX Windows Media Player

]]>

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.

  
  
  		


]]>

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:

  




This example shows a minimally-functional player



]]>

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:

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.

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:

  if (type == "Text") 
  {
    var cap = document.getElementById("CapText");
    cap.innerHTML = param;
  }

]]>

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:

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):

]]>

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.