gh-obsproject/obs-browser

Watch

Fork 0

Unable to distinguish between Dock and Browser Source #455

New issue

Open

opened 2024-09-14 21:27:08 -05:00 by thexeos · 3 comments

thexeos commented

2024-09-14 21:27:08 -05:00

(Migrated from github.com)

Operating System Info

Windows 11

OBS Studio Version

30.2.3

Expected Behavior

It should be possible for the application interacting with JS Bindings to determine if it is running in Dock or in Browser Source.

Current Behavior

Currently, web pages loaded in both OBS Docks and Browser Sources have access to the same APIs and environment, making it difficult to differentiate between the two contexts. This creates limitations for developers who want to provide different functionality depending on whether their web page is loaded as a control panel (Dock) or as visible content (Browser Source).

Steps to Reproduce

Users commonly select a wrong type Dock vs Browser Source or load a URL that is not appropriate for the type.

For example, a webpage with interactive buttons (e.g., scene selection) might be mistakenly loaded as a Browser Source instead of a Dock. The application can't detect this, so it displays the interactive UI. Users may try to interact, but the buttons won't work, leading them to report bugs. In reality, they should have added a Dock, not a Browser Source, causing confusion and poor user experience. Similarly, a non-interactive overlay meant for the stream could be loaded as a Dock, confusing users when it doesn’t appear on the stream.

Having a reliable way to detect the obs-browser environment is the only way these issues can be caught by developers before users create support tickets.

Since there are only two possible states, there could be a boolean isDock value exposed on window.obsstudio object, or alternatively there could be a string enum { 'dock', 'browser_source' } which can be expanded later on.

### Operating System Info Windows 11 ### OBS Studio Version 30.2.3 ### Expected Behavior It should be possible for the application interacting with JS Bindings to determine if it is running in Dock or in Browser Source. ### Current Behavior Currently, web pages loaded in both OBS Docks and Browser Sources have access to the same APIs and environment, making it difficult to differentiate between the two contexts. This creates limitations for developers who want to provide different functionality depending on whether their web page is loaded as a control panel (Dock) or as visible content (Browser Source). ### Steps to Reproduce Users commonly select a wrong type Dock vs Browser Source or load a URL that is not appropriate for the type. For example, a webpage with interactive buttons (e.g., scene selection) might be mistakenly loaded as a Browser Source instead of a Dock. The application can't detect this, so it displays the interactive UI. Users may try to interact, but the buttons won't work, leading them to report bugs. In reality, they should have added a Dock, not a Browser Source, causing confusion and poor user experience. Similarly, a non-interactive overlay meant for the stream could be loaded as a Dock, confusing users when it doesn’t appear on the stream. Having a reliable way to detect the obs-browser environment is the only way these issues can be caught by developers before users create support tickets. Since there are only two possible states, there could be a boolean `isDock` value exposed on `window.obsstudio` object, or alternatively there could be a string enum `{ 'dock', 'browser_source' }` which can be expanded later on.

WizardCM commented

2024-09-14 23:46:32 -05:00

(Migrated from github.com)

Hmm, good catch. I should note, however, that currently most JS bindings don't actually run/return in a dock, as they're not fully implemented there.

thexeos commented

2024-09-15 14:30:35 -05:00

(Migrated from github.com)

That's a good suggestion.

All the methods are present, but none of the getControlLevel, getStatus, getCurrentScene, getScenes, getTransitions, getCurrentTransition would fire when opening the page in Dock.

So that can be considered a workaround:

let isObs = false
let isObsDock = false
if (window.obsstudio) {
  isObs = true
  isObsDock = true
  window.obsstudio.getControlLevel(() => {
    isObsDock = false
  })
}

That's a good suggestion. All the methods are present, but none of the `getControlLevel, getStatus, getCurrentScene, getScenes, getTransitions, getCurrentTransition` would fire when opening the page in Dock. So that can be considered a workaround: ```js let isObs = false let isObsDock = false if (window.obsstudio) { isObs = true isObsDock = true window.obsstudio.getControlLevel(() => { isObsDock = false }) } ```

leon-wbr commented

2025-10-25 13:07:48 -05:00

(Migrated from github.com)

If anyone has trouble with this workaround: It appears that the callback in getControlLevel is asynchronously executed, so when using this to update state (React, etc.), you'll have to make sure to update the state inside the callback.

If anyone has trouble with this workaround: It appears that the callback in `getControlLevel` is asynchronously executed, so when using this to update state (React, etc.), you'll have to make sure to update the state inside the callback.

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

gh-obsproject/obs-browser#455

No description provided.

Rows
Columns