Electron: Versión sin cabeza para pruebas

Al usar la ventana oculta del navegador, atom-shell puede hacer lo que hace phantomjs, el ejemplo en la página de inicio de phantomjs podría traducirse a atom-shell:

BrowserWindow = require('browser-window');

console.log('Loading a web page');
var page = new BrowserWindow({show: false});
var url = 'http://www.phantomjs.org/';
page.on('loading-state-changed', (event, isLoading) {
  if (!isLoading)
    //Page is loaded!
    require('app').exit();
});
page.loadUrl(url);

Por supuesto, es posible que necesitemos agregar algunas API más para fines de prueba de automatización.

El único problema es que en lugar de dibujar en un búfer virtual, atom-shell en realidad dibuja la página en una ventana real, esto requeriría un entorno gráfico, en Windows y OS X no importa, sin embargo en Linux tenemos que usar xvfb para proporcionar un servidor X para atom-shell. Esto es por diseño en la API de contenido de Chromium, por lo que no podemos hacer nada para eliminar la dependencia del entorno gráfico.

Últimamente he tenido éxito con esto (usando Xvfb en un servidor Ubuntu). Mi caso de uso es la captura de capturas de pantalla de páginas con plantilla. De hecho, descubrí que atom-shell a través de Xvfb en el servidor (un m3-large) tiene un mejor rendimiento que en mi Macbook pro local. Esto me llevó a querer que atom-shell funcione a través de Xvfb en osx también.

Dado que osx se envía con Xvfb, esa parte es fácil. ¿Puedo hacer que atom-shell use una pantalla Xvfb en osx? El uso de la variable estándar DISPLAY env como lo hago en Linux no funciona. ¿Quizás libchromiumcontent no sabe cómo usar X11 cuando se ejecuta en Darwin?

Xvfb solo funciona para aplicaciones escritas para el entorno X11, en OS X atom-shell usa Cocoa para la visualización, que creo que no puede funcionar con Xvfb.

Sí, un poco, pon eso junto. ¿Probablemente no sea realmente una forma de compilar desde el código fuente para X11?

@zcbenz , actualmente no es posible crear un BrowserWindow que sea más grande que la resolución actual en OS X, incluso si usa new BrowserWindow({show: false});

@FWeinb ¿puedes abrir un ticket específico por separado para lo anterior?

Creado # 475

Estoy cerrando esto porque no hay forma de dibujar una página sin crear un widget nativo en Chromium, y no creo que nunca lo permitan.

Para las pruebas automáticas, admitimos Selenium.

El proyecto CEF tiene soporte para renderizado fuera de la pantalla , por lo que puede dibujar la pantalla en un búfer en lugar de una ventana. Con respecto al servidor X para Linux, parece que hay una manera de trabajar sin él agregando un objetivo llamado Ozone (vea la discusión aquí ).

@etiktin ¡ Gracias por la información! Estoy reabriendo esto ya que existe una implementación sobre cómo hacerlo.

Realmente podríamos usar apoyo para esto. Recientemente reemplazamos Phantom con Electron en Nightmare y nos encanta hasta ahora, pero no funciona de inmediato en Linux.

Esto es lo que debemos hacer ahora para que funcione: https://github.com/segmentio/nightmare/issues/224#issuecomment -141575361

Se me ha encomendado la tarea de automatizar el comportamiento del usuario para una de nuestras aplicaciones web que se convertirá en una aplicación electrónica de escritorio independiente. Antes de que nuestra empresa decidiera hacer este movimiento, creamos objetos de página usando el controlador web Chrome e interactuamos con la aplicación web invocando botones / menús desplegables / cuadros de texto usando los selectores css. ¿Hay alguna manera de hacer esto con una aplicación web que está empaquetada con el shell de Electron? La compañía planea usar las opciones de la barra de menú para invocar cierta funcionalidad e intenté llegar a las opciones predeterminadas de la barra de menú como Archivo / Editar / Ayuda usando el controlador de JavaScript sin éxito. ¿Hay algún ejemplo sobre cómo hacer esto?

https://github.com/segmentio/nightmare/issues/224#issuecomment -141575361 parece que el fragmento de código de

¿Alguien ha realizado pruebas sin cabeza trabajando en SuSE? ¿Específicamente SLES?

@fritx Lo mismo que se usa para SlimerJS, pero NO es el modo sin cabeza.

@fritx eso es lo que @zcbenz estaba diciendo, tienes que tener Xvfb en ejecución. Tanto CEF3 como Chromium Content Shell dependen actualmente de Xlib. Pero con la finalización de Ozone: https://www.chromium.org/developers/design-documents/ozone
podría proporcionar cualquier E / S de bajo nivel.

Aparentemente, hay un error maestro en el propio Chromium: https://code.google.com/p/chromium/issues/detail?id=546953

Esto es interesante:

Fecha: miércoles 02 dic 15:35:21 2015

[sin cabeza] Esqueleto inicial de sin cabeza / público /

Cree un esquema de la futura API sin cabeza.

¿ChromeDriver funciona con electron?

Un binario sin cabeza que no requiera xvfb abriría nuevos entornos como AWS Lambda . ¡Inscríbeme!

@Vanuan ¿Has oído hablar de Nightmare ? Eso podría ayudarlo si no hay nada que necesite específicamente de ChromeDriver.

¿Tiene controlador Capybara / Selenium?

+1

Estoy un poco confundida. ¿Existe un modo sin cabeza? ¿Podemos hacer esto de manera efectiva con BrowserWindow ({show: false})? Esto sería muy útil para mí, estoy tratando de que esto funcione para que podamos crear componentes web del lado del servidor: https://github.com/scramjs/scram-markup-engine

Creo que he respondido a mi propia pregunta mientras miraba a mi alrededor. Electron no admite de forma nativa un modo sofisticado sin cabeza. Nightmare parece permitir algo así, pero aún debe realizar alguna configuración para que funcione en ciertos sistemas sin un entorno gráfico. Electron también puede hacerlo si usa BrowserWindow ({show: false}), pero debe usar xvfb para proporcionar un entorno gráfico en sistemas Linux sin cabeza (que en realidad no parece tan malo). Corrígeme si me equivoco y haz +1 en esta función.

Con el nuevo proyecto sin cabeza de cromo [1], ¿sería posible hacer que los electrones sin cabeza sin usar xvfb?

Creo que la limitación actual fue con libchromium. ¿Han arreglado eso los chicos de Chrome?

1: https://chromium.googlesource.com/chromium/src/+/master/headless/README.md

Hay un foro relacionado: https://groups.google.com/a/chromium.org/forum/#!forum/headless -dev

¿Algún progreso en esto? Esto sería realmente útil para probar

Segmentio / nightmare es perfecto para esto. Simplemente:

const nightmare = Nightmare({
  show: true
});

@amilajack Para casos simples como ejecutar pruebas de unidades simples de Mocha sin cabeza, Nightmare sería como usar un mazo de 20 libras para clavar un clavo pequeño (léase: exageración masiva). Es una biblioteca de automatización del navegador completamente desarrollada, con baterías incluidas, que no solo puede realizar la navegación y la entrada básicas, sino que incluso puede guardar archivos HTML y PDF en el disco o tomar capturas de pantalla. Debería ser necesario exactamente el 0% de esta biblioteca para ejecutar pruebas unitarias simples.

@isiahmeadows @mcolyer dijo que quería una versión sin cabeza de atom-shell que pudiera usarse como reemplazo '. Electron es exactamente eso con características adicionales.

Sí, pero ¿por qué necesitarías azúcar para lo que no usas? (Me refería a todo el azúcar; teóricamente, podrías volver a implementar Electron en su totalidad con solo enlaces vainilla Node + OpenGL).

El caso de uso más común para los navegadores sin cabeza son cosas como para qué ya existen mocha-phantomjs y Karma: ejecutar pruebas unitarias del navegador desde la CLI. La mayoría de las personas usan xvfb, un servidor X sin cabeza, en Travis si necesitan probar Firefox / Chrome, porque ese no tiene un servidor X en ejecución, e incluso podría ejecutar Electron con eso, pero los navegadores sin cabeza como PhantomJS y SlimerJS no lo hacen. No necesito un servidor X. Electron + Nightmare todavía necesita un servidor X de algún tipo (incluso si es xvfb) para ejecutarse, y este problema solicita que se elimine esa dependencia, pero lo más probable es que no suceda hasta que Chromium pueda quedarse sin cabeza y esos cambios se propaguen al contenido de

Headless ahora está en Chrome 59: https://www.chromestatus.com/features/5678767817097216

@sindresorhus @zcbenz ¿Este cambio en Chromium hará alguna diferencia aquí?

Electron ya es maravilloso, ¡y un modo sin cabeza lo haría aún mejor!

(También sería útil para Nightmare , que se basa en Electron)

Pude hacer que Xvfb funcionara en lambda, lo que podría ser útil para las pruebas basadas en lambda ... https://github.com/nisaacson/aws-lambda-xvfb

¿Alguna noticia sobre cuándo Electron admitirá el verdadero sin cabeza? ¿Podemos contar con que esto suceda? No puedo esperar para eliminar xvfb.

@lastmjs , ¿logró que Electron se ejecutara en AWS Lambda basado en xvfb?

@schickling Ver https://github.com/nisaacson/aws-lambda-xvfb

Gracias por tu comentario @MrSaints. De hecho, estoy depurando este repositorio durante varias horas ya que no puedo lograr que nightmare ejecute. ¿Funciona para ti?

@zcbenz FYI chrome 59 obtendrá soporte de modo sin cabeza https://www.chromestatus.com/features/5678767817097216

@schickling ver https://github.com/JohannesHoppe/nightmare-html2pdf - pesadilla en la ventana acoplable, con Xvfb

Gracias @JohannesHoppe , tengo Nightmare trabajando en Docker con Xvfb pero quiero ejecutarlo en AWS Lambda.

Abrí un problema para reemplazar Electron con Chrome sin cabeza en Nightmare: https://github.com/segmentio/nightmare/issues/1092

@schickling prueba esto: https://github.com/dimkir/nightmare-lambda-tutorial

Disculpas si esto se responde en otro lugar, pero no puedo encontrar una respuesta concreta. En su comentario anterior con muchos +1 , @sandstrom señaló que sin cabeza ahora está disponible en Chrome 59.

¿Está el soporte para la bandera sin cabeza de Chrome en la hoja de ruta de desarrollo de Electron? Parece que esta es una "victoria" potencialmente enorme para Electron, ya que hace posible el uso sin cabeza.

Estoy de acuerdo con @rinogo. Tener una opción sin cabeza para electron será muy útil para ejecutar pruebas en sistemas ci y en dev box sin necesidad de una pantalla virtual y que se haga cargo de la máquina. También estoy interesado en conocer la hoja de ruta para el electrón y posiblemente contribuir.

Xvfb es molesto, ¡será genial si Electron admite un verdadero sin cabeza!

xvfb-tal vez mientras tanto

Hay un nuevo artículo de Google: https://developers.google.com/web/updates/2017/04/headless-chrome

Viene pronto.

Parece que Chrome 59 está ahora en el canal estable. ¿Cuáles son los próximos pasos para admitir sin cabeza en Electron?

Por favor, haga de esto una realidad: al hacer esto y permitir que NightmareJS ejecute Electron sin cabeza, finalmente eliminaría como un tercio de todos los casos de uso de Selenium. *

* Ser hiperbólico pero tampoco realmente

@aendrew Creo que NightmareJS podría ser _reescrito_ para usar / incluir un backend CDP en su lugar, en lugar de hacer que Electron (con una filosofía: _construir aplicaciones de escritorio multiplataforma _) no tenga cabeza. Ver: https://github.com/cyrus-and/chrome-remote-interface

@MrSaints No envidio a los mantenedores; ellos _sólo_ terminaron de convertirlo de PhantomJS como hace un año. Aunque, en todo caso, tal vez sea una buena motivación hacer que la capa del navegador de Nightmare sea conectable ...

Independientemente, el punto de que Electron esté orientado al escritorio está bien entendido.

@aendrew @MrSaints A riesgo de difundir mi ignorancia ... ¿Qué tan difícil es implementar este cambio (que respalda la bandera headless )? No estoy seguro de cómo Electron interactúa con / extiende Chromium, pero me parece que los pasos para implementar esto son:

1. Actualice Chromium de Electron a la versión 59+.
2. Proporcione el parámetro de configuración / indicador de línea de comandos headless .
3. Otras cosas de las que obviamente no estoy contando. :)

Supongo que lo que estoy diciendo es que, con headless ahora disponible en Chromium, implementar un modo sin cabeza (por ejemplo, para NightmareJS) parece ser relativamente sencillo. Por supuesto, una versión de uso general de Electron podría tomar algún tiempo para resolver ciertos casos de uso. Sin embargo, generar una compilación diseñada para algo como NightmareJS, debería ser bastante sencillo, ¿verdad?

Si tuviera una necesidad inmediata de las mejoras de velocidad, me lanzaría y le daría una oportunidad. Sin embargo, todavía nos las arreglamos con NightmareJS tal como está, así que estamos bien por el momento.

Independientemente, ¡gracias a los mantenedores de todos estos proyectos por sus contribuciones y su arduo trabajo! :)

Con respecto a NightmareJS: actualmente estamos trabajando en una versión de Nightmare construida en Chrome sin cabeza, incluso capaz de ejecutarse en entornos sin servidor como AWS Lambda. Lo abriremos pronto @graphcool. 🚀

@schickling ¡ eso va a ser increíble!

Una cosa a tener en cuenta con --headless en Chrome es que deshabilita el soporte para todos los complementos. Entonces, si necesita flash (que se puede hacer con electron / nightmare) o el visor de PDF, etc., --headless no es para usted y querrá usar xvfb.

No puedo esperar para ejecutar Electron en AWS Lambda ... creo

Amén @lastmjs Amén

¿Qué pasa con esta solución?
https://github.com/dimkir/nightmare-lambda-tutorial

Aunque todavía no lo he probado

@xplodedthemes usa una versión precompilada de xvfb

Enchufe desvergonzado: https://github.com/joelgriffith/navalia. Esto se construyó sobre Chrome sin cabeza para pruebas funcionales y más. Incluye algunas características interesantes como paralelizar varias tareas, un front-end GraphQL y más.

¡Doy la bienvenida a cualquier RP / Problema / Comentarios!

¡Hola a todos! Lamento tenerlos a todos esperando ... 💤

Acabamos de utilizar Chromeless de código abierto. Se basa en Chrome sin cabeza y funciona tanto localmente como en AWS Lambda. La API es bastante similar a NightmareJS.

Puedes probarlo aquí: https://chromeless.netlify.com

¿Chromeless acaba de reemplazar a Nightmare? Chromeless tiene un largo camino por recorrer antes de alcanzar a Nightmare.

Lo usamos como reemplazo de Nightmare, ya que necesitamos la capacidad de ejecutar múltiples pruebas al mismo tiempo.

Pregunta (tal vez no sea buena para este hilo): ¿está considerando hacer que la funcionalidad pdf funcione? Si es así, esto podría ahorrarnos un montón de dolores de cabeza (y costos).

Vaya, eso es increíble. ¡Buen trabajo chicos!

@zcbenz parece que han surgido soluciones para esto: ¿está bien cerrar?

Umm, este problema sigue siendo extremadamente válido. Todas las "soluciones" implican abandonar Nightmare por completo.

Totalmente de acuerdo con @keithkml - las soluciones, aunque bien intencionadas (¡gracias!), Han estado más en la línea de "alternativas" hasta que se proporciona una solución real. En ese sentido, ¿alguien aquí tiene la experiencia suficiente para responder las preguntas que planteé en mi comentario anterior ? (Y de nuevo, ¡disculpe mi ignorancia! :))

Todavía no entiendo el punto en las respuestas. ¿Podría alguien darme una aclaración de que tenemos el modo sin cabeza NATIVO para que la aplicación de electrones se ejecute en el CI o no?

@hitliubo Chrome tiene una --headless , pero solo funciona si no estás usando complementos como Flash o el lector de PDF. Si es así , la respuesta es un no afirmativo en este momento. Si no es así , puede pasar esa marca (junto con --disable-gpu si es necesario; arreglaron esta implicación faltante en las versiones más nuevas de Chrome IIRC) al crear el contexto del navegador y ver si funciona. (Tenga en cuenta que si está usando algo como Nightmare y cae en la segunda categoría, realmente debería presentar un problema en el repositorio respectivo de ese proyecto si aún no hay uno).

Incluso si no puede usar --headless (o si no funciona), hay opciones:

• Windows: a menos que esté usando algo oscuro, siempre tendrá un contexto de ventana para renderizar. Windows Server 2016 eliminó el soporte de GUI predeterminado, pero aún admite la creación de ventanas de GUI, y AFAICT debería admitir lo mínimo para las pruebas de Selenium.
• macOS: siempre tendrá una GUI aquí (y, por lo tanto, tendrá un contexto de ventana para renderizar). Apple no ofrece una versión que no lo haga.
• Linux: xvfb es un servidor X sin cabeza que está disponible para casi todas las distribuciones comunes de Linux (y me refiero a "común" bastante libremente aquí). Si está utilizando Travis, tienen instrucciones sobre cómo agregarlo a su proyecto .

@isiahmeadows Gracias por tu información. Actualmente tengo una aplicación web ejecutándose en el navegador y con Chrome / Firefox siempre puedo agregar --headless para las pruebas sin cabeza. Recientemente, nos gustaría convertirlo a la aplicación Electron y probé con --headless, que no funciona en mi macOS. Ahora conozco tu razón. ¡Gracias!

En realidad, no me gusta la solución de xvfb ya que no es nativa. Sin embargo, dado que no admitimos los nativos sin cabeza, supongo que debo intentarlo.

FYI - Ahora estoy usando capibara para la prueba.

Eso sería genial (y)

¿Hay alguna actualización sobre esto?

Me redirigieron aquí desde una publicación sobre renderizado directamente a un búfer de marco de Linux, pero esto parece estar enfocado en pruebas sin cabeza. ¿Se ha realizado algún progreso al renderizar directamente a un búfer de fotogramas _real_?

@quinn Estoy bastante seguro de que necesitará un servidor X, aunque puede ejecutar X11 (Xorg) en un búfer de marco si lo desea (consulte: https://www.x.org/releases/current/ doc / man / man4 / fbdev.4.xhtml).

_Editar:_

En realidad, después de analizar esto un poco más, esto también se puede lograr mediante el uso de ozono. (https://github.com/jakwu/ozone-fb)

Agregar ozono también permitiría la compatibilidad con wayland, otra característica que le falta a electron, ya que la mayoría de las distribuciones de Linux han migrado a esta.

Según la descripción de ozone-fb y el comentario de @isiahmeadows , parece que la aceleración de la GPU no funciona si se procesa en un búfer de fotogramas.

@trusktr Ese es un comentario de 2 años. Recomendaría no tomar mi comentario como autoritario, ya que eso podría haber cambiado (no lo he verificado desde entonces).

Agrego lib sin cabeza al electrón y llamo al HeadlessShellMain。
correr:

e run  --headless --enable-logging --v=2 --disable-gpu --screenshot  http://192.168.50.206

entonces muestra:

Running "/home/a/dev0/e9.2.1/src/out/ReleaseSym0/electron --headless --enable-logging --v=2 --disable-gpu --screenshot http://192.168.50.206:8889"
[1028/172650.483932:INFO:cpu_info.cc(53)] Available number of cores: 4
[1028/172650.484061:VERBOSE1:zygote_main_linux.cc(217)] ZygoteMain: initializing 0 fork delegates
[1028/172650.484400:INFO:cpu_info.cc(53)] Available number of cores: 4
[1028/172650.484465:VERBOSE1:zygote_main_linux.cc(217)] ZygoteMain: initializing 0 fork delegates
[1028/172650.493514:VERBOSE1:webrtc_internals.cc(119)] Could not get the download directory.
[1028/172650.494623:VERBOSE1:proxy_config_service_linux.cc(500)] All gsettings tests OK. Will get proxy config from gsettings.
[1028/172650.494764:VERBOSE1:proxy_config_service_linux.cc(1261)] Obtained proxy settings from annotation hash code 11258689
[1028/172650.494873:VERBOSE1:proxy_config_service_linux.cc(500)] All gsettings tests OK. Will get proxy config from gsettings.
[1028/172650.494919:VERBOSE1:proxy_config_service_linux.cc(1261)] Obtained proxy settings from annotation hash code 11258689
[1028/172650.504033:VERBOSE1:sandbox_linux.cc(69)] Activated seccomp-bpf sandbox for process type: renderer.
[1028/172650.505596:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.511468:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.524408:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.524916:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.525173:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.525963:VERBOSE1:sandbox_linux.cc(69)] Activated seccomp-bpf sandbox for process type: gpu-process.
[1028/172650.526373:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.528735:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.531839:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.535051:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[1028/172650.550076:VERBOSE1:configured_proxy_resolution_service.cc(873)] PAC support disabled because there is no system implementation
[1028/172650.550312:VERBOSE1:configured_proxy_resolution_service.cc(873)] PAC support disabled because there is no system implementation
[1028/172650.550923:VERBOSE1:network_delegate.cc(32)] NetworkDelegate::NotifyBeforeURLRequest: http://192.168.50.206:8889/
[1028/172650.575829:VERBOSE1:url_loader.cc(418)] To buffer: http://192.168.50.206:8889/
[1028/172650.580122:VERBOSE1:v8_context_snapshot.cc(153)] A context is created from snapshot for main world
[1028/172650.587399:VERBOSE1:v8_context_snapshot.cc(153)] A context is created from snapshot for main world
[1028/172650.595294:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[1028/172650.612295:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[1028/172650.676553:INFO:headless_shell.cc(620)] Written to file screenshot.png.

¿Eso significa que se ha implementado sin cabeza?

@ bigben0123 ¡ eso es interesante y muy emocionante! Entonces, ¿ha compilado su propia versión de electrón incorporando la capa sin cabeza de cromo?

¿Ha probado en un entorno sin X en Linux para ver si funciona?

Cuando chromium se ejecuta en modo sin cabeza, los subprocesos de renderizado se inician con el indicador de paso a través: sin cabeza (puede ver si usa 'ps args' de la memoria). ¿Te está pasando esto?

(Curiosamente con electron actualmente si intenta comenzar con, sin cabeza, la bandera no se pasa a los procesos de renderizado, sino al proceso de GPU).

@ bigben0123 ¡ eso es interesante y muy emocionante! Entonces, ¿ha compilado su propia versión de electrón incorporando la capa sin cabeza de cromo?

¿Ha probado en un entorno sin X en Linux para ver si funciona?

Cuando chromium se ejecuta en modo sin cabeza, los subprocesos de renderizado se inician con el indicador de paso a través: sin cabeza (puede ver si usa 'ps args' de la memoria). ¿Te está pasando esto?

(Curiosamente con electron actualmente si intenta comenzar con, sin cabeza, la bandera no se pasa a los procesos de renderizado, sino al proceso de GPU).

Sí, lo ejecuto en ubuntu, que simplemente se inicia en el modo de comando de usuario.
Se ha pasado sin cabeza:

electron --headless --enable-logging --v=2 --disable-gpu -print-to-pdf http://www.google.com
electron --type=zygote --no-zygote-sandbox --enable-logging --headless --v=2 --headless
electron --type=zygote --enable-logging --headless --v=2 --headless
electron --type=zygote --enable-logging --headless --v=2 --headless
electron --type=gpu-process --field-trial-handle=15536072708541054845,15522400966085077738,131072 --enable-logging --headless --v=2 --headless --gpu-preferences=MAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAQAAAAAAAAAAAAAAAAAAAACAAAAAAAAAA= --use-gl=swiftshader-webgl --override-use-software-gl-for-tests --enable-logging --v=2 --shared-files
electron --type=utility --field-trial-handle=15536072708541054845,15522400966085077738,131072 --lang=en-US --service-sandbox-type=network --enable-logging --use-gl=swiftshader-webgl --v=2 --headless --enable-logging --v=2 --shared-files=v8_snapshot_data:100
electron --type=renderer --allow-pre-commit-input --enable-logging --v=2 --field-trial-handle=15536072708541054845,15522400966085077738,131072 --disable-databases --disable-gpu-compositing --lang=en-US --headless --lang=en-US --num-raster-threads=2 --enable-main-frame-before-activation --renderer-client-id=4 --shared-files=v8_snapshot_data:100
electron --type=broker

@ bigben0123 ¿tienes tus cambios en alguna parte? Incluso si esto no se convierte en un núcleo de electrones por alguna razón, me encantaría poder usarlo.

Esta confirmación solo fusiona la biblioteca sin cabeza de Chrome con electron y puede usarla de la misma manera que Chrome.
https://github.com/bigben0123/electron/commit/b6cad8993d68d39f1732aa6ed5ece0135b9ae0c8

En lo que a mí respecta, chrome y headless tienen una implementación de capa de contenido diferente. Al igual que el shell de dos navegadores, si comienzas sin cabeza, no tiene nada que ver con Chrome, solo excepto que comienzas con "chrome --headless".

El objetivo del headless es "Minimizar el número de cambios invasivos o específicos de headless (por ejemplo, #ifdefs) en el código base de Chromium".

Por lo tanto, es difícil implementar que el electrón no tenga cabeza para eliminar xvfb. Podemos dejar que electron soporte sin cabeza, pero no puede ejecutar aplicaciones electron.

Podemos usar la implementación sin cabeza para reemplazar los electrones para obtener una nueva rama sin cabeza.

eliminar la dependencia de electron / BUILD.gn:

      "//ui/events/devices/x11",
      "//ui/events/platform/x11",
      "//ui/gtk"  #all of gkt related

    if (use_x11) {
      deps += [
        "//ui/gfx/x",
        "//ui/gtk:x",
      ]
    }
    configs += [ ":gio_unix" ]
    configs += [ "//build/config/linux:x11" ]

reemplazar con:
"// interfaz de usuario / pantalla",
"// ui / eventos / dispositivos",