Fix browser-source viewport scaling and test alert reliability #124

Closed
opened 2026-07-08 11:43:46 -05:00 by Gitchegumi · 1 comment
Gitchegumi commented 2026-07-08 11:43:46 -05:00 (Migrated from github.com)

Summary

Fix the alert browser-source rendering path so the browser source shows the same stage composition as the editor canvas, scales predictably to the viewport, and reliably triggers all alert media even when multiple browser-source views are open.

Problems observed

1. Browser source cuts off the editor stage canvas

The alert appears correctly centered and fully visible in the editor stage, but the browser-source view can crop or push part of the composition outside the visible viewport. The stage canvas and browser-source viewport should represent the same alert output.

The browser source should not show a different effective crop than the editor stage.

2. Browser source does not scale down to non-matching window sizes

If a user opens the browser-source URL in a normal browser window that is not exactly the same dimensions as the configured canvas, the alert should resize itself to fit within the available viewport width while preserving aspect ratio.

Example: a 1920x1080 canvas opened in a browser window that is narrower than 1920px should fit inside the window instead of clipping horizontally or vertically.

3. Image and audio intermittently fail during test alerts with multiple browser sources open

Intermittently, image and audio assets do not trigger when running a test alert. This appears more likely when an OBS browser source and a regular browser window are both open to the browser-source URL at the same time.

The number of connected browser-source clients should not affect whether a test alert triggers. When an alert is triggered, every connected browser source should receive and play the same alert event independently.

4. Test alerts use static placeholder values

The test alert message currently uses static test values. Test alerts should use randomized viewer names and randomized tip amounts so variable substitution can be visually validated with realistic variation.

Desired behavior

  • The editor stage canvas and browser-source output should match in layout, positioning, and visible bounds.
  • The browser-source output should preserve the configured canvas aspect ratio.
  • The browser-source output should scale to fit within the viewport when the browser window is smaller or not the exact configured canvas size.
  • No part of the configured stage should be cropped unless the user intentionally places content outside the stage bounds.
  • Alert events should be broadcast to every active browser-source client.
  • Multiple open browser-source clients should not consume, steal, cancel, or interfere with the same alert event.
  • Image, text, and audio layers should trigger consistently on every connected browser-source client.
  • Test alerts should generate randomized sample data for supported variables, including viewer name and tip amount.

Acceptance criteria

  • A browser source with a 1920x1080 canvas shows the same composition visible in the editor stage.
  • Opening the browser-source URL in a browser window smaller than the canvas scales the alert down to fit the viewport width while preserving aspect ratio.
  • Opening the browser-source URL in a browser window larger than the canvas does not distort the alert.
  • Browser-source rendering does not crop the stage unexpectedly.
  • Running a test alert while one OBS browser source is open triggers image, text, and audio layers.
  • Running a test alert while OBS and one or more regular browser windows are open triggers image, text, and audio layers in every connected client.
  • Alert delivery is broadcast-style, not single-consumer behavior.
  • Test alerts use a randomized viewer name.
  • Test alerts use a randomized tip amount.
  • Variable substitution continues to work for existing alert templates.

Implementation notes

The browser-source page should likely render the configured canvas inside a responsive wrapper. The inner stage should keep the configured logical dimensions, then scale via a calculated transform or equivalent CSS so the full stage fits inside the available viewport.

For test alert delivery, confirm that the event dispatch mechanism broadcasts to all connected overlay clients instead of treating the alert as a queue item consumed by the first active client. Each connected client should receive its own copy of the event payload and handle playback locally.

For randomized test data, the test payload should vary values like viewer name and tip amount on each test run so users can verify text variables and layout behavior with changing content.

## Summary Fix the alert browser-source rendering path so the browser source shows the same stage composition as the editor canvas, scales predictably to the viewport, and reliably triggers all alert media even when multiple browser-source views are open. ## Problems observed ### 1. Browser source cuts off the editor stage canvas The alert appears correctly centered and fully visible in the editor stage, but the browser-source view can crop or push part of the composition outside the visible viewport. The stage canvas and browser-source viewport should represent the same alert output. The browser source should not show a different effective crop than the editor stage. ### 2. Browser source does not scale down to non-matching window sizes If a user opens the browser-source URL in a normal browser window that is not exactly the same dimensions as the configured canvas, the alert should resize itself to fit within the available viewport width while preserving aspect ratio. Example: a 1920x1080 canvas opened in a browser window that is narrower than 1920px should fit inside the window instead of clipping horizontally or vertically. ### 3. Image and audio intermittently fail during test alerts with multiple browser sources open Intermittently, image and audio assets do not trigger when running a test alert. This appears more likely when an OBS browser source and a regular browser window are both open to the browser-source URL at the same time. The number of connected browser-source clients should not affect whether a test alert triggers. When an alert is triggered, every connected browser source should receive and play the same alert event independently. ### 4. Test alerts use static placeholder values The test alert message currently uses static test values. Test alerts should use randomized viewer names and randomized tip amounts so variable substitution can be visually validated with realistic variation. ## Desired behavior - The editor stage canvas and browser-source output should match in layout, positioning, and visible bounds. - The browser-source output should preserve the configured canvas aspect ratio. - The browser-source output should scale to fit within the viewport when the browser window is smaller or not the exact configured canvas size. - No part of the configured stage should be cropped unless the user intentionally places content outside the stage bounds. - Alert events should be broadcast to every active browser-source client. - Multiple open browser-source clients should not consume, steal, cancel, or interfere with the same alert event. - Image, text, and audio layers should trigger consistently on every connected browser-source client. - Test alerts should generate randomized sample data for supported variables, including viewer name and tip amount. ## Acceptance criteria - [ ] A browser source with a 1920x1080 canvas shows the same composition visible in the editor stage. - [ ] Opening the browser-source URL in a browser window smaller than the canvas scales the alert down to fit the viewport width while preserving aspect ratio. - [ ] Opening the browser-source URL in a browser window larger than the canvas does not distort the alert. - [ ] Browser-source rendering does not crop the stage unexpectedly. - [ ] Running a test alert while one OBS browser source is open triggers image, text, and audio layers. - [ ] Running a test alert while OBS and one or more regular browser windows are open triggers image, text, and audio layers in every connected client. - [ ] Alert delivery is broadcast-style, not single-consumer behavior. - [ ] Test alerts use a randomized viewer name. - [ ] Test alerts use a randomized tip amount. - [ ] Variable substitution continues to work for existing alert templates. ## Implementation notes The browser-source page should likely render the configured canvas inside a responsive wrapper. The inner stage should keep the configured logical dimensions, then scale via a calculated transform or equivalent CSS so the full stage fits inside the available viewport. For test alert delivery, confirm that the event dispatch mechanism broadcasts to all connected overlay clients instead of treating the alert as a queue item consumed by the first active client. Each connected client should receive its own copy of the event payload and handle playback locally. For randomized test data, the test payload should vary values like viewer name and tip amount on each test run so users can verify text variables and layout behavior with changing content.
Gitchegumi commented 2026-07-08 16:56:16 -05:00 (Migrated from github.com)

fixed with #125

fixed with #125
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gitchegumi/GitchAlerts#124
No description provided.