Zoom applied to docks also affects browser sources

P

Peter Sanders

New Member
OBS applies zoom levels per domain instead of per browser instance. This causes an issue when using a dock and a browser source that load content from the same domain.

Steps to Reproduce:
  1. Add a custom dock in OBS Studio with the following URL:

    OBS Studio Gets A New Renderer | OBS

    Starting with OBS Studio 32.0.0 a new renderer backend based on Apple's Metal graphics API is available for users to test as an experimental alternative to the existing OpenGL …
    obsproject.com obsproject.com
  2. Add a browser source to a scene using the this URL:

    OBS Studio 32.0 Release Notes | OBS

    New Features Added a basic plugin manager [FiniteSingularity/PatTheMav/Warchamp7] Added opt-in automatic crash log upload for Windows and macOS [PatTheMav/Warchamp7] Added Voice …
    obsproject.com obsproject.com
  3. Adjust the zoom level in the dock.
  4. Observe the browser source in the program output.
  5. The zoom level doesn't affect docks and browser sources using a URL with a different domain

Expected Behavior:
Zoom changes in the dock should not affect the browser source. Each instance should maintain its own zoom level.

Actual Behavior:
Changing the zoom level in the dock also changes the zoom level of the browser source, since both are loaded from the same domain (obsproject.com).

Additional Notes:
I originally encountered this issue while using overlays from overlays.uno.

In that setup, the URLs follow this pattern:
Both URLs share the same domain (app.overlays.uno), which causes the zoom level of the control UI (dock) to also affect the output rendered in the browser source.

Impact:
Very High – adjusting zoom in a dock unintentionally affects visible content in the live output, which is especially problematic in production environments.
 
This is how all modern browsers handle zoom settings.

If you need access to a control panel of some sort at an increased zoom level, I would suggest using it from within an actual browser rather than as a browser dock.
 
Thanks for the clarification.

I understand that modern browsers often apply zoom per domain. However, in OBS Studio this behavior becomes problematic because docks and browser sources are not just “tabs”. They serve fundamentally different purposes:
  • Docks are typically used for control UIs (operator interfaces)
  • Browser sources are part of the actual program output (what gets streamed)
Because of this, changing the zoom level in a dock can unintentionally affect the live output, which is not expected behavior in a production environment.

In a normal browser, all tabs are part of the same user-facing context, so shared zoom makes sense. In OBS, however, docks and browser sources act more like independent rendering contexts.

Ideally, zoom should be applied per instance (or at least docks vs. browser sources separately), so adjusting a control UI does not impact the rendered output.

Using an external browser for control UIs is a workaround, but it’s not always practical in live production setups where integrated docks are preferred.


You can see the effect for yourself by using these two URLs in OBS:
Place a video in the background and the browser source full screen on top. Then dock the control URL and zoom out several steps. The browser source will also scale, affecting the output.
 
While I can understand the expectation here, since this is core to modern browsing paradigms, it's unlikely that there will be anything we can do about it. These settings are not applied on a per-tab basis, they are applied globally to all instances; same as a browser does.
 
Thanks for the explanation, I understand that this behavior is aligned with how modern browsers handle zoom and that it may not be trivial to change.

That said, in OBS Studio this has a much bigger impact than in a typical browser environment. Docks and browser sources serve very different roles, especially in live production workflows.

For overlays.uno users, this effectively makes browser docks risky to use. We currently recommend docks for control UIs, but if a user adjusts the zoom in a dock and unintentionally changes the scale of a browser source in the live output, it has serious on-air consequences.

Because of this, we will likely need to advise our users not to use OBS docks for control interfaces, which is unfortunate since it’s otherwise a very useful feature.

Even if a full change is not feasible, it might be worth considering whether some form of isolation between docks and browser sources (or an option to disable shared zoom behavior) could be possible in the future.
 
This is something I've ran into as well, while trying to zoom out the Dock for an UNO Overlay Control page in order to get more real estate to work with, which additionally zoomed out a Browser source containing the same domain.

Custom browser docks in OBS are very convenient, but this issue can completely break the way an overlay will appear on screen, which is especially not great if the dock's zoom is modified during live production.
It would be great to have browser docks and browser sources render independent from each other, regardless of the domain.
 
I have run into this issue too while trying to zoom out the Dock so I could have more workspace. When I did that, the Browser Source using the same domain was also zoomed out.

Custom browser docks in OBS are extremely useful, but this behavior can completely disrupt how an overlay is displayed on screen. That becomes even more concerning if the dock zoom is adjusted during a live production.
 
Yes, this is a serious issue, making it nearly impossible using browser docks in OBS for productions at all!
We use a second monitor for the UNO control app, if the space at the production loation is available.

Unfortunaltely, we upgraded to the version 32. We haven't seen this issue before.
I hope this issue gets addressed soon! :-)
 
You must log in or register to reply here.
Back
Top