libaribhtml5 0.1.9 → 0.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -9,7 +9,7 @@ export declare class ExternalMediaHoleController {
9
9
  private readonly placeholderOpacities;
10
10
  private readonly backgrounds;
11
11
  constructor(target: RuntimeWindow);
12
- set(object: HTMLElement, enabled: boolean): void;
12
+ set(object: HTMLElement, enabled: boolean, clearBackgrounds?: boolean): void;
13
13
  restore(): void;
14
14
  /** Read application styles while temporarily exposing backgrounds hidden for external video. */
15
15
  withApplicationBackgrounds<T>(callback: () => T): T;
@@ -51,6 +51,8 @@ export declare class RuntimeMediaPlaneController {
51
51
  private slotIdFor;
52
52
  private callMediaPlaneAdapter;
53
53
  private unmountMediaPlane;
54
+ /** A foreground surface must not cover opaque application dialogs above its slot. */
55
+ private isCoveredByApplication;
54
56
  private reportMediaPlane;
55
57
  }
56
58
  export {};
@@ -37,6 +37,11 @@ receiver runtime は object が wrapper の唯一の子である場合に限り
37
37
  iframe より前の layer に置きます。標準の `BehindIframeMediaPlaneAdapter` は通常 `z=0`、この場合だけ
38
38
  `z=2` を使います(必要なら `behindZIndex` / `aboveZIndex` で host の stacking context に合わせます)。
39
39
  通常の全面映像や application background として使われる slot は `behind-application` のままです。
40
+ `above-application` では背景に穴を開ける必要がないため、object / media-only wrapper の透明化だけを行い、
41
+ application element の背景色・背景画像は保持します。後景から前景へ切り替わる場合は退避した背景を復元します。
42
+ 前景 slot 全体が上位の不透明な矩形パネルで覆われた場合は、外部 surface のみ visible=false として
43
+ 調査の選択・閉じるボタンを保護します。パネルを閉じると元の矩形・layer のまま表示を復元します。
44
+ 半透明や部分的な重なりの完全な interleave は、この外部 iframe 合成方式の対象外です。
40
45
 
41
46
  `display: none`、`visibility: hidden`、`content-visibility: hidden` は矩形計測または可視判定を壊すため
42
47
  使用しません。runtime は隠す前の computed opacity を media-plane report に使い、host 側の video は
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "libaribhtml5",
3
- "version": "0.1.9",
3
+ "version": "0.2.0",
4
4
  "description": "Browser runtime and receiver host for ARIB HTML5 data broadcasting",
5
5
  "keywords": [
6
6
  "arib",
@@ -1,300 +0,0 @@
1
- # Receiver compatibility roadmap
2
-
3
- ## Purpose and scope
4
-
5
- This document records the remaining receiver-runtime work needed to run long-lived ARIB
6
- HTML5 data services in HonomiTV. The primary target is live and recorded BS4K/BS8K
7
- playback, including viewer-participation programmes. An isolated demo and Komorebi are useful
8
- secondary checks, but they are not the integration source of truth.
9
-
10
- The component boundary is:
11
-
12
- | Component | Responsibility |
13
- | --- | --- |
14
- | `tlvdemux` | Parse MMT/TLV, MMT-SI, LCT, MH-AIT, EMT, EIT, and carousel resources |
15
- | DPlayer | Own playback and forward typed TLV events without changing their meaning |
16
- | `libaribhtml5` | Own iframe/VFS, receiver API objects, application state, permissions, media slots, and receiver input state |
17
- | HonomiTV | Own live/recorded mode, service/session lifetime, remote-control UI, network proxy, and user-facing notices |
18
-
19
- Broadcaster directory names such as `sh4`, `sh8`, or `bsfuji4k` are not protocol fields and
20
- must not become policy. Application entries come from the active MH-AIT/resource context.
21
-
22
- This status was reviewed on 2026-08-02 against the English ARIB TR-B39 2.5 and STD-B62 2.2
23
- documents in `../ARIB-docs`, plus extracted NHK BS4K/BS8K applications.
24
-
25
- ## Current coverage
26
-
27
- The current runtime already covers the receiver API surface exercised by the inspected NHK
28
- applications:
29
-
30
- - early runtime bootstrap and `receiverDevice.getSystemInformation(null)`;
31
- - `getDeviceIdentifier()` and the legacy `bmlCompat.browserPseudo.getIRDID()` path;
32
- - persistent-array compatibility and receiver-owned regional information;
33
- - current/following EIT delivery;
34
- - immediate general event-message delivery;
35
- - carousel resource retention callbacks;
36
- - caption existence, subscription, and TTML/resource delivery;
37
- - MH-AIT identity, application replacement, destruction, and managed-state exit;
38
- - application boundary/permission bitmap evaluation;
39
- - broadcast media-slot discovery and external media-plane composition;
40
- - LCT receiver background colour with an application-stage fallback;
41
- - receiver clock projection from stream time and media position.
42
-
43
- The important remaining work is mostly state and lifecycle semantics rather than adding names
44
- which only return a placeholder value.
45
-
46
- ## P0: required for long-lived interactive broadcasts
47
-
48
- ### Viewer-participation corner notification and input ownership
49
-
50
- TR-B39 Part 1 Volume 3 section 6.2.5 defines a receiver-level notification for games,
51
- questionnaires, and viewer voting:
52
-
53
- - `data_event_id` is `0xF`;
54
- - `event_msg_group_id` is `0xF00`;
55
- - the EMT has no event-message descriptor;
56
- - receiving it does not raise an interrupt event in the broadcast application;
57
- - when receiver input is not directed to the data application, the receiver may show a notice
58
- which lets the viewer make the application controllable with a simple operation.
59
-
60
- This differs from an application `GeneralEventMessageListener`. It must not be injected into
61
- the page as an invented EMT callback.
62
-
63
- `Application.show()`, `hide()`, `activateInput()`, and `deactivateInput()` currently return
64
- success without changing receiver state. They need to update a receiver-owned application
65
- presentation/input state. `AribReceiverHost` then needs a host-facing viewer-participation
66
- notification contract. HonomiTV remains responsible for rendering the notice and deciding
67
- which UI action transfers control to the application.
68
-
69
- A future API may resemble the following, but these names are not yet a stable contract:
70
-
71
- ```ts
72
- const host = new AribReceiverHost({
73
- iframe,
74
- viewport,
75
- onViewerParticipation(event) {
76
- if (event.requiresUserAction) showDataBroadcastParticipationNotice()
77
- },
78
- })
79
-
80
- host.notifyViewerParticipationCorner({
81
- contextId,
82
- serviceId,
83
- version,
84
- })
85
- ```
86
-
87
- Repeated transmissions must be deduplicated by the current tuning generation, service, and
88
- message version. A service/session reset clears the notification state.
89
-
90
- Parser prerequisite: the current `tlvdemux` EMT parser emits events only for an event-message
91
- descriptor (`descriptor_tag=0xF003`). It must expose the descriptor-less `0xF00` receiver
92
- notification separately instead of fabricating a general event message.
93
-
94
- Acceptance criteria:
95
-
96
- 1. A hidden or input-inactive application causes one host notification for a new participation
97
- corner version.
98
- 2. An already controllable application does not cause an unnecessary notice.
99
- 3. Repeated transmission of the same version does not spam the UI.
100
- 4. The notification is never delivered to an application EMT listener.
101
- 5. Changing service or playback session discards the old notification.
102
-
103
- ### Carousel resource update and deletion semantics
104
-
105
- Real NHK application code uses `storeDataResource("./", listener)` to monitor a directory and
106
- detect source updates or disappearance. The current cache implementation is centered on an
107
- exact resolved URL:
108
-
109
- - directory listeners do not observe descendant resource changes;
110
- - VFS `put()` does not automatically notify the active receiver runtime;
111
- - the Service Worker protocol has no single-resource deletion operation;
112
- - `notifyDataResource()` is a separate manual action which an integrator may omit;
113
- - a removed resource may therefore remain readable from the VFS mirror.
114
-
115
- VFS mutation and CacheEvent notification should share one receiver-owned lifecycle. The
116
- event contract needs atomic `updated`, `deleted`, `store_finished`, and `store_failed`
117
- semantics for both file and directory targets. A directory listener must match descendants
118
- without receiving unrelated application resources.
119
-
120
- A future high-level host contract should cover update, deletion, and session reset in one place,
121
- for example:
122
-
123
- ```ts
124
- host.updateBroadcastResource({ path, revision })
125
- host.removeBroadcastResource(path)
126
- host.resetBroadcastResources()
127
- ```
128
-
129
- The VFS may retain older bytes until a complete new resource is committed, but the runtime
130
- must not report `updated` before those new bytes are readable.
131
-
132
- ### Complete MH-AIT state and update listeners
133
-
134
- `setApplicationInformation()` currently describes only the application owning the active
135
- document. The receiver also needs the complete current MH-AIT so it can implement:
136
-
137
- - `Application.getOwnerAIT()`;
138
- - `ApplicationInformationTable.getApplications()`;
139
- - `streamEvent.addAITUpdateListener()`;
140
- - `streamEvent.removeAITUpdateListener()`.
141
-
142
- The host should accept one detached, validated table snapshot containing the table version and
143
- all applications in transmission order. Updating the table must preserve the currently running
144
- document when the continuation rules allow it, update its identity/permission snapshot in
145
- place, and notify registered AIT listeners. A removed or killed active application must exit.
146
-
147
- HonomiTV already maintains all demuxed application states, so it should pass that snapshot
148
- rather than reimplementing the AIT object in application code.
149
-
150
- ### Correct event-ID update behaviour
151
-
152
- TR-B39 requires `addEventIDUpdateListener()` to call the listener once immediately with an
153
- `ISDBResourceReference`, then again whenever the current event ID changes. The current
154
- runtime queues a zero-argument callback only after a later `program-info` update.
155
-
156
- The runtime must additionally:
157
-
158
- - provide `original_network_id`, `tlv_stream_id`, `service_id`, and `event_id`;
159
- - use `event_id: null` when no current event exists;
160
- - distinguish `tlv_stream_id` from the legacy `transport_stream_id` compatibility alias;
161
- - avoid notifying merely because a title, description, or duration changed;
162
- - return the present/following fields and `null` values required by the receiver API contract.
163
-
164
- The inspected NHK application includes a delayed polling fallback when this listener does not
165
- start, so fixing the semantics removes a real receiver-compatibility workaround rather than an
166
- abstract completeness issue.
167
-
168
- ### Atomic broadcast-session reset
169
-
170
- An integrator currently has to clear captions, EIT, the broadcast clock, LCT colour,
171
- application information, queued EMT events, resource state, and the iframe separately. Missing
172
- one call leaks old-service state into the next application.
173
-
174
- Add one generation-changing operation, tentatively `resetBroadcastSession()` or
175
- `beginBroadcastSession()`, which atomically:
176
-
177
- - invalidates the previous runtime and asynchronous completions;
178
- - clears application/AIT and participation state;
179
- - clears EIT, EMT backlog, UTC/NPT alarms, and broadcast clock;
180
- - clears caption tracks/subscriptions;
181
- - clears LCT colour and application-stage fallback;
182
- - resets retained carousel resources and CacheEvent listeners;
183
- - restores the ordinary media plane.
184
-
185
- The individual setters may remain for incremental updates within a session.
186
-
187
- ## P1: compatibility needed after the P0 state model
188
-
189
- ### Capabilities and playback source
190
-
191
- Implement `navigator.capabilities.hasCapability()` as a host-configurable feature matrix.
192
- Unknown queries must return `false`; advertising a feature requires the corresponding API and
193
- host bridge to work.
194
-
195
- Implement `receiverDevice.streamEvent.sourceIs("onair")`. HonomiTV already knows whether
196
- the manager was created for live or recorded playback, so the runtime must not guess from a
197
- carousel path or current URL. TR-B39 recommends this optional API for receivers that execute
198
- data content during recording playback.
199
-
200
- ### Broadcast video/audio object controls
201
-
202
- Only caption discovery/listener methods are currently implemented. STD-B62 Volume 2 section
203
- 2.2 also defines:
204
-
205
- - fullscreen enable, disable, and query;
206
- - audio mute enable, disable, and query;
207
- - video/audio source selection and query;
208
- - caption source selection;
209
- - caption visibility set/query.
210
-
211
- These operations should be added to the media-plane adapter contract. The runtime must not
212
- pretend they succeeded without changing DPlayer/native media state.
213
-
214
- ### Receiver API error and callback conformance
215
-
216
- Centralize ARIB receiver errors with `INVALID_PARAM_ERR`, `NOT_AUTHORIZED_ERR`,
217
- `NOT_FOUND_ERR`, `TIMEOUT_ERR`, and `MISC_ERR`. In particular:
218
-
219
- - asynchronous callbacks must not run after a synchronous API exception;
220
- - device-identifier acquisition failure returns `null`, not an empty string;
221
- - `confirmIPNetwork(destination, confirmType, timeout)` needs argument validation and a
222
- host-provided result rather than only returning the configuration flag;
223
- - synchronous APIs must validate object shapes and integer ranges consistently.
224
-
225
- ### Storage and network isolation
226
-
227
- All broadcast documents currently share the HonomiTV origin. Without an emulated application
228
- storage boundary, different broadcasters can collide in `_wlocal*`, Ureg, and other
229
- `localStorage` names. Persistence should be scoped by receiver policy and application identity
230
- while retaining explicitly receiver-owned regional information.
231
-
232
- Application-boundary permission bit 9 must apply to direct storage access as well as the
233
- `readPersistentArray()` and `writePersistentArray()` compatibility functions.
234
-
235
- External traffic should use a typed host request provider. HonomiTV currently rewrites
236
- `fetch`, XHR, and `sendBeacon` to its same-origin proxy after runtime installation. Moving that
237
- contract into the receiver host allows permission/boundary checks to precede the proxy and
238
- avoids competing monkey patches. Subresources, forms, WebSocket/EventSource, redirects, and
239
- managed-state navigation need an explicit support or rejection policy.
240
-
241
- ## P2: optional and lower-risk receiver functions
242
-
243
- Implement these only after the session state and parser inputs are stable:
244
-
245
- - UTC-NPT reference listeners, `getUTCNPT()`, alarms, and cancellation;
246
- - data-event-ID update listeners;
247
- - `tuneTo()` through an explicit host callback;
248
- - viewing/recording scheduling APIs through the receiver EPG/backend;
249
- - CAS-provider-specific extensions.
250
-
251
- The runtime must not expose these through `hasCapability()` until their end-to-end behaviour is
252
- available.
253
-
254
- ## Integration event matrix
255
-
256
- | Input/state | `tlvdemux`/DPlayer output | `libaribhtml5` action | HonomiTV action |
257
- | --- | --- | --- | --- |
258
- | LCT background | layout configuration | Set/reset receiver background plane | Forward event only |
259
- | MH-AIT | complete table/application states | Update AIT, active application, permissions, listeners | Select lifecycle candidate and pass snapshot |
260
- | Carousel file | complete resource/revision/delete | Commit VFS mutation and CacheEvent atomically | Forward owned bytes and session generation |
261
- | MH-EIT p/f | present/following event | Update event object and event-ID listeners | Convert demux time/fields only |
262
- | General EMT | typed event message | Match registered application listeners | Forward without interpreting broadcaster IDs |
263
- | Participation EMT `0xF00` | dedicated receiver notification | Evaluate visibility/input state and request a notice | Render notice and transfer control on user action |
264
- | Liveness source | host playback mode | Implement `sourceIs("onair")` | Supply live versus recorded state |
265
- | Service/session change | generation change | Atomic receiver-session reset | Call once before replaying the new snapshot |
266
-
267
- ## Validation plan
268
-
269
- Library tests should cover each contract without requiring broadcaster media:
270
-
271
- - immediate and change-only event-ID callbacks with structured references;
272
- - complete AIT snapshots, ordering, version changes, continuation, removal, and KILL;
273
- - directory CacheEvent matching, atomic update, deletion, and reset;
274
- - participation notification deduplication and input/visibility combinations;
275
- - session-reset rejection of late callbacks from the old generation;
276
- - capability truthfulness and live/recorded `sourceIs()` behaviour;
277
- - media object state and adapter command failures;
278
- - application-scoped storage and permission changes.
279
-
280
- End-to-end replay should then use:
281
-
282
- - NHK BS Premium 4K for ordinary startup, EIT, receiver API, and long-running resource updates;
283
- - NHK BS8K for LCT/background, external media holes, caption applications, and 8K viewport state;
284
- - BS Fuji 4K for a non-NHK application entry and storage/path compatibility check;
285
- - a synthetic descriptor-less `0xF00` EMT fixture for viewer-participation UI, because an
286
- archived programme is not guaranteed to contain that notification.
287
-
288
- Passing unit tests or a local SDK build is not equivalent to proving the deployed HonomiTV
289
- bundle, browser composition, remote focus, or multi-hour live behaviour.
290
-
291
- ## Standards references
292
-
293
- - ARIB TR-B39 2.5-E1, Part 1 Volume 3, section 6.2.5 and Appendix 1: viewer-participation
294
- corner notification and expected receiver UI.
295
- - ARIB TR-B39 2.5-E1, Part 1 Volume 3, section 10.7: permissions and receiver extended APIs.
296
- - ARIB STD-B62 2.2-E1, Volume 2, section 2.2: broadcast video/audio object.
297
- - ARIB STD-B62 2.2-E1, Volume 2, sections 3.3.7 through 3.3.13: application, capabilities,
298
- receiver device, stream events, and cache control.
299
- - ARIB STD-B60 and STD-B62: MH-AIT/LCT transport state and receiver media/background-plane
300
- composition; see the focused lifecycle and media-plane documents in this repository.