mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-14 06:16:20 -06:00
c1270599c3
The parity doc and the capability model had drifted from the players in both
directions, and nothing failed when they did. Auditing all four players against
their shipped sources turned up three controls a customer can press today that
change nothing, and a set of baselines that were partly too generous and partly
too stingy.
The three dead controls:
- The volume slider works on Android only. The dashboard sends set_volume as
{ level: 0..1 }; the web player reads payload.value and Tizen reads
payload.value ?? payload.volume, so on both the number is undefined and the
handler quietly declines. Three complete, working volume implementations
that cannot be driven. The fix is one line in each player and belongs to
those files; audio.volume is out of the web and brightsign baselines until
it lands, held there by a biconditional test that fails the moment a player
starts reading `level`.
- Every #161 Tier-2 command was refused for the entire fleet. lock_now,
power_menu, status_bar, block_uninstall and unblock_uninstall were gated on
system.device_owner, which no player declares and no baseline grants, so
supports() was false everywhere -- including on the device-owner panels the
feature was built for. The dashboard still drew the buttons because it also
gates on device.tier === 2. Fixed here: those five now accept
system.device_owner OR system.kiosk, which PlayerCapabilities.kt declares
under `if (isOwner)` and nothing else, and which no non-Android player
declares. Android should declare system.device_owner and retire the
stand-in.
- enable_system_capture required the capability it creates. It raises the
MediaProjection consent dialog -- the way a panel GAINS capture -- and was
gated on remote.screenshot, so the only panel that needs it was the one
panel that could not be sent it. Now ungated. The dashboard still hides the
button behind the same check; that half is a frontend change.
The baselines describe what an un-updated fielded display can do, and since
v1.9.29 is the first build in which any player declares anything, that means
v1.9.28. Every entry is now justified against `git show v1.9.28:<source>`:
- android loses display.power (v1.9.28 answers screen_on with a logged no-op,
so the ON half is dead on every fielded panel and one capability renders
both buttons) and system.reboot (owner-only; off-owner it paints an
accessibility power dialog over the signage). Scheduled reboots now skip
undeclared Android panels rather than logging a reboot that never happened,
which is the reason that gate exists.
- tizen gains display.power: v1.9.28 implements both halves with no signing
and no panel API, so withholding it hid a working control.
- brightsign loses audio.volume, display.power, system.reboot,
system.restart_player and offline.cache. All need a host bridge the unit is
not known to have, and restart_player without one is the page reload that
darkened a panel on 2026-07-28.
Also found, not fixed here because the files belong to others:
st-bridge.js computeCapabilities() is dead code -- nothing calls BS.capabilities()
-- and its 199 lines of passing tests constrain nothing a BrightSign actually
declares; the two disagree on six capabilities and the bridge is right about
most of them. BrightSign's "Force update" button is dead. PlayerCapabilities.kt
under-declares display.brightness.
The new test reads the player sources rather than the table: a dead-button rule
(every gated command has a branch somewhere), an unreachable-capability rule
(which would have caught system.device_owner), and biconditionals so a fix in a
player fails the test until the baseline follows. Claims that need hardware --
CEC reaching a display, a widget being allowed a service worker, SyncManager
holding frame lock -- are marked unverifiable in the document instead of
asserted.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL
60 lines
3 KiB
JavaScript
60 lines
3 KiB
JavaScript
'use strict';
|
|
|
|
// A player declares what it can do; the dashboard hides the controls it cannot honour.
|
|
//
|
|
// The failure this guards is the one that would hit hardest: several hundred displays are already
|
|
// in the field and declare NOTHING. If an absent declaration were persisted as "supports nothing"
|
|
// they would all lose their controls the moment this shipped. So absent must leave the column NULL
|
|
// (baseline applies) while an EMPTY declaration is stored as '[]' and honoured — a real statement
|
|
// from, say, a BrightSign widget with no host bridge.
|
|
//
|
|
// Those two cases differ by one character in the payload and by an entire dashboard in effect.
|
|
|
|
const { test } = require('node:test');
|
|
const assert = require('node:assert/strict');
|
|
const caps = require('../lib/player-capabilities');
|
|
|
|
// The exact filter the socket handler applies before writing.
|
|
const persistedValue = (raw) => {
|
|
const declared = caps.parseDeclared(raw);
|
|
return declared === null ? null : JSON.stringify(declared);
|
|
};
|
|
|
|
test('THE FLEET CASE: an absent declaration is not persisted, so the baseline still applies', () => {
|
|
assert.equal(persistedValue(undefined), null);
|
|
assert.equal(persistedValue(null), null);
|
|
const legacy = { client_type: 'apk' }; // column stays NULL
|
|
// Was system.reboot until the parity audit: STPolicy.reboot() needs device owner, so the
|
|
// undeclared fleet never had that one. restart_player is a control it genuinely does have.
|
|
assert.ok(caps.supports(legacy, 'system.restart_player'), 'legacy Android keeps its controls');
|
|
});
|
|
|
|
test('an EMPTY declaration IS persisted and is honoured as "nothing"', () => {
|
|
assert.equal(persistedValue([]), '[]');
|
|
assert.deepEqual(caps.capabilitiesFor({ client_type: 'apk', capabilities: '[]' }), []);
|
|
});
|
|
|
|
test('a hostile or malformed declaration never reaches the dashboard', () => {
|
|
// Not persisted at all -> the device keeps its baseline rather than gaining anything.
|
|
for (const bad of ['not json', '{"a":1}', 42, ' ']) assert.equal(persistedValue(bad), null);
|
|
});
|
|
|
|
test('unknown capability names are dropped, known ones survive', () => {
|
|
// A newer player declaring something this server has never heard of must not lose the rest.
|
|
assert.equal(persistedValue(['playback.video', 'quantum.teleport']), '["playback.video"]');
|
|
});
|
|
|
|
test('a stored declaration overrides the baseline in both directions', () => {
|
|
const stripped = { client_type: 'apk', capabilities: persistedValue(['playback.video']) };
|
|
assert.equal(caps.supports(stripped, 'system.reboot'), false, 'declared set wins over baseline');
|
|
|
|
const hosted = { platform: 'brightsign', capabilities: persistedValue(['system.reboot', 'sync.native']) };
|
|
assert.ok(caps.supports(hosted, 'sync.native'), 'a BrightSign with SyncManager can declare it');
|
|
});
|
|
|
|
test('the round trip is stable — persisted output re-parses to the same set', () => {
|
|
const declared = ['playback.video', 'audio.mute', 'system.reboot'];
|
|
const stored = persistedValue(declared);
|
|
assert.deepEqual(caps.capabilitiesFor({ capabilities: stored }), declared);
|
|
});
|