Skip to content

Window Zoom Controls #956

Closed
Closed

Description

@AeonSake

Is there currently any way to programmatically set/get the zoom level/factor of a window? I believe the electron side exposes a zoom API on the webFrame, but the BrowserWindow and WebContents classes currently don't provide any possibility to use it.

I understand that this might not be a very urgent feature, but it would be great to have nonetheless. Likewise, I would also gladly accept any alternative solution to get this to work.

Activity

  1. agracio commented on Dec 2, 2025

    @agracio
    Contributor

    Is there any way to check the minimum supported version of this API or any Electron API for that matter?

  2. AeonSake commented on Dec 2, 2025

    @AeonSake
    ContributorAuthor

    Good question; I don't think so? At least not directly. I would need to check the git history, but the zoom API has been part of electron since basically forever.

  3. AeonSake commented on Dec 2, 2025

    @AeonSake
    ContributorAuthor

    Checking the electron GitHub history, it looks like the zoom API has been part of the shell since the start. The oldest entry I could find was with the creation of the initial documentation more than 11 years ago (webFrame was called webView back then).

  4. agracio commented on Dec 2, 2025

    @agracio
    Contributor

    I can take a look at it later unless someone already picked that up.
    Are there any other known APIs that are either needed or nice to have?

  5. AeonSake commented on Dec 2, 2025

    @AeonSake
    ContributorAuthor

    Personally, I can't say I'm missing any other APIs beside the zoom functions, but maybe the clearCache and insertText functions could also be useful to some? There are also some functions for spell-checker stuff on the webFrame class.

    There are also a lot of other functions in the webContents class that I feel like might be more interesting; especially the undo/redo/copy/cut/etc. functions and the navigation functions.

  6. agracio commented on Dec 2, 2025

    @agracio
    Contributor

    Would be great to have more APIs to finish at the same time, I will check for a few more and will get a PR ready in a day or two at most.
    If you can compile a list of some APIs with links that would be a great start, cannot promise that all will be done but will start with some low hanging fruits first.

    But undo/redo/cut/copy/paste might be complicated to implement.

  7. AeonSake commented on Dec 2, 2025

    @AeonSake
    ContributorAuthor

    Sure, I can compile you a list of all (relevant) functions with links. Priority is up to you, though, as I personally care mainly for the zoom API. Regarding the clipboard functions, as far as I understood it, those are just the browser-control calls which should then correctly map back to the clipboard API. Most functions on the webContents class seem to just provide an interface to native browser controls and content.

  8. agracio commented on Dec 4, 2025

    @agracio
    Contributor

    After looking closely at the code it appears we do not have webFrame class at all.
    Will take longer to implement since it would require creation of a new class on both sides.

  9. AeonSake commented on Dec 4, 2025

    @AeonSake
    ContributorAuthor

    Loading Content

    Zoom

    API for window zoom factor and limits. Changes the underlying rendering zoom, not the CSS styling zoom. Zoom factor of 1.0 = 100% (default). All of these methods are also available on the webFrame instance and I'm not entirely sure, how these interact with each other.

    User Agent

    Might be useful for some applications/websites that rely on user agent fingerprinting.

    Dynamic CSS

    Allows to manipulate CSS at runtime. All of these methods are also available on the webFrame instance.

    Audio

    Global audio/mute controls for the entire window.

    Edit / Select

    Access to the (usually browser) controls for the edit history and text selection. All copy/paste operations are executed with the clipboard API.

    Dev Tools

    Additional methods to control dev tools.

    Cache Control

    Resource Monitoring

  10. AeonSake commented on Dec 4, 2025

    @AeonSake
    ContributorAuthor

    After looking closely at the code it appears we do not have webFrame class at all. Will take longer to implement since it would require creation of a new class on both sides.

    The zoom API specifically exists on both, the webFrame and webContents instances. However, I'm not sure how they actually affect each other (i.e., is the zoom synchronized or inherited?). For now, I would say adding the webContents-specific methods to the already existing WebContents class on the C# side would probably be more than enough.

  11. agracio commented on Dec 4, 2025

    @agracio
    Contributor

    Ok so I will be dropping webFrame for now. As for all the methods you mentioned I will implement some but definitely not all.
    Would be great if everyone else had a look at this list and gave some feedback.

  12. AeonSake commented on Dec 4, 2025

    @AeonSake
    ContributorAuthor

    Yea, I feel like a lot of these methods are quite niche. I just tried to document most potentially relevant methods. Though personally, I would probably only add the zoom, the audio/mute, and maybe the dev tools and user agent stuff because they seem to be rather trivial for the implementation but still provide decent benefit for the user.

  13. agracio commented on Dec 5, 2025

    @agracio
    Contributor

    Some are done and merged to develop #958. I might take a look at more once I have some time.

  14. agracio commented on Dec 6, 2025

    @agracio
    Contributor

    There will be changes to property names to make them async, please hold on before using them in any implementation.

  15. agracio commented on Dec 6, 2025

    @agracio
    Contributor

    Update: all properties will be removed, only methods will remain in code. See discussion in #958

  16. added this to the 1.0.0 milestone on Dec 9, 2025
  17. AeonSake commented on Dec 30, 2025

    @AeonSake
    ContributorAuthor

    Not a bug (probably a feature) but caught me be my surprise: zoom factor is shared across all windows by default. There might also be other shared properties (e.g., clipboard, audio, etc.), but zoom factor is what I noticed first. To mitigate this, the easiest way I found is to ensure each window has a unique partition name set under BrowserWindowOptions.WebPreferences.Partition when creating the window. Just thought I'd leave this here if someone else came across a similar issue.

  18. agracio commented on Dec 31, 2025

    @agracio
    Contributor

    Does this happen on Get(), Set() or both?
    Looking at code Set() passes Id but Get() does not, so looks like an error in PR on my part.
    If both do not work then there is a separate issue.

  19. AeonSake commented on Dec 31, 2025

    @AeonSake
    ContributorAuthor

    Does this happen on Get(), Set() or both? Looking at code Set() passes Id but Get() does not, so looks like an error in PR on my part. If both do not work then there is a separate issue.

    To be fair, I haven't used the Get() method(s) at all since in my case, the zoom controls are entirely handled on the C# side. I only use window.WebContents.SetZoomFactor(value) to apply a zoom factor. In the video below, you can see how this propagates through all open Electron windows. Furthermore, if using the default partition name (i.e., not setting it), the zoom factor is also persisted, which I also didn't expect (usually, only partitions prefixed with persist: should be persisted). I didn't try to forcefully set a zoom factor when creating the window, though.
    At the end of the video, you can see how it works as intended when selecting unique partition names. I still believe this is intended design by Electron itself since shared partitions are meant to also share data between windows (cache, local storage, etc.) and I assume it also includes parts of the window config space. I have not tested other parts of the webContents API for what all is shared across windows, though. Dev-Tools for one is unique to the individual window at least.

    I have also read that changing the zoom factor of the webFrame instance will only affect the individual window content/frame, but since there is currently no C# API for the webFrame instance, I couldn't really test that further.

    electron_zoom.mp4
  20. modified the milestones: 1.0.0, 0.6.0 on Sep 4, 2026
  21. added a commit that references this issue on Sep 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions