You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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).
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.
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.
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.
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.
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.
Zoom level and factor do the same thing but work slightly differently. The level starts at 0 and each increment will increase/decrease the overall zoom by 20%. So a zoom level of 2 would be a total zoom of 140%, -1 would be 80%, etc.
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.
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.
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.
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.
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.
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.
Activity
agracio commentedon Dec 2, 2025
Is there any way to check the minimum supported version of this API or any Electron API for that matter?
AeonSake commentedon Dec 2, 2025
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.
AeonSake commentedon Dec 2, 2025
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 (
webFramewas calledwebViewback then).agracio commentedon Dec 2, 2025
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?
AeonSake commentedon Dec 2, 2025
Personally, I can't say I'm missing any other APIs beside the zoom functions, but maybe the
clearCacheandinsertTextfunctions could also be useful to some? There are also some functions for spell-checker stuff on thewebFrameclass.There are also a lot of other functions in the
webContentsclass that I feel like might be more interesting; especially theundo/redo/copy/cut/etc. functions and the navigation functions.agracio commentedon Dec 2, 2025
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/pastemight be complicated to implement.AeonSake commentedon Dec 2, 2025
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
webContentsclass seem to just provide an interface to native browser controls and content.agracio commentedon Dec 4, 2025
After looking closely at the code it appears we do not have
webFrameclass at all.Will take longer to implement since it would require creation of a new class on both sides.
AeonSake commentedon Dec 4, 2025
Loading Content
webContents.loadFile(filePath: string, options?: {query?: Record<string, string>, search?: string, hash?: string}) : Promise<void>webContents.isLoading() : booleanwebContents.isLoadingMainFrame() : booleanwebContents.isWaitingForResponse() : booleanwebContents.reload() : voidwebContents.reloadIgnoringCache() : voidwebContents.stop() : voidZoom
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
webFrameinstance and I'm not entirely sure, how these interact with each other.webContents.setZoomFactor(factor: double) : voidwebContents.getZoomFactor() : doublewebContents.setZoomLevel(level: number) : voidlevelstarts at 0 and each increment will increase/decrease the overall zoom by 20%. So a zoom level of 2 would be a total zoom of 140%, -1 would be 80%, etc.webContents.getZoomLevel() : numberwebContents.setVisualZoomLevelLimits(minimumLevel: number, maximumLevel: number) : Promise<void>webContents.zoomFactor : double {get,set}webContents.zoomLevel : number {get,set}User Agent
Might be useful for some applications/websites that rely on user agent fingerprinting.
webContents.setUserAgent(userAgent: string) : voidwebContents.getUserAgent() : stringwebContents.userAgent : string {get,set}Dynamic CSS
Allows to manipulate CSS at runtime. All of these methods are also available on the
webFrameinstance.webContents.insertCSS(css: string, options?: {cssOrigin?: string}) : Promise<string>removeInsertedCSS()webContents.removeInsertedCSS(key: string) : Promise<void>Audio
Global audio/mute controls for the entire window.
webContents.setAudioMuted(muted: boolean) : voidwebContents.isAudioMuted() : booleanwebContents.isCurrentlyAudible() : booleanwebContents.audioMuted : boolean {get,set}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.
webContents.undo() : voidwebContents.redo() : voidwebContents.cut() : voidwebContents.copy() : voidwebContents.copyImageAt(x: int, y: int) : voidwebContents.paste() : voidwebContents.pasteAndMatchStyle() : voidwebContents.insertText(text: string) : voidwebContents.replace(text: string) : voidwebContents.replaceMisspelling(text: string) : voidwebContents.selectAll() : voidwebContents.unselect() : voidwebContents.adjustSelection(options: {start?: number, end?: number}) : voidwebContents.centerSelection() : voidwebContents.delete() : voidwebContents.findInPage(text: string, options?: {forward?: boolean, findNext?: boolean, matchCase?: boolean}) : intfound-in-pageevent.webContents.stopFindInPage(action: string) : voidactionmust be one of the following:clearSelection,keepSelection,activateSelectionDev Tools
Additional methods to control dev tools.
webContents.toggleDevTools() : voidwebContents.closeDevTools() : voidwebContents.isDevToolsOpened() : booleanwebContents.isDevToolsFocused() : booleanCache Control
webFrame.clearCache() : voidResource Monitoring
webFrame.getResourceUsage() : {images: {count: number, size: number, liveSize: number}, scripts: {count: number, size: number, liveSize: number}, cssStyleSheets: {count: number, size: number, liveSize: number}, xslStyleSheets: {count: number, size: number, liveSize: number}, fonts: {count: number, size: number, liveSize: number}, other: {count: number, size: number, liveSize: number}}AeonSake commentedon Dec 4, 2025
The zoom API specifically exists on both, the
webFrameandwebContentsinstances. 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 thewebContents-specific methods to the already existingWebContentsclass on the C# side would probably be more than enough.agracio commentedon Dec 4, 2025
Ok so I will be dropping
webFramefor 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.
AeonSake commentedon Dec 4, 2025
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.
agracio commentedon Dec 5, 2025
Some are done and merged to develop #958. I might take a look at more once I have some time.
agracio commentedon Dec 6, 2025
There will be changes to property names to make them async, please hold on before using them in any implementation.
agracio commentedon Dec 6, 2025
Update: all properties will be removed, only methods will remain in code. See discussion in #958
AeonSake commentedon Dec 30, 2025
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.Partitionwhen creating the window. Just thought I'd leave this here if someone else came across a similar issue.agracio commentedon Dec 31, 2025
Does this happen on
Get(),Set()or both?Looking at code
Set()passesIdbutGet()does not, so looks like an error in PR on my part.If both do not work then there is a separate issue.
AeonSake commentedon Dec 31, 2025
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 usewindow.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 withpersist: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
webContentsAPI 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
webFrameinstance will only affect the individual window content/frame, but since there is currently no C# API for thewebFrameinstance, I couldn't really test that further.electron_zoom.mp4
Completed APIs from #956