This is part of the event management suite which allows events to be routed to handlers other than just the one that defaults to being associated with an event.

Depending on the current setting of the event type mask for the receiving object, an event may be available for processing with this method. An initial mask that enumerates the events to be received might have been set up with the captureEvents() method. Then perhaps sometime later, some of those events may have been deselected by means of the releaseEvents() method. The remaining mask defines the finite set of events that will be visible to the object.

So, when a suitable event arrives and is captured, it can be passed on to the appropriately mapped event handler function belonging to the next object in the event handling hierarchy or to another handler belonging to the receiving object.

This means that an event can be processed via several handlers within an object before being passed to the next object in sequence. The order in which handlers and objects are visited by the event is controlled by Netscape Navigator. However, whether the event is passed on or not is controlled by the script in the handler. If it chooses not to pass on the event, then no subsequent handlers will see it, nor will any other objects.

This trickle-down effect is somewhat clumsy and uncontrolled. You can gain some control over the way that events are propagated with the handleEvent() method and applying it to the various objects that need to take the event. This does disperse the event handling around the scripts somewhat and can be difficult to maintain.

Warnings:

• This entire mechanism may become obsolete when the W3C standardizes the event handling process for the Document Object Model.