Charles KerrandClaude Opus 5.5
79594d98e6
* test: wait for an active window before sending menu shortcuts On Windows and Linux, views hands accelerators only to the active window (View::CanHandleAccelerators). The setIgnoreMenuShortcuts specs waited for page or DevTools focus, which can be set inside an inactive window, or for no focus at all, so an honored F13 could miss the menu and the spec timed out waiting for it. Focus the window and wait for isFocused() before each press. The CDP keyUp's answer is what orders the count after the keyDown's menu dispatch: the widget acks the events in order, and the browser offers an unhandled keyDown to the menu while it handles that ack. This only holds when both events reach the same widget, but the keyDown went through sendInputEvent to the main widget, while CDP targets the focused frame. Send the keyDown through CDP as well, with a native key code so that it isn't marked skip_if_unhandled. Read the count as soon as the keyUp is answered instead of polling for it, and wait for the webview guest to have focus. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test: keep menu shortcut windows visible and active The browser doesn't offer keys from a hidden widget to the menu (RenderWidgetHostImpl::OnKeyboardEventAck checks IsHidden()). On Windows, native occlusion marks a covered window hidden and shows it again only after a timer and a posted task, so a press sent right after window.focus() raises a covered window could be dropped. Keep the shown windows always on top on Windows, as the visibility specs do, and wait for the page to report that it is visible before each press. On macOS, window.focus() activates the app only when no other app is frontmost, so the isFocused() wait could time out. Take activation with app.focus({ steal: true }) first, as the webview specs do. Also correct the comment on the native key code: off macOS, any non-zero code works. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test: simplify the menu shortcut specs The webview spec activated the window before each press, and then sendShortcut() activated it again under a different condition. Focus the guest inside sendShortcut() instead, once the window is active, so activation happens in one place. Set the Windows alwaysOnTop option from one describe-level const, next to the reason for it. The docked DevTools spec waited for devtools-focused and passed activate: true, which is the default and which docked DevTools ignore. Neither the CDP target nor the menu depends on DevTools focus, and sendShortcut() already waits for an active window and a visible page before each press, so drop both. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
📝 Available Translations: 🇨🇳 🇧🇷 🇪🇸 🇯🇵 🇷🇺 🇫🇷 🇺🇸 🇩🇪. View these docs in other languages on our Crowdin project.
The Electron framework lets you write cross-platform desktop applications using JavaScript, HTML and CSS. It is based on Node.js and Chromium and is used by the Visual Studio Code and many other apps.
Follow @electronjs on Twitter for important announcements.
This project adheres to the Contributor Covenant code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to coc@electronjs.org.
Installation
To install prebuilt Electron binaries, use npm.
The preferred method is to install Electron as a development dependency in your
app:
npm install electron --save-dev
For more installation options and troubleshooting tips, see installation. For info on how to manage Electron versions in your apps, see Electron versioning.
Platform support
Each Electron release provides binaries for macOS, Windows, and Linux.
- macOS (Ventura and up): Electron provides 64-bit Intel and Apple Silicon / ARM binaries for macOS.
- Windows (Windows 10 and up): Electron provides
x64(amd64) andarm64binaries for Windows. - Linux: Electron provides
x64(amd64) andarm64binaries for Linux. Electron supports major Linux distributions (e.g., Ubuntu, Fedora, Debian) in versions that are still supported by both Chromium and the distro maker (without requiring a paid subscription). The prebuilt binaries are built on Ubuntu.
In general, Electron tries to align with Chromium on platform support.
Electron Fiddle
Use Electron Fiddle
to build, run, and package small Electron experiments, to see code examples for all of Electron's APIs, and
to try out different versions of Electron. It's designed to make the start of your journey with
Electron easier.
Resources for learning Electron
- electronjs.org/docs - All of Electron's documentation
- electron/fiddle - A tool to build, run, and package small Electron experiments
Programmatic usage
Most people use Electron from the command line, but if you require electron inside
your Node app (not your Electron app) it will return the file path to the
binary. Use this to spawn Electron from Node scripts:
const electron = require('electron')
const proc = require('node:child_process')
// will print something similar to /Users/maf/.../Electron
console.log(electron)
// spawn Electron
const child = proc.spawn(electron)
Mirrors
See the Advanced Installation Instructions to learn how to use a custom mirror.
Documentation translations
We crowdsource translations for our documentation via Crowdin. We currently accept translations for Chinese (Simplified), French, German, Japanese, Portuguese, Russian, and Spanish.
Contributing
If you are interested in reporting/fixing issues and contributing directly to the code base, please see CONTRIBUTING.md for more information on what we're looking for and how to get started.
Community
Info on reporting bugs, getting help, finding third-party tools and sample apps, and more can be found on the Community page.
License
When using Electron logos, make sure to follow OpenJS Foundation Trademark Policy.