Electron 43 has been released! It includes upgrades to Chromium 150.0.7871.46, V8 15.0, and Node v24.17.0.

---

The Electron team is excited to announce the release of Electron 43! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Improved app startup performance​

Electron 43 ships several improvements to app startup performance. The main process now boots from an embedded Node.js startup snapshot, framework bundles and preload scripts are cached as compiled V8 bytecode, and sandboxed renderer startup data is pushed ahead of navigation instead of fetched via blocking IPC. As a bonus, preload stack traces now show the correct file path and line number. #51792

Frameless windows on Linux now have rounded corners by default​

On Linux, frameless windows now have rounded corners by default, matching the behavior on macOS and Windows. Rounded corners can be disabled on all platforms by setting roundedCorners: false on the window. #52111

File downloads now open in the Downloads folder by default​

File downloads will now open by default in the user's Downloads folder (or the Home directory if Downloads doesn't exist). #49868

New macOS Notification management APIs​

Electron 43 adds Notification.remove(), Notification.removeAll(), and Notification.removeGroup() static methods on macOS, giving developers finer control over delivered notifications. Combined with the existing Notification.getHistory() API, you can now fully manage the lifecycle of notifications in Notification Center. #51690

Stack Changes​

• Chromium 150.0.7871.46

  • New in 150
  • New in 149

• Node v24.17.0

  • Node 24.17.0 blog post

• V8 15.0

Electron 43 upgrades Chromium from 148.0.7778.96 to 150.0.7871.46, Node.js from v24.15.0 to v24.17.0, and V8 from 14.8 to 15.0.

New Features and Improvements​

• Added Clone method to WebContents. #49959
• Added JS stack trace to crash reports on renderer OOM. #50043
• Added Linux support for app.getApplicationInfoForProtocol(). #51297
• Added Notification.remove(), Notification.removeAll(), and Notification.removeGroup() static methods for macOS. #51690
• Added Notification.getHistory() for macOS, allowing developers to restore all delivered notifications still present in Notification Center. #50325
• Added accessibilityLabel property to MenuItem constructor options and properties for defining screen-reader-friendly labels. #50240
• Added allowExtensions privilege to protocol.registerSchemesAsPrivileged() to enable Chrome extensions on custom protocols. #49951
• Added app.configureWebAuthn() to enable the Touch ID platform authenticator for WebAuthn on macOS, and a select-webauthn-account session event for choosing between multiple discoverable credentials. #51255
• Added globalShortcut.setSuspended() and globalShortcut.isSuspended() methods to temporarily suspend and resume global shortcut handling. #50425
• Added id and groupId options to the Notification constructor on macOS. id allows custom identifiers for notifications, and groupId visually groups notifications together in Notification Center. #50097
• Added id, groupId, and groupTitle support for Windows notifications. #50328
• Added nativeTheme.shouldDifferentiateWithoutColor on macOS. #49912
• Added nv12 OSR pixel format support for professional use. #49799
• Added view.setBackgroundBlur(). #51076
• Added webContents.copyVideoFrameAt(x, y) and webContents.saveVideoFrameAs(x, y) methods. #48149
• Added session support to net module requests from the utility process. #51279
• Added support for heap profiling via contentTracing.enableHeapProfiling(). #50826
• Added support for importing shared textures using the nv16 pixel format. #50728
• Added support for the urgency option in Notifications on Windows. #50225
• Added support for using a proxy during yarn install. #50322
• Allowed the --experimental-inspector-network-resource Node.js flag to be passed through Electron. #49689
• Enabled ThinLTO on macOS builds. #51819
• Enabled profile-guided optimization for V8 builtins in release builds, improving JavaScript builtin performance (Array, String, RegExp, etc.). #50416
• Improved app startup performance — the main process now boots from an embedded Node.js startup snapshot, framework bundles and preload scripts are cached as compiled V8 bytecode, and sandboxed renderer startup data is pushed ahead of navigation instead of fetched via blocking IPC. #51792
• Improved performance of Linux and Windows release builds by enabling ThinLTO link-time optimization for the main Electron binary. #51820
• Improved performance of app.getApplicationNameForProtocol() on Linux. #51251
• Improved performance of app.isDefaultProtocolClient() and app.setAsDefaultProtocolClient() on Linux. #51316
• Improved performance of webRequest header conversions and several other gin converter hot paths. #51608
• Improved performance of native event emission, IPC dispatch, and option-dictionary parsing. #51615

Breaking Changes​

Behavior Changed: File downloads now open in the Downloads folder​

File downloads will now open by default in the user's Downloads folder (or the Home directory if the Downloads folder doesn't exist). #49868

Behavior Changed: nativeImage pixel values are normalized to SRGB​

If a nativeImage was passed an image with a color profile, its pixel values will now be normalized to SRGB. This ensures that two visually identical images after color space application will receive similar pixel values when converted to a nativeImage. #51565

Behavior Changed: Frameless windows have rounded corners on Linux by default​

On Linux, frameless windows now have rounded corners by default, matching the behavior on macOS and Windows. Rounded corners can be disabled on all platforms by setting roundedCorners: false on the window. #52111

Behavior Changed: WCO respects the native title bar layout on Linux​

Frameless windows with Window Controls Overlay (WCO) now adopt the native title bar layout and user settings on Linux. For example, controls will appear on the left side of the frame on RTL systems, and only the close button will be visible by default on GNOME. Depending on the user's desktop environment and configuration, buttons can appear on the left or right side of the frame (or both). To account for all possibilities, use the CSS variables env(titlebar-area-x, 0px) and env(titlebar-area-width, 100%) to constrain your app's title bar content to a safe area. #52018

Behavior Changed: chrome.scripting CSS injection matches more fallback frames​

Extensions using chrome.scripting.insertCSS() or chrome.scripting.removeCSS() now follow Chrome's behavior when Electron cannot match a frame's URL directly, such as with about:blank or data: frames. If the extension has access to the page that created the frame, CSS may now be inserted into or removed from those fallback frames as well. Apps or extensions that relied on Electron skipping those frames should narrow their injection target, frame IDs, or match patterns. #51376

Removed: showHiddenFiles from dialog API on Linux​

showHiddenFiles support has been removed from the dialog API on Linux. #51880

End of Support for 40.x.y​

Electron 40.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron. See https://releases.electronjs.org/schedule to see the timeline for supported versions of Electron.

Support for 32-bit platforms ending​

Electron 43.x.y will be the last version series of Electron to ship with prebuilt binaries for 32-bit platforms: Windows x86 (win32-ia32) and Linux ARM (linux-armv7l). Once the v43 series reaches end of life in January 2027, these 32-bit platforms will no longer be supported.

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8.

You can find Electron's public timeline here.

More information about future changes can be found on the Planned Breaking Changes page.

I spent some time this week walking the entire Linux Foundation umbrella to inventory the API specifications it stewards, and the projects underneath it that actually have APIs. I expected a long, messy list. What I did not expect was how clearly one fact would jump out at me once it was all written down in a single place: the Linux Foundation has quietly become the neutral home of the world’s open API specification standards. Not most of them. Almost all of them.

When I pulled the specifications into one table, the picture was hard to argue with. OpenAPI lives there, under the OpenAPI Initiative, and it has quietly grown into a family—OpenAPI itself, plus the Arazzo workflow specification and the Overlay specification. AsyncAPI is there for our event-driven and message-based APIs. GraphQL is there. JSON Schema is there, hosted at the OpenJS Foundation. gRPC and the Protocol Buffers it leans on are there through CNCF. CloudEvents, the OpenTelemetry protocol, OpenMetrics, and the xDS data-plane API are all there too. And that is before you get to the identity and supply-chain formats sitting right alongside them—SPIFFE, OpenFeature, SPDX, the OCI image, runtime, and distribution specs, in-toto, OSV, SLSA, TUF, Notary, and Sigstore.

That is the contract layer for REST, event-driven, RPC, and GraphQL APIs—all governed under one foundation. I have been doing this for sixteen years and I am not sure I had ever stopped to notice that the descriptions we use to define how software talks to software had all drifted into the same harbor.

JSON Schema Is the Connective Tissue

The deeper I looked, the more one thread kept showing up underneath everything else: JSON Schema. OpenAPI uses it. Arazzo and Overlay use it. AsyncAPI uses it. CloudEvents ships a JSON Schema. OSV and SPDX lean on it. The OpenAPI metaschema is JSON Schema. GraphQL is the notable outlier with its own grammar, but for most of the rest of the catalog, JSON Schema is the substrate the other specifications are built on top of.

So we have a situation where a single foundation governs the major API description formats, and most of those formats quietly share a common foundation underneath them. That is not a coincidence anymore. That is an opportunity that nobody is fully reaching for.

The Specifications Are Neighbors That Do Not Talk

Here is the part that bugs me. These specifications all live in the same house, and they barely talk to each other. Each one is its own initiative, its own working group, its own community, its own release cadence, its own tooling ecosystem, its own registry of extensions, its own way of expressing the same handful of ideas—operations, schemas, parameters, servers, security, tags, versions, references.

I have done the exercise before of exploding the properties across interface specifications and watching the same concepts surface again and again under slightly different names. The overlap is real, and it is large. A parameter in OpenAPI, a field in a CloudEvent, a property in a JSON Schema, a message member in AsyncAPI—these are cousins, and we keep redefining them in isolation. Every specification reinvents how it points at a thing, references another thing, attaches metadata to a thing, and versions a thing. We have a dozen vocabularies for a shared set of nouns.

That fragmentation costs us. It costs tooling authors, who rebuild the same validators, linters, mockers, and code generators once per specification. It costs the people doing governance, who have to learn each format’s idioms separately. And it costs the everyday developer, who has to hold all of these mental models at once just to describe a single system that speaks more than one protocol.

The Opportunity Is Sitting Right There

Because all of these specifications already share a roof, the hard part—neutral, vendor-independent governance with a real IP framework and a path to ISO ratification—is already solved. What is missing is the connective work between them.

I keep coming back to a few concrete things these projects could be sharing:

• A common vocabulary for the properties they all express. Schemas, references, servers, security, parameters, tags, and versions show up everywhere. A shared map of these overlapping concepts would let each specification stay itself while making it obvious where they align.
• Shared registries and shared tooling. Extension registries, format registries, and the validators and linters that read these specs are rebuilt over and over. There is no reason a CloudEvent’s schema, an AsyncAPI message, and an OpenAPI body could not lean on the same JSON Schema tooling and the same registry patterns.
• Cross-specification references that actually resolve. An Arazzo workflow already points across OpenAPI documents. AsyncAPI and OpenAPI describe two halves of the same system. These cross-references should be first-class and consistent, not bolted on per project.
• Coordinated governance and a shared discovery surface. If these specifications are going to live together, they should be discoverable together, documented against each other, and governed with at least an awareness of each other’s roadmaps.

None of this requires merging the specifications. I do not want one specification to rule them all, and I do not think anyone seriously does. The strength of this ecosystem is that OpenAPI, AsyncAPI, GraphQL, and the rest each do their job well. What I want is for these neighbors to share information and coordinate—to treat the fact that they share a foundation as a feature, not an accident.

Why I Care About This

This matters to me because I spend my days trying to describe real systems, and real systems do not respect specification boundaries. A single platform has REST endpoints, events, schemas, an RPC surface, telemetry, and an SBOM. I have to reach for half a dozen of these specifications at once to describe it honestly, and right now that means stitching together half a dozen disconnected worlds by hand.

The Linux Foundation has already done the heavy lifting of gathering our API specifications into one neutral place. The next move—and I think it is a big one—is to get those specifications sharing what they know and working together. I am going to keep pulling on this thread, because the inventory I built this week makes me think the pieces for something much more coordinated are already sitting on the same shelf, just waiting for someone to wire them together. If you are thinking about this too, reach out at kinlane@apievangelist.com.

The Trump administration has lifted export restrictions that forced Anthropic to shut off public access to its Mythos and Fable models. After weeks of talks, Secretary of Commerce Howard Lutnick said Anthropic "has agreed to proactively detect and address security risks associated with the models; to work diligently with the U.S. government on protocols and standards and releases for Mythos, Fable and future models; and to inform the US government of any malicious activity." Access is set to begin returning July 1. TechCrunch reports: Anthropic had already publicly pledged to do much of this voluntarily, months before the export rule existed. That's part of why cybersecurity experts were skeptical of the restrictions in the first place. To them, the ban looked less like a security fix and more like leverage, a way for the Trump administration to punish Anthropic for its executives' public criticism of how the government, and the president's political opponents, might use the technology. Mythos was originally made available to a select group of organizations beginning in April to allay concerns about its ability to identify and exploit vulnerabilities in software, while a version called Fable was released to the public in June with additional security guardrails. However, with Asian AI companies beginning to release their own AI models approaching Mythos-level capabilities -- among them Fugu and Tulonfeng -- the US government was under pressure to ease its restrictions on Anthropic to ensure that American AI could compete globally. Last week, Lutnick cleared Mythos to be released to select customers approved by the White House. OpenAI's latest models were also released to a group of organizations approved by the Trump team, instead of the public. The Trump administration's erratic approach to AI policymaking has left companies across the industry with little clarity about what will govern future model releases. An executive order issued in June that signaled a desire to review models ahead of release was criticized by influential analysts like Dean W. Ball, who recently started a policy position at OpenAI.

Read more of this story at Slashdot.

I have a love-and-hate relationship with New Outlook. I like how simple the interface is, but dislike the fact that many of the advanced features are still missing. And it’s not just about Windows, as even New Outlook for macOS has a similar problem. The good news is Microsoft is bridging the gap and rolling out support for advanced .PST and other features.

In a couple of posts on Microsoft’s Feedback portal for Outlook, the company confirmed that it has now fully released an advanced version of .PST support in New Outlook. It also shared a support document that explains how the feature works in Outlook, but warned that Classic Outlook is still required to be installed in the background.

“Opening .pst files in new Outlook requires classic Outlook to also be installed. Both versions need to be the same architecture: 32-bit (x86) or 64-bit (x64),” Microsoft noted in a document.

.PST file support for New Outlook rolled out a little while ago, but at that time, it was basic and lacked multiple features. For example, if you imported a .PST file from a different account, you couldn’t search for emails by either content or sender in a folder that you had just created.

This has been addressed, and you can now follow these steps to use .PST files in New Outlook:

• Open Settings in New Outlook, and navigate to Data files.
• Now, select “Add files.”
  
• Pick your PST file, and open it in your folder list.

I’ve been following Outlook’s .PST journey for a while now, and it’s been a long ride. The company gradually added all .pst-related features to New Outlook, with the initial rollout beginning in June 2025:

• June 2025: We finally got the ability to export our entire mailbox, or just specific folders, into a fresh PST file. (Status: Launched)
• July 2025: You can schedule automatic or regular exports of mailboxes to a PST. (Status: Launched)
• August 2025: Read-only access was added to help you browse your old calendars, events, and contacts. (Status: Launched)
• September 2025: Move emails in PST as attachments. (Status: Launched)
• March 2026: Import our old emails straight from a PST file. (Status: Launched)
• June/July 2026: Import our calendars and contacts from a PST file directly into our mailbox.

As I noted above, New Outlook is still dependent on Outlook Classic to load .PST files, but Microsoft has clarified that it’ll remove that requirement later this year. Once the requirement for Outlook Classic is removed and the ability to bulk import Mail, Calendar, and Contacts is rolled out, the company has no plans to continue developing .PST.

New Outlook’s .PST development is almost over at this point, so you shouldn’t expect anything beyond what’s documented above.

Other features slated to arrive in New Outlook

We have already covered all the confirmed features coming to New Outlook in the next few weeks, but our findings revealed that there’s more on the table than what’s been documented.

For example, Outlook will let you choose whether to send calendar updates to all attendees. At this point, the development of the feature has been marked complete internally, and it’ll roll out soon.

Right now, if you edit a calendar event in New Outlook for Windows 11 or 10, it automatically sends a notification to attendees.

While it may not appear to be a major problem, it’s annoying because it auto-sends notifications to everyone when you change a meeting’s description or add a single person. The current UX causes an email blast to everyone, which can be annoying.

After a new update, New Outlook will finally show a confirmation prompt with an option to choose between “Save” or “Send Update.”

Emails sent from delegated mailboxes do not appear in Sent Items

I’ve personally observed this problem in my Outlook. I have two emails, example@outlook.com and abc@outlook.com.

The abc@outlook.com  account is a shared inbox, so if a coworker replies to a customer from that shared address, that reply does not get saved into the shared “Sent Items” folder. Instead, it appears in the Sent Items folder of the personal email.

In the old Outlook, when you replied to a customer from that shared address, your reply was saved directly into the shared “Sent Items” folder. That is not the case with New Outlook, where the delegated mailbox’s Sent Items folder is always empty.

Microsoft says this feature will soon get fixed, and it’s being worked on internally.

The post Microsoft says New Outlook is now closer to Outlook Classic, adds .PST advanced support and other features appeared first on Windows Latest

Microsoft is preparing to cut thousands of jobs next week, continuing to rein in operating costs as the company pours unprecedented sums into AI infrastructure. 

Business Insider broke the news Tuesday afternoon, saying that the cuts will impact less than 2.5% of the company’s global workforce of about 220,000 people. It includes not just Xbox, where cuts have been signaled for weeks, but also layoffs in sales and consulting. 

GeekWire confirmed the details of the report with a person familiar with the company’s plan. Microsoft isn’t commenting on the report.

The timing follows a familiar pattern. Microsoft often restructures its operations around the close of its fiscal year on June 30, and the cuts would come just as the new year begins. 

The reductions were bigger last year. Microsoft laid off more than 15,000 people in two rounds of cuts a few weeks apart: about 6,000 in May 2025, then around 9,000 (roughly 4% of the company at the time) in early July 2025.

One difference this year: Microsoft’s first-ever voluntary retirement program. About a third of the approximately 8,750 eligible U.S. employees took the buyout, reportedly allowing the company to cut a smaller share of its workforce through layoffs than a year ago. 

The company is on pace to spend more than $100 billion building AI and cloud infrastructure in the fiscal year that just ended — up from $88.7 billion the year before — with about two-thirds going to the chips that power AI. 

Microsoft shares closed Tuesday at $373.02, down 19% over the past month and near a 52-week low, as Wall Street questions whether its heavy AI spending will pay off.

The layoffs come amid a broader wave of restructuring across the tech industry, which has shed more jobs than any other sector this year. U.S. tech companies have announced 123,653 cuts so far in 2026, up 66% from the same stretch of 2025, according to a report from outplacement firm Challenger, Gray & Christmas. 

Across all sectors, not just tech, AI was the most commonly cited reason for job cuts in May — the third straight month it has led the list. The 38,579 cuts attributed to AI were the most in any month since Challenger began tracking the cause in 2023. For the year, AI has been linked to 87,714 cuts, already surpassing the 54,836 attributed to it in all of 2025.

The free open source agentic program is finally invading your phone.