Saltar al contenido principal

BrowserView window.open() Vulnerability Fix

· Lectura de un minuto

A code vulnerability has been discovered that allows Node to be re-enabled in child windows.


Opening a BrowserView with sandbox: true or nativeWindowOpen: true and nodeIntegration: false results in a webContents where window.open can be called and the newly opened child window will have nodeIntegration enabled. This vulnerability affects all supported versions of Electron.

Mitigación

We've published new versions of Electron which include fixes for this vulnerability: 2.0.17, 3.0.15, 3.1.3, 4.0.4, and 5.0.0-beta.2. We encourage all Electron developers to update their apps to the latest stable version immediately.

If for some reason you are unable to upgrade your Electron version, you can mitigate this issue by disabling all child web contents:

view.webContents.on('-add-new-contents', (e) => e.preventDefault());

Más información

This vulnerability was found and reported responsibly to the Electron project by PalmerAL.

Para aprender más sobre las buenas prácticas para mantener tus aplicaciones Electron seguras, ve nuestro tutorial de seguridad.

Si quieres reportar una vulnerabilidad de Electron, envía un correo electrónico a security@electronjs.org.

Node.js Native Addons and Electron 5.0

· 2 lectura mínima

If you're having trouble using a native Node.js addon with Electron 5.0, there's a chance it needs to be updated to work with the most recent version of V8.


Goodbye v8::Handle, Hello v8::Local

In 2014, the V8 team deprecated v8::Handle in favor of v8::Local for local handles. Electron 5.0 includes a version of V8 that has finally removed v8::Handle for good, and native Node.js addons that still use it will need to be updated before they can be used with Electron 5.0.

The required code change is minimal, but every native Node module that still uses v8::Handle will fail to build with Electron 5.0 and will need to be modified. The good news is that Node.js v12 will also include this V8 change, so any modules that use v8::Handle will need to be updated anyway to work with the upcoming version of Node.

I maintain a native addon, how can I help?

If you maintain a native addon for Node.js, ensure you replace all occurrences of v8::Handle with v8::Local. The former was just an alias of the latter, so no other changes need to be made to address this specific issue.

You may also be interested in looking into N-API, which is maintained separately from V8 as a part of Node.js itself, and aims to insulate native addons from changes in the underlying JavaScript engine. You can find more information in the N-API documentation on the Node.js website.

Ayuda! I use a native addon in my app and it won't work!

If you're consuming a native addon for Node.js in your app and the native addon will not build because of this issue, check with the author of the addon to see if they've released a new version that fixes the problem. If not, reaching out to the author (or opening a Pull Request!) is probably your best bet.

Electron v5.0.0 Timeline

· 2 lectura mínima

Por primera vez en la historia, Electron está emocionado de dar a conocer nuestro programa de lanzamiento a partir de la v5. Este es nuestro primer paso para tener una cronología pública a largo plazo.


As mentioned in our v4.0.0 stable release blog post, we are planning to release approximately quarterly to maintain closer cadence with Chromium releases. Chromium releases a new version very quickly -- every 6 weeks.

Take a look at progression in Electron versus Chromium side-by-side:

line graph comparing Electron versus Chromium versions

In the last half of 2018, our top priority was releasing faster and catching up closer to Chromium. We succeeded by sticking to a predetermined timeline. Electron 3.0.0 and 4.0.0 were released in a 2-3 month timeline for each release. We are optimistic about continuing that pace in releasing 5.0.0 and beyond. With a major Electron release approximately every quarter, we're now keeping pace with Chromium's release cadence. Getting ahead of Chromium stable release is always a goal for us and we are taking steps towards that.

We would love to promise future dates like Node.js and Chromium do, but we are not at that place yet. We are optimistic that we will reach a long-term timeline in the future.

Con esto en mente, estamos dando los primeros pasos publicando nuestro calendario de lanzamiento para v5.0.0. Puedes encontrar eso aquí.

To help us with testing our beta releases and stabilization, please consider joining our App Feedback Program.

Electron 4.0.0

· 7 lectura mínima

¡ El equipo de electrones se complace en anunciar que el lanzamiento estable de Electron 4 ya está disponible! Puedes instalarlo desde electronjs.org o desde npm a través de npm install electron@latest. El lanzamiento está repleto de actualizaciones, correcciones y nuevas características, y no podemos esperar a ver lo que construyes con ellos. ¡Lea más para obtener más información sobre esta versión, y por favor comparta cualquier comentario que tenga mientras explora!


What's New?

Una gran parte de la funcionalidad de Electron es proporcionada por Chromium, Node.js y V8, los componentes principales que componen Electron. Como tal, un objetivo clave para el equipo de Electron es mantenerse al día con los cambios en estos proyectos tanto como sea posible proporcionando a los desarrolladores que construyen aplicaciones Electron acceso a nuevas características web y JavaScript. Con este fin, Electron 4 presenta los principales saltos de versión de cada uno de estos componentes; Electron v 4.0.0 incluye 69.0.3497.106de cromo, 10.11.0de nodo y 6.9.427.24V8.

Además, Electron 4 incluye cambios en las APIs específicas de Electron. Puedes encontrar un resumen de los cambios principales en Electron 4 a continuación; para ver la lista completa de cambios, revisa las notas de lanzamiento de Electron v 4.0.0.

Deshabilitar el módulo remote

Ahora tiene la habilidad de desactivar el módulo remote por razones de seguridad. El módulo puede ser deshabilitado para etiquetas BrowserWindows y webview:

// BrowserWindow
new BrowserWindow({
webPreferences: {
enableRemoteModule: false
}
})

// webview tag
<webview src="http://www.google.com/" enableremotemodule="false"></webview>

Consulte la documentación de BrowserWindow y <webview> Tag para más información.

Filtrando remote.require() / remote.getGlobal() solicitudes

Esta característica es útil si no desea deshabilitar completamente el módulo remote en su proceso de renderizado o webview pero le gustaría un control adicional sobre qué módulos pueden ser requeridos vía remote.require.

Cuando se requiere un módulo a través de remote.require en un proceso de renderizado, se eleva un evento remote-require en el módulo app. Puede llamar a event.preventDefault() en el evento (el primer argumento) para evitar que el módulo sea cargado. La WebContents instancia donde ocurrió la solicitud es pasada como el segundo argumento, y el nombre del módulo es pasado como el tercer argumento. El mismo evento también se emite en la instancia de WebContents, pero en este caso, los únicos argumentos son el evento y el nombre del módulo. En ambos casos, puede devolver un valor personalizado estableciendo el valor de event.returnValue.

// Controla `remote.require` desde todos los WebContents:
app.on('remote-require', function (event, webContents, requestedModuleName) {
// ...
});

// Control `remote.require` from a specific WebContents instance:
browserWin.webContents.on(
'remote-require',
function (event, requestedModuleName) {
// ...
}
);

De una manera similar, cuando se llama a remote.getGlobal(name), se levanta un evento remote-get-global. Esto funciona del mismo modo que el evento remote-require: llame a preventDefault() para evitar que el global sea devuelto, y establece event.returnValue para retornar un valor personalizado.

// Control `remote.getGlobal` from all WebContents:
app.on(
'remote-get-global',
function (event, webContents, requrestedGlobalName) {
// ...
}
);

// Control `remote.getGlobal` from a specific WebContents instance:
browserWin.webContents.on(
'remote-get-global',
function (event, requestedGlobalName) {
// ...
}
);

Para obtener más información, consulte la siguiente documentación:

JavaScript Access to the About Panel

En macOS, ahora puede llamar a app.showAboutPanel() para mostrar programáticamente el panel Acerca, al igual que hacer clic en el elemento de menú creado a través de {role: 'about'}. Vea la documentación de showAboutPanel para más información

Controlando WebContents Limitando el segundo plano

WebContents instances now have a method setBackgroundThrottling(allowed) to enable or disable throttling of timers and animations when the page is backgrounded.

let win = new BrowserWindow(...)
win.webContents.setBackgroundThrottling(enableBackgroundThrottling)
win.webContents.setBackgroundThrottling(enableBackgroundThrottling)

See the setBackgroundThrottling documentation for more information.

Restaurar archivos borrados

No más soporte para macOS 10.9

Chromium no longer supports macOS 10.9 (OS X Mavericks), and as a result Electron 4.0 and beyond does not support it either.

Single Instance Locking

Previously, to make your app a Single Instance Application (ensuring that only one instance of your app is running at any given time), you could use the app.makeSingleInstance() method. Starting in Electron 4.0, you must use app.requestSingleInstanceLock() instead. The return value of this method indicates whether or not this instance of your application successfully obtained the lock. If it failed to obtain the lock, you can assume that another instance of your application is already running with the lock and exit immediately.

For an example of using requestSingleInstanceLock() and information on nuanced behavior on various platforms, see the documentation for app.requestSingleInstanceLock() and related methods and the second-instance event.

win_delay_load_hook

When building native modules for windows, the win_delay_load_hook variable in the module's binding.gyp must be true (which is the default). If this hook is not present, then the native module will fail to load on Windows, with an error message like Cannot find module. See the native module guide for more information.

Deprecations

The following breaking changes are planned for Electron 5.0, and thus are deprecated in Electron 4.0.

Node.js Integration Disabled for nativeWindowOpen-ed Windows

Starting in Electron 5.0, child windows opened with the nativeWindowOpen option will always have Node.js integration disabled.

webPreferences Default Values

When creating a new BrowserWindow with the webPreferences option set, the following webPreferences option defaults are deprecated in favor of new defaults listed below:

PropertyDeprecated DefaultNew Default
contextIsolationfalsetrue
nodeIntegrationtruefalse
webviewTagvalue of nodeIntegration if set, otherwise truefalse

Please note: there is currently a known bug (#9736) that prevents the webview tag from working if contextIsolation is on. Keep an eye on the GitHub issue for up-to-date information!

Learn more about context isolation, Node integration, and the webview tag in the Electron security document.

Electron 4.0 will still use the current defaults, but if you don't pass an explicit value for them, you'll see a deprecation warning. To prepare your app for Electron 5.0, use explicit values for these options. See the BrowserWindow docs for details on each of these options.

webContents.findInPage(text[, options])

The medialCapitalAsWordStart and wordStart options have been deprecated as they have been removed upstream.

Programa de retroalimentación

The App Feedback Program we instituted during the development of Electron 3.0 was successful, so we've continued it during the development of 4.0 as well. We'd like to extend a massive thank you to Atlassian, Discord, MS Teams, OpenFin, Slack, Symphony, WhatsApp, and the other program members for their involvement during the 4.0 beta cycle. To learn more about the App Feedback Program and to participate in future betas, check out our blog post about the program.

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. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. See our versioning document for more detailed information about versioning in Electron.

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

SQLite Vulnerability Fix

· Lectura de un minuto

A remote code execution vulnerability, "Magellan," has been discovered affecting software based on SQLite or Chromium, including all versions of Electron.


Ámbito

Electron applications using Web SQL are impacted.

Mitigación

Affected apps should stop using Web SQL or upgrade to a patched version of Electron.

We've published new versions of Electron which include fixes for this vulnerability:

There are no reports of this in the wild; however, affected applications are urged to mitigate.

Más información

This vulnerability was discovered by the Tencent Blade team, who have published a blog post that discusses the vulnerability.

Para aprender más sobre las buenas prácticas para mantener tus aplicaciones Electron seguras, ve nuestro tutorial de seguridad.

Si quieres reportar una vulnerabilidad de Electron, envía un correo electrónico a security@electronjs.org.

Programa de Retroalimentación de la Aplicación Electron

· 3 lectura mínima

Estamos trabajando en hacer el ciclo de desarrollo de Electrón más rápido y estable. Para hacerlo posible, hemos iniciado el Programa de Comentarios de Aplicaciones para aplicaciones Electron a gran escala para probar nuestras versiones beta y reportarnos problemas específicos de la aplicación. Esto nos ayuda a priorizar el trabajo que hará que las aplicaciones se actualicen antes a nuestra próxima versión estable.

Edición (2020-05-21): Este programa ha sido retirado.


¿Quién puede unirse?

Nuestros criterios y expectativas para que las aplicaciones se unan a este programa incluyen los siguientes elementos:

  • Prueba tu aplicación durante el periodo beta durante más de 10.000 horas
  • Tener una persona de un solo punto que chequee semanalmente para discutir los errores de su aplicación Electron y bloqueadores de aplicaciones
  • Aceptas acatar el Código de Conducta de Electron
  • Está dispuesto a compartir la siguiente información listada en la siguiente pregunta

¿Qué información debe compartir mi aplicación Electron?

  • Total de horas de funcionamiento de su aplicación con cualquier versión beta
  • Versión de Electron con la que está probando su aplicación (por ejemplo, 4.0.0-beta.3)
  • Cualquier error que impida que su aplicación de actualizar a la línea de publicación sea probado

Usuario / Horas

Entendemos que no todos pueden compartir números de usuario exactos, sin embargo mejores datos nos ayudan a decidir cuán estable es una versión en particular. Pedimos que las aplicaciones se comprometan a probar un número mínimo de horas de usuario, actualmente 10.000 en todo el ciclo beta.

  • 10 horas de usuario podrían ser 10 personas probando por una hora, o una persona probando por 10 horas
  • Puede dividir la prueba entre versiones beta, por ejemplo prueba de 5.000 horas de usuario en 3.0.0-beta. y luego pruebe por 5.000 horas de usuario en 3.0.0-beta.5. Más es mejor, pero entendemos que algunas aplicaciones no pueden probar cada versión beta
  • Las horas CI o QA no cuentan para el total; sin embargo, las versiones internas cuentan

¿Por qué debería unirse mi aplicación Electron?

Los errores de tu aplicación serán rastreados y estarán en el radar del núcleo del equipo de Electron. Sus comentarios ayudan al equipo de Electron a ver cómo están haciendo las nuevas betas y qué trabajo hay que hacer.

¿Se compartirá la información de mi aplicación públicamente? ¿Quién puede ver esta información?

No, la información de su aplicación no se compartirá con el público en general. La información se mantiene en un repositorio privado de GitHub que sólo es visible para los miembros del Programa de Comentarios de la aplicación y Gobernanza Electron. Todos los miembros han aceptado seguir el Código de Conducta de Electron.

Registrarse

Actualmente estamos aceptando un número limitado de registros. Si está interesado y puede cumplir con los requisitos anteriores, por favor rellene este formulario.

Electron 3.0.0

· 4 lectura mínima

¡El equipo de Electron se complace en anunciar que la primera versión estable de Electron 3 se encuentra disponible desde electronjs.org y a través de npm install electron@latest! El lanzamiento está lleno de actualizaciones, mejores y nuevas características, y no podemos esperar para ver qué construirás con estas. A continuación se comparten los detalles sobre este lanzamiento, y le damos la bienvenida a tus comentarios mientras exploras.


Release Process

As we undertook development of v3.0.0, we sought to more empirically define criteria for a stable release by formalizing the feedback progress for progressive beta releases. v3.0.0 would not have been possible without our App Feedback Program partners, who provided early testing and feedback during the beta cycle. Thanks to Atlassian, Atom, Microsoft Teams, Oculus, OpenFin, Slack, Symphony, VS Code, and other program members for their work. If you'd like to participate in future betas, please mail us at info@electronjs.org.

Changes / New Features

Major bumps to several important parts of Electron's toolchain, including Chrome v66.0.3359.181, Node v10.2.0, and V8 v6.6.346.23.

  • [#12656] feat: app.isPackaged
  • [#12652] feat: app.whenReady()
  • [#13183] feat: process.getHeapStatistics()
  • [#12485] feat: win.moveTop() to move window z-order to top
  • [#13110] feat: TextField and Button APIs
  • [#13068] feat: netLog API for dynamic logging control
  • [#13539] feat: enable webview in sandbox renderer
  • [#14118] feat: fs.readSync now works with massive files
  • [#14031] feat: node fs wrappers to make fs.realpathSync.native and fs.realpath.native available

Breaking API changes

  • [#12362] feat: updates to menu item order control
  • [#13050] refactor: removed documented deprecated APIs
    • See docs for more details
  • [#12477] refactor: removed did-get-response-details and did-get-redirect-request events
  • [#12655] feat: default to disabling navigating on drag/drop
  • [#12993] feat: Node v4.x or greater is required use the electron npm module
  • [#12008 #12140 #12503 #12514 #12584 #12596 #12637 #12660 #12696 #12716 #12750 #12787 #12858] refactor: NativeWindow
  • [#11968] refactor: menu.popup()
  • [#8953] feat: no longer use JSON to send the result of ipcRenderer.sendSync
  • [#13039] feat: default to ignore command line arguments following a URL
  • [#12004] refactor: rename api::Window to api::BrowserWindow
  • [#12679] feat: visual zoom now turned off by default
  • [#12408] refactor: rename app-command media-play_pause to media-play-pause

macOS

  • [#12093] feat: workspace notifications support
  • [#12496] feat: tray.setIgnoreDoubleClickEvents(ignore) to ignore tray double click events.
  • [#12281] feat: mouse forward functionality on macOS
  • [#12714] feat: screen lock / unlock events

Windows

  • [#12879] feat: added DIP to/from screen coordinate conversions

Nota Bene: Switching to an older version of Electron after running this version will require you to clear out your user data directory to avoid older versions crashing. You can get the user data directory by running console.log(app.getPath("userData")) or see docs for more details.

Bug Fixes

  • [#13397] fix: issue with fs.statSyncNoException throwing exceptions
  • [#13476, #13452] fix: crash when loading site with jquery
  • [#14092] fix: crash in net::ClientSocketHandle destructor
  • [#14453] fix: notify focus change right away rather not on next tick

MacOS

  • [#13220] fix: issue allowing bundles to be selected in <input file="type"> open file dialog
  • [#12404] fix: issue blocking main process when using async dialog
  • [#12043] fix: context menu click callback
  • [#12527] fix: event leak on reuse of touchbar item
  • [#12352] fix: tray title crash
  • [#12327] fix: non-draggable regions
  • [#12809] fix: to prevent menu update while it's open
  • [#13162] fix: tray icon bounds not allowing negative values
  • [#13085] fix: tray title not inverting when highlighted
  • [#12196] fix: Mac build when enable_run_as_node==false
  • [#12157] fix: additional issues on frameless windows with vibrancy
  • [#13326] fix: to set mac protocol to none after calling app.removeAsDefaultProtocolClient
  • [#13530] fix: incorrect usage of private APIs in MAS build
  • [#13517] fix: tray.setContextMenu crash
  • [#14205] fix: pressing escape on a dialog now closes it even if defaultId is set

Linux

  • [#12507] fix: BrowserWindow.focus() for offscreen windows

Other Notes

  • PDF Viewer is currently not working but is being worked on and will be functional once again soon
  • TextField and Button APIs are experimental and are therefore off by default
    • They can be enabled with the enable_view_api build flag

What's Next

The Electron team continues to work on defining our processes for more rapid and smooth upgrades as we seek to ultimately maintain parity with the development cadences of Chromium, Node, and V8.

Using GN to Build Electron

· 2 lectura mínima

Electron now uses GN to build itself. Here's a discussion of why.


GYP and GN

Cuando Electron fue lanzado por primera vez en 2013, la configuración de compilación de Chromium fue escrita con GYP, abreviando "Generar proyectos".

En 2014, el proyecto Chromium introdujo una nueva herramienta de configuración de construcción llamada GN (abreviatura de "Generar Ninja") los archivos de construcción de Chromium fueron migrados a GN y GYP fue eliminado del código fuente.

Históricamente, Electron ha mantenido una separación entre el código principal de Electron y libchromiumcontent, la parte de Electron que envuelve el 'contenido' de Chromium. Electron has carried on using GYP, while libchromiumcontent -- as a subset of Chromium -- switched to GN when Chromium did.

Like gears that don't quite mesh, there was friction between using the two build systems. Maintaining compatibility was error-prone, from compiler flags and #defines that needed to be meticulously kept in sync between Chromium, Node, V8, and Electron.

To address this, the Electron team has been working on moving everything to GN. Today, the commit to remove the last of the GYP code from Electron was landed in master.

What this means for you

If you're contributing to Electron itself, the process of checking out and building Electron from master or 4.0.0 is very different than it was in 3.0.0 and earlier. See the GN build instructions for details.

If you're developing an app with Electron, there are a few minor changes you might notice in the new Electron 4.0.0-nightly; but more than likely, Electron's change in build system will be totally transparent to you.

What this means for Electron

GN is faster than GYP and its files are more readable and maintainable. Moreover, we hope that using a single build configuration system will reduce the work required to upgrade Electron to new versions of Chromium.

  • It's already helped development on Electron 4.0.0 substantially because Chromium 67 removed support for MSVC and switched to building with Clang on Windows. With the GN build, we inherit all the compiler commands from Chromium directly, so we got the Clang build on Windows for free!

  • It's also made it easier for Electron to use BoringSSL in a unified build across Electron, Chromium, and Node -- something that was problematic before.

Solución de vulnerabilidad de WebPreferences

· 3 lectura mínima

Se ha descubierto una vulnerabilidad de ejecución de un código remoto la cual afecta aplicaciones con la capacidad de abrir ventanas anidadas hijas en versiones de Electron (3.0.0-beta.6, 2.0.7, 1.8.7, and 1.7.15). La vulnerabilidad ha sido asignada al identificador CVE CVE-2018-15685.


Plataformas afectadas

Esto te afecta si:

  1. Has incrustado cualquier contenido de usuario remoto, incluso en una sandbox
  2. Aceptas inputs de usuario con cualquier vulnerabilidad XSS

Detalles

Esto te afecta si cualquier código de usuario se ejecuta dentro de iframe / si puede crear un iframe. Dada la posibilidad de una vulnerabilidad XSS, se puede asumir que la mayoría de aplicaciones son vulnerables a este caso.

Esto te afecta si abres cualquiera de tus ventanas con las opciones nativeWindowOpen: true o sandbox: true. A pesar de que esta vulnerabilidad también requiere que exista una vulnerabilidad XSS en tu aplicación, deberías aplicar una de las mitigaciones de abajo si utilizas alguna de estas opciones.

Mitigación

We've published new versions of Electron which include fixes for this vulnerability: 3.0.0-beta.7, 2.0.8, 1.8.8, and 1.7.16. Le pedimos a todos los desarrolladores de Electron a que actualicen sus aplicaciones a la más reciente versión estable ahora mismo.

If for some reason you are unable to upgrade your Electron version, you can protect your app by blanket-calling event.preventDefault() on the new-window event for all webContents'. Si no utilizas window.open o ninguna ventana hija en absoluto, entonces esta también es una mitigación válida para tu aplicación.

mainWindow.webContents.on('new-window', (e) => e.preventDefault());

Si dependes de la capacidad de tus ventanas hijas para crear ventanas de nietos, entonces una tercera estrategia de mitigación requiere utilizar el siguiente código en tu ventana de nivel superior:

const enforceInheritance = (topWebContents) => {
const handle = (webContents) => {
webContents.on(
'new-window',
(event, url, frameName, disposition, options) => {
if (!options.webPreferences) {
options.webPreferences = {};
}
Object.assign(
options.webPreferences,
topWebContents.getLastWebPreferences()
);
if (options.webContents) {
handle(options.webContents);
}
}
);
};
handle(topWebContents);
};

enforceInheritance(mainWindow.webContents);

Este código forzará manualmente las ventanas de nivel superior (webPreferences) sean aplicadas a todas las ventanas hijas de manera infinitamente profunda.

Más información

Esta vulnerabilidad fue encontrada y reportada responsablemente al proyecto Electron por Matt Austin de Contrast Security.

Para aprender más sobre las buenas prácticas para mantener tus aplicaciones Electron seguras, ve nuestro tutorial de seguridad.

Si quieres reportar una vulnerabilidad de Electron, envía un correo electrónico a security@electronjs.org.

Búsqueda

· 5 lectura mínima

The Electron website has a new search engine that delivers instant results for API docs, tutorials, Electron-related npm packages, and more.

Electron Search Screenshot


Learning a new technology or framework like Electron can be intimidating. Once you get past the quick-start phase, it can be difficult to learn best practices, find the right APIs, or discover the tools that will help you build the app of your dreams. We want the Electron website to be a better tool for finding the resources you need to build apps faster and more easily.

Visit any page on electronjs.org and you'll find the new search input at the top of the page.

The Search Engine

When we first set about adding search to the website, we rolled our own search engine using GraphQL as a backend. GraphQL was fun to work with and the search engine was performant, but we quickly realized that building a search engine is not a trivial task. Things like multi-word search and typo detection require a lot of work to get right. Rather than reinventing the wheel, we decided to use an existing search solution: Algolia.

Algolia is a hosted search service that has quickly become the search engine of choice among popular open source projects like React, Vue, Bootstrap, Yarn, and many others.

Here are some of the features that made Algolia a good fit for the Electron project:

API Docs

Sometimes you know what you want to accomplish, but you don't know exactly how to do it. Electron has over 750 API methods, events, and properties. No human can easily remember all of them, but computers are good at this stuff. Using Electron's JSON API docs, we indexed all of this data in Algolia, and now you can easily find the exact API you're looking for.

Trying to resize a window? Busca [redimensionar] y salta directamente al método que necesitas.

Tutoriales

Electron has an ever-growing collection of tutorials to complement its API documentation. Now you can more easily find tutorials on a given topic, right alongside related API documentation.

Looking for security best practices? Search for security.

npm Packages

There are now over 700,000 packages in the npm registry and it's not always easy to find the one you need. To make it easier to discover these modules, we've created electron-npm-packages, a collection of the 3400+ modules in the registry that are built specifically for use with Electron.

La gente de Bibliotecas. o han creado SourceRank, un sistema para anotar proyectos de software basado en una combinación de métricas como código, comunidad, documentación y uso. Hemos creado un módulo [sourceranks] que incluye la puntuación de cada módulo en el registro npm, y nosotros usamos estas puntuaciones para ordenar los resultados del paquete.

Want alternatives to Electron's built-in IPC modules? Buscar [es:paquete ipc].

Aplicaciones de Electron

It's easy to index data with Algolia, so we added the existing apps list from electron/apps.

Prueba a buscar [music] o [homebrew].

Filtering Results

If you've used GitHub's code search before, you're probably aware of its colon-separated key-value filters like extension:js or user:defunkt. We think this filtering technique is pretty powerful, so we've added an is: keyword to Electron's search that lets you filter results to only show a single type:

Keyboard Navigation

People love keyboard shortcuts! The new search can be used without taking your fingers off the keyboard:

  • / focuses the search input
  • esc focuses the search input and clears it
  • down moves to the next result
  • up moves to the previous result, or the search input
  • enter opens a result

We also open-sourced the module that enables this keyboard interaction. It's designed for use with Algolia InstantSearch, but is generalized to enable compatibility with different search implementations.

We want your feedback

If you encounter any issues with the new search tool, we want to hear about it!

The best way to submit your feedback is by filing an issue on GitHub in the appropriate repository:

Thanks

Special thanks to Emily Jordan and Vanessa Yuen for building these new search capabilities, to Libraries.io for providing SourceRank scores, and to the team at Algolia for helping us get started. 🍹