Repository navigation
Display WYSIWYG Editor
RoomGoblin uses the classroom receiver itself as the preview engine for display-content editing.
A separate generic HTML/Rich Text preview would eventually drift from the physical receiver's font loading, dynamic-object allocation, title single-line fitting, body wrapping, timer geometry, and containment rules. The editor therefore embeds the actual /display/:id?preview=1 receiver and injects local draft state into that iframe.
The preview is not a second renderer.
The Display Studio preview is open by default. Changes to title, subtitle, body text, colors, background, font size, and body alignment are reflected immediately in the embedded receiver.
Nothing is sent to a classroom display until the operator explicitly uses a Send action.
The editor shows:
- the fixed 1920x1080 logical design canvas;
- a reference output resolution such as 1920x1080, 3840x2160, or 1280x720;
- the same fonts and layout engine used on physical receivers;
- the same dynamic object allocation and hard containment behavior.
The Display Text action includes the same embedded receiver preview. Automation variables remain visible as typed in the draft; they are resolved only when the scheduled automation runs.
Editing the preview does not save or enable the automation.
The receiver accepts roomgoblin.preview.state only when all of these are true:
- the receiver is running with
preview=1; - the message origin exactly equals the receiver origin;
- the sender is
window.parent; - the message includes a draft state object.
Normal physical receivers do not install the preview message handler.
Do not send arbitrary operator-authored HTML directly to classroom receivers. That would add a new XSS/sanitization boundary and could make preview behavior differ from the display protocol.
If richer formatting is added later, prefer a structured, bounded formatting model (for example bold/italic/emphasis spans, lists, alignment, and safe colors) or a strict sanitization allowlist. The dynamic receiver layout engine remains the final sizing/containment authority.
Regression coverage must verify that:
- the preview uses the actual receiver page;
- draft messages are same-origin and parent-only;
- editing a draft does not call the physical display command API;
- the receiver still rejects draft messages outside preview mode;
- the same layout revision is used by preview and physical receivers;
- the NOCTI fixture and dense-content fixtures remain contained.
- Home
- Brand and Compatibility
- Operator Workspaces
- Architecture
- TV Routing Matrix
- Installation and Deployment
- Configuration
- Matrix Restoration Validation
- CI Workflows
- Production Publication and Shared Data
- Database-First Recovery Contract
- Host Networking
- Display Access
- Display Layout Contract
- Display Sizing Recovery
- Display Hard Containment
- Managed Display Gateway
- Morning Announcements Diagnostics
- Managed Displays Recovery
- Manual Media Audio
- Media Plane
- Android TV Displays
- Persistent Android ADB
- Android Agent Control Pilot
- Device Agent v2
- Android Agent Artifact Pipeline
- Image Permissions Recovery
- Planning
- Special-Day Schedules
- Automation Display Media
- Veyon and Music Assistant
- Veyon OEM policy
- Music Assistant Sendspin
- Music Assistant TV Audio Recovery
- ESPHome devices — native enrollment, security boundaries, supported controls, and recovery behavior.
- ESPHome discovery — automatic mDNS discovery and adoption of already-flashed devices.
- Operations
- Troubleshooting
- Development
- AI and Contributor Guide
- Security
- Secret URL Handling
- Securly Pass Kiosk
- Windows Lab Agent
- Release and Upgrade Process