Electron: Versão sem cabeça para teste

Usando a janela oculta do navegador, o atom-shell pode realmente fazer o que o phantomjs faz, o exemplo na página inicial do phantomjs pode ser traduzido para o 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);

É claro que podemos precisar adicionar mais algumas APIs para fins de teste de automação.

O único problema é que em vez de desenhar em um buffer virtual, o atom-shell na verdade desenha a página em uma janela real, isso exigiria um ambiente gráfico, no Windows e no OS X não importa, no entanto, no Linux temos que usar xvfb para fornecer um servidor X para atom-shell. Isso ocorre por design na API de conteúdo do Chromium, portanto, não podemos fazer nada para remover a dependência do ambiente gráfico.

Tive sucesso com isso recentemente (usando Xvfb em um servidor Ubuntu). Meu caso de uso é capturar imagens de páginas com modelo. Na verdade, descobri que o atom-shell por meio do Xvfb no servidor (um m3-large) tem melhor desempenho do que no meu Macbook pro local. Isso me levou a querer fazer o atom-shell funcionar por meio do Xvfb no osx também.

Como o osx vem com o Xvfb, essa parte é fácil. Posso fazer com que o atom-shell use um display Xvfb no osx? Usar a variável DISPLAY env padrão como eu faço no linux não está funcionando. Talvez o libchromiumcontent não saiba como usar o X11 ao ser executado no Darwin?

Xvfb só funciona para aplicativos escritos para o ambiente X11, no OS X atom-shell usa Cocoa para exibição, o que eu acredito não pode funcionar com Xvfb.

Sim, meio que juntamos isso. Provavelmente não é realmente uma maneira de compilar a partir do código-fonte para o X11?

@zcbenz atualmente não é possível criar um BrowserWindow que seja maior do que a resolução atual no OS X, mesmo se você usar new BrowserWindow({show: false});

@FWeinb você pode abrir um tíquete específico separado para os

Criado # 475

Estou fechando isso porque não há como desenhar uma página sem realmente criar um widget nativo no Chromium, e acho que eles nunca permitirão isso.

Para testes automáticos, oferecemos suporte ao Selenium.

O projeto CEF tem suporte para renderização fora da tela , então você pode desenhar a tela em um buffer em vez de uma janela. Em relação ao servidor X para Linux, parece que há uma maneira de trabalhar sem ele adicionando um destino chamado Ozone (veja a discussão aqui ).

@etiktin Obrigado pela informação! Estou reabrindo isso, pois existe uma implementação existente sobre como fazê-lo.

Nós realmente poderíamos usar o suporte para isso. Recentemente substituímos o Phantom pelo Electron no Nightmare e adoramos até agora, mas não funciona fora da caixa no Linux.

Aqui está o que precisamos fazer agora para fazê-lo funcionar: https://github.com/segmentio/nightmare/issues/224#issuecomment -141575361

Recebi a tarefa de automatizar o comportamento do usuário para um de nossos aplicativos da web que será convertido em um aplicativo Electron de desktop independente. Antes de nossa empresa decidir fazer essa mudança, criamos objetos de página usando o driver da web Chrome e interagimos com o aplicativo da web invocando botões / menus suspensos / caixas de texto usando os seletores css. Existe uma maneira de fazer isso com um aplicativo da Web que é empacotado com o shell Electron? A empresa planeja usar as opções da barra de menus para invocar certas funcionalidades e eu tentei obter as opções padrão da barra de menus, como Arquivo / Editar / Ajuda usando o driver JavaScript, sem sucesso. Existem exemplos de como fazer isso?

https://github.com/segmentio/nightmare/issues/224#issuecomment -141575361 parece que o snippet de @matthewmueller funciona no Linux: +1:

Alguém conseguiu um teste sem cabeça trabalhando no SuSE? Especificamente SLES?

@fritx O mesmo usado para SlimerJS, mas NÃO é o modo headless.

@fritx é o que @zcbenz estava dizendo, você tem que ter o Xvfb rodando. Tanto o CEF3 quanto o Chromium Content Shell dependem atualmente do Xlib. Mas com a conclusão do Ozônio: https://www.chromium.org/developers/design-documents/ozone
você seria capaz de fornecer qualquer E / S de baixo nível.

Aparentemente, há um bug mestre no próprio Chromium: https://code.google.com/p/chromium/issues/detail?id=546953

Isto é interessante:

Data: Quarta, 02 de dezembro 15:35:21 de 2015

[headless] Esqueleto inicial de headless / public /

Crie um esboço da futura API Headless.

O ChromeDriver funciona com elétron?

Um binário sem cabeça que não requer xvfb abriria novos ambientes, como AWS Lambda - me inscreva!

@Vanuan Você já ouviu falar em Nightmare ? Isso pode ajudá-lo se não houver nada de que você precise especificamente do ChromeDriver.

Tem driver Capybara / Selenium?

+1

Estou um pouco confuso. Existe um modo sem cabeça? Podemos fazer isso com eficácia com BrowserWindow ({show: false})? Isso seria muito útil para mim, estou tentando fazer isso funcionar para que possamos criar componentes da web do lado do servidor: https://github.com/scramjs/scram-markup-engine

Acho que respondi minha própria pergunta enquanto olhava ao redor. O Electron não oferece suporte nativo a um modo sem cabeça sofisticado. Nightmare parece permitir algo parecido, mas você ainda precisa fazer algumas configurações para fazê-lo funcionar em certos sistemas sem ambiente gráfico. O Electron também pode fazer isso se você usar o BrowserWindow ({show: false}), mas você deve usar o xvfb para fornecer um ambiente gráfico em sistemas Linux sem periféricos (o que não parece tão ruim, na verdade). Corrija-me se eu estiver errado e marque este recurso com +1.

Com o novo projeto de cromo sem cabeça [1], seria possível fazer elétron sem cabeça sem usar o xvfb?

Acredito que a limitação atual seja com libchromium? Os caras do Chrome consertaram isso?

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

Há um fórum relacionado: https://groups.google.com/a/chromium.org/forum/#!forum/headless -dev

Algum progresso nisso? Isso seria muito útil para testar

segmentio / nightmare é perfeito para isso. Simplesmente:

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

@amilajack Para casos simples, como executar testes de unidade Mocha simples sem cabeça, Nightmare seria como usar uma marreta de 20 libras para dirigir em um pequeno prego (leia-se: exagero massivo). É uma biblioteca de automação de navegador totalmente desenvolvida, com baterias incluídas que pode não apenas realizar a navegação e entrada básicas, mas até mesmo salvar arquivos HTML e PDF em disco ou fazer capturas de tela. Exatamente 0% dessa biblioteca deve ser necessária para executar testes de unidade simples.

@isiahmeadows @mcolyer disse que queria uma versão sem cabeça do atom-shell que pudesse ser usado como um substituto '. O elétron é exatamente isso, com recursos extras.

Sim, mas por que você precisa de açúcar para o que não usa? (Eu estava me referindo a todo o açúcar - você poderia, teoricamente, reimplementar o Electron em sua totalidade com apenas ligações vanilla Node + OpenGL).

O caso de uso mais comum para navegadores sem cabeça são coisas para as quais mocha-phantomjs e Karma já existem - executar testes de unidade de navegador a partir da CLI. A maioria das pessoas usa xvfb, um servidor X sem cabeça, no Travis se precisam testar o Firefox / Chrome, porque ele não tem um servidor X em execução, e você poderia até mesmo executar o Electron com ele, mas navegadores sem cabeça como PhantomJS e SlimerJS não não preciso de um servidor X. Electron + Nightmare ainda precisa de algum tipo de servidor X (mesmo que seja xvfb) para rodar, e este problema está pedindo que essa dependência seja removida, mas provavelmente não acontecerá até que o próprio Chromium possa ficar sem cabeça e essas mudanças propagadas para libchromiumcontent .

Headless agora está no Chrome 59: https://www.chromestatus.com/features/5678767817097216

@sindresorhus @zcbenz Essa mudança no Chromium fará alguma diferença aqui?

O elétron já é maravilhoso, e um modo sem cabeça o tornaria ainda melhor!

(Também seria útil para Nightmare , que é baseado no Electron)

Consegui obter Xvfb trabalhando em lambda, o que pode ser útil para testes baseados em lambda ... https://github.com/nisaacson/aws-lambda-xvfb

Alguma palavra sobre quando o Electron suportará o verdadeiro headless? Podemos contar com que isso aconteça? Mal posso esperar para encerrar o xvfb.

@lastmjs , você conseguiu fazer o Electron rodar no AWS Lambda baseado em xvfb?

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

Obrigado pelo seu comentário @MrSaints. Na verdade, estou depurando este repositório há várias horas, pois não consigo fazer com que nightmare seja executado. Funciona para você?

@zcbenz FYI chrome 59 terá suporte para modo headless https://www.chromestatus.com/features/5678767817097216

@schickling, consulte https://github.com/JohannesHoppe/nightmare-html2pdf - pesadelo no docker, com Xvfb

Obrigado @JohannesHoppe , coloquei o Nightmare trabalhando no Docker com Xvfb, mas quero executá-lo no AWS Lambda.

Abri um problema para substituir o Electron pelo Chrome sem cabeça no Nightmare: https://github.com/segmentio/nightmare/issues/1092

@schickling, tente isso: https://github.com/dimkir/nightmare-lambda-tutorial

Peço desculpas se esta resposta for respondida em outro lugar, mas não consigo encontrar uma resposta concreta. Em seu comentário marcado com +1 acima, @sandstrom apontou que o headless agora está disponível no Chrome 59.

O suporte para a bandeira sem cabeça do Chrome está no roteiro de desenvolvimento do Electron? Parece que esta é uma "vitória" potencialmente grande para a Electron, pois torna possível o uso sem cabeça real.

Eu concordo com @rinogo. Ter uma opção headless para elétron será muito útil para executar testes em sistemas ci e em dev box sem a necessidade de exibição virtual e controle da máquina. Também estou interessado em conhecer o roteiro para o elétron e possivelmente contribuir.

Xvfb é irritante, será ótimo se Electron suportar true headless!

xvfb-talvez nesse meio tempo

Há um novo artigo do Google: https://developers.google.com/web/updates/2017/04/headless-chrome

Chega em breve.

Parece que o Chrome 59 está no canal estável agora. Quais são as próximas etapas para oferecer suporte a headless no Electron?

Por favor, torne isso uma realidade - ao fazer isso e habilitar o NightmareJS para executar o Electron sem cabeça, você acabará eliminando cerca de um terço de todos os casos de uso do Selenium. *

* Sendo hiperbólico, mas também não realmente

@aendrew Eu acho que NightmareJS poderia ser _rewritten_ para usar / incluir um back-end de CDP, ao invés de confundir com a criação de Electron (com uma filosofia: _construir aplicativos de plataforma cruzada para https://github.com/cyrus-and/chrome-remote-interface

@MrSaints Eu não invejo os mantenedores; eles _já_ terminaram de convertê-lo do PhantomJS há um ano. No entanto, talvez seja uma boa motivação para tornar a camada do navegador do Nightmare plugável ...

Independentemente disso, o ponto sobre o Electron ser orientado para desktop é bem entendido.

@aendrew @MrSaints Correndo o risco de divulgar minha ignorância ... Quão difícil é essa mudança (apoiar a sinalização headless ) de implementar? Não tenho certeza de como o Electron faz interface com / estende o Chromium, mas me parece que as etapas para implementar isso são:

1. Atualize o Electron's Chromium para a versão 59+.
2. Forneça o parâmetro de configuração / sinalização de linha de comando headless .
3. Outras coisas que obviamente não estou explicando. :)

Acho que o que estou dizendo é que, com headless agora disponível no Chromium, implementar um modo sem cabeça (por exemplo, para NightmareJS) parece ser relativamente simples. É verdade que uma versão de uso geral do Electron pode levar algum tempo para resolver certos casos de uso. No entanto, para gerar uma construção projetada para algo como NightmareJS, deve ser bastante simples, certo?

Se eu tivesse uma necessidade imediata de melhorias de velocidade, eu pularia e tentaria. No entanto, ainda estamos nos saindo com o NightmareJS como está, então estamos bem por enquanto.

Mesmo assim, obrigado aos mantenedores de todos esses projetos por suas contribuições e trabalho árduo! :)

Em relação ao NightmareJS: No momento, estamos trabalhando em uma versão do Nightmare construída no Chrome sem cabeça, capaz de ser executado em ambientes sem servidor, como o AWS Lambda. Vamos abrir o código em breve @graphcool. 🚀

@schickling, isso vai ser incrível!

Uma coisa a ter em mente com --headless no Chrome é que ele desativa o suporte para todos os plug-ins. Portanto, se você precisa de flash (que pode ser feito com elétron / pesadelo) ou o visualizador de PDF, etc, --headless não é para você e você vai querer usar xvfb.

Mal posso esperar para executar o Electron no AWS Lambda ... acho

Amen @lastmjs Amen

E quanto a esta solução?
https://github.com/dimkir/nightmare-lambda-tutorial

Ainda não tentei ainda

@xplodedthemes usa uma versão pré-compilada de xvfb

Plugue sem vergonha: https://github.com/joelgriffith/navalia. Isso foi construído em cima do Chrome sem cabeça para testes funcionais e muito mais. Inclui alguns recursos interessantes, como paralelizar várias tarefas, um front-end GraphQL e muito mais.

Congratulo-me com quaisquer relações públicas / questões / comentários!

Ei pessoal! Desculpe por deixá-los todos esperando ... 💤

Acabamos de abrir o código-fonte do Chromeless . É baseado no headless Chrome e funciona tanto localmente quanto no AWS Lambda. A API é muito semelhante ao NightmareJS.

Você pode experimentar aqui: https://chromeless.netlify.com

O Chromeless acabou de substituir o Nightmare? O Chromeless tem um longo caminho a percorrer antes de alcançar o Pesadelo.

Nós o usamos como um substituto para o Nightmare, pois precisamos da capacidade de executar vários testes ao mesmo tempo.

Pergunta (talvez não seja bom para este tópico): você está pensando em fazer a funcionalidade de PDF funcionar? Em caso afirmativo, isso poderia nos salvar uma tonelada de dor de cabeça (e custo).

Uau, isso é incrível. Bom trabalho pessoal!

@zcbenz parece que surgiram soluções para isso: posso fechar?

Umm, esse problema ainda é extremamente válido. Todas as "soluções" envolvem sair completamente do Pesadelo.

Concordo totalmente com @keithkml - as soluções, embora bem intencionadas (obrigado!), Têm sido mais como "alternativas" até que uma solução real seja fornecida. Nesse sentido, alguém aqui tem experiência suficiente para responder às perguntas que fiz em meu comentário anterior ? (E novamente, desculpe minha ignorância! :))

Ainda não entendi as respostas. Alguém poderia me esclarecer se temos o modo headless NATIVO para que o aplicativo de elétrons seja executado no CI ou não?

@hitliubo Chrome tem um --headless , mas só funciona se você não estiver usando plug-ins como Flash ou leitor de PDF. Se estiver , a resposta é afirmativa não no momento. Se você não for, você poderia passar essa bandeira (junto com --disable-gpu , se necessário - que fixa essa implicação faltando em versões mais recentes do Chrome IIRC) ao criar o contexto do navegador e ver se isso funciona. (Observe que se você estiver usando algo como Nightmare e cair na segunda categoria, você realmente deve registrar um problema no respectivo repositório do projeto, se ainda não houver um.)

Mesmo se você não puder usar --headless (ou se não funcionar), existem opções:

• Windows: a menos que esteja usando algo obscuro, você sempre terá um contexto de janela para renderizar. O Windows Server 2016 abandonou o suporte de GUI padrão, mas ainda oferece suporte à criação de janelas de GUI, e AFAICT deve oferecer suporte ao mínimo para testes Selenium.
• macOS: você sempre terá uma GUI aqui (e, portanto, terá um contexto de janela para renderizar). A Apple não oferece uma versão que não o faça.
• Linux: xvfb é um servidor X sem cabeça que está disponível para quase todas as distros Linux comuns (e quero dizer "comum" de forma bastante vaga aqui). Se você estiver usando o Travis, eles têm instruções sobre como adicioná-lo ao seu projeto .

@isiahmeadows Obrigado por suas informações. Atualmente eu tenho um aplicativo da web rodando no navegador e com o Chrome / Firefox eu sempre poderia adicionar --headless para o teste headless. Recentemente, gostaríamos de convertê-lo para o aplicativo Electron e tentei com --headless, que não funciona no meu macOS. Agora eu conheço a razão. Obrigado!

Na verdade não gosto da solução do xvfb porque não é nativa. No entanto, como não oferecemos suporte para o uso de cabeçote nativo, acho que preciso fazer uma tentativa.

FYI - Agora estou usando capivara para o teste.

Isso seria ótimo (y)

Existe alguma atualização sobre isso?

Fui redirecionado aqui de um post sobre a renderização diretamente para um buffer de quadros do Linux, mas parece estar focado em testes sem cabeça. Algum progresso foi feito renderizando diretamente para um buffer de quadro _real_?

@quinn Tenho quase certeza de que você precisará de um servidor X, embora possa executar o X11 (Xorg) em um frame-buffer, se desejar (consulte: https://www.x.org/releases/current/ doc / man / man4 / fbdev.4.xhtml).

_Editar:_

Na verdade, depois de examinar isso um pouco mais, isso também pode ser obtido usando o ozônio. (https://github.com/jakwu/ozone-fb)

Adicionar ozônio também permitiria suporte a wayland, outro recurso que o elétron está perdendo, visto que a maioria das distribuições de Linux já migrou para ele.

Com base na descrição do comentário ozone-fb e @isiahmeadows , parece que a aceleração da GPU não funciona se renderizar para um buffer de quadro.

@trusktr Esse é um comentário de 2 anos. Eu recomendo não considerar meu comentário como oficial, pois isso poderia ter mudado (eu não verifiquei desde então).

Eu adiciono lib sem cabeça ao elétron e chamo o HeadlessShellMain。
corre:

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

então mostra:

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.

Isso significa que o headless foi implementado?

@ bigben0123 isso é interessante e muito empolgante! Então você compilou sua própria versão do elétron incorporando a camada sem cabeça do cromo?

Você testou em um ambiente sem X no Linux para ver se funciona?

Quando o chromium é executado no modo headless, os subprocessos de renderização são iniciados com o sinalizador —headless passado (você pode ver que você usa 'ps args' da memória). Isso está acontecendo para você?

(Estranhamente com elétron atualmente, se você tentar iniciá-lo com - sem cabeça, o sinalizador não é passado para os processos de renderização, mas para o processo de GPU.)

@ bigben0123 isso é interessante e muito empolgante! Então você compilou sua própria versão do elétron incorporando a camada sem cabeça do cromo?

Você testou em um ambiente sem X no Linux para ver se funciona?

Quando o chromium é executado no modo headless, os subprocessos de renderização são iniciados com o sinalizador —headless passado (você pode ver que você usa 'ps args' da memória). Isso está acontecendo para você?

(Estranhamente com elétron atualmente, se você tentar iniciá-lo com - sem cabeça, o sinalizador não é passado para os processos de renderização, mas para o processo de GPU.)

Sim, eu o executo no Ubuntu, que apenas inicia no modo de comando do usuário.
Headless foi aprovado:

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 você tem suas alterações em algum lugar? Mesmo que isso não chegue ao núcleo do elétron por algum motivo, eu adoraria poder usá-lo.

Este commit apenas mescla o lib headless do chrome com o electron e você pode usá-lo da mesma forma que o chrome.
https://github.com/bigben0123/electron/commit/b6cad8993d68d39f1732aa6ed5ece0135b9ae0c8

No que me diz respeito, chrome e headless têm implementações de camadas de conteúdo diferentes. Como dois shell de navegador, se você iniciar o headless, não terá nada a ver com o Chrome, apenas a não ser que você comece com "chrome --headless".

O objetivo do headless é “Minimizar o número de alterações invasivas ou específicas do headless (por exemplo, #ifdefs) na base de código do Chromium“.

Portanto, é difícil implementar que o elétron não tem cabeça para remover o xvfb. Podemos apenas permitir que o elétron suporte sem cabeça, mas você não pode executar aplicativos de elétrons.

Podemos usar a implementação sem cabeça para substituir o elétron para obter um novo ramo sem cabeça.

remova a dependência do elétron / 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" ]

substituir com:
"// ui / display",
"// ui / events / devices",