DOM events for A/V Control object
Support in HbbTV
Available since: HbbTV 1.0 (ETSI TS 102 796 V1.1.1, OIPF DAE V1.1)
To make the A/V Control object as defined in CEA-2014-A in line with the other scripting objects in section 7 of this specification, for the intrinsic events listed in the table below, a corresponding DOM event SHALL be generated in the following manner:
Intrinsic event | Corresponding DOM event | DOM Event properties |
onfocus | focus (as defined in section 5.2.1.2 of the DOM Level 3 Events specification as referenced in [OIPF_DAE2_WEB]) | Bubbles: No Cancellable: No Context Info: None |
onblur | blur (as defined in section 5.2.1.2 of the DOM Level 3 Events specification as referenced in [OIPF_DAE2_WEB]) | Bubbles: No Cancellable: No Context Info: None |
onPlayStateChange | PlayStateChange | Bubbles: No Cancellable: No Context Info: None |
onFullScreenChange | FullScreenChange | Bubbles: No Cancellable: No Context Info: None |
Note: these DOM events are directly dispatched to the event target, and will not bubble nor capture. Applications SHOULD NOT rely on receiving these events during the bubbling or the capturing phase. Applications that use DOM event handlers SHALL call the addEventListener() method on the CEA-2014 A/V Control object. The third parameter of addEventListener, i.e. “useCapture”, will be ignored.
When handling PlayStateChange events, since the property “playState” of the A/V Control object always returns the current play state, there are a number of considerations:
- When accessing the playState property inside a PlayStateChange event handler, its value will be the current state of the related media object that may be different from the state transition that caused the handler to be called.
- The playState property may change value during the execution of the PlayStateChange event handler.
- For an A/V Control object there is no way to detect which state transition caused the event handler to be executed.