ScreenTinker c4ee7d008f web player: declare capabilities at runtime, persist them, and audit all four players ... The dashboard offered every control to every display, so a browser tab showed a reboot button that could never work. server/lib/player-capabilities.js defines the vocabulary; this makes the web player actually speak it. The declaration is computed, not constant, because the same index.html is BOTH the browser player and the BrightSign player. system.reboot / display.power / display.resolution / system.self_update are claimed only when BS.hasHost() answers — deliberately hasHost() and not isBrightSign(), since the UA check is also true for a widget built without node integration, which can reach none of them. Screenshots, offline cache, transitions and native sync are each probed the same way. Capabilities were never persisted: the column and the handler did not exist, so a declaration would have been sent and silently dropped. Added the migration and applyCapabilities(). An ABSENT declaration leaves the column NULL so the baseline still applies — several hundred fielded displays declare nothing and would otherwise lose every control at once — while an EMPTY declaration is stored as '[]' and honoured. docs/player-parity.md records every capability against all four players with a reason for each "no", and flags three Tizen baseline errors found while verifying it. Tests: 1109/1109. Both inline <script> blocks in index.html parse clean.		2026-08-05 14:17:40 -05:00
..
dashboardSocket.js	refactor(auth): centralise session token resolution across manual verify sites	2026-07-24 20:58:05 -05:00
deviceSocket.js	web player: declare capabilities at runtime, persist them, and audit all four players	2026-08-05 14:17:40 -05:00
index.js	Initial open source release	2026-04-08 12:14:53 -05:00