Electron: Version sans tête pour les tests

En utilisant une fenêtre de navigateur cachée, atom-shell peut réellement faire ce que fait phantomjs, l'exemple de la page d'accueil de phantomjs pourrait être traduit en 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);

Bien sûr, nous devrons peut-être ajouter d'autres API à des fins de test d'automatisation.

Le seul problème est qu'au lieu de dessiner dans un tampon virtuel, atom-shell dessine en fait la page dans une vraie fenêtre, cela nécessiterait un environnement graphique, sur Windows et OS X cela n'a pas d'importance, cependant sur Linux nous devons utiliser xvfb fournir un serveur X pour atom-shell. C'est par conception dans l'API de contenu de Chromium, nous ne pouvons donc rien faire pour supprimer la dépendance de l'environnement graphique.

J'ai eu du succès récemment (en utilisant Xvfb sur un serveur Ubuntu). Mon cas d'utilisation consiste à capturer des captures d'écran de pages modélisées. En fait, j'ai trouvé que atom-shell via Xvfb sur le serveur (un m3-large) a de meilleures performances que sur mon Macbook pro local. Cela m'a amené à vouloir faire fonctionner atom-shell via Xvfb dans osx également.

Comme osx est livré avec Xvfb, cette partie est facile. Puis-je faire en sorte qu'atom-shell utilise un affichage Xvfb dans osx? L'utilisation de la variable d'environnement standard DISPLAY comme je le fais sous Linux ne fonctionne pas. Peut-être que libchromiumcontent ne sait pas comment utiliser X11 lorsqu'il s'exécute dans Darwin ?

Xvfb ne fonctionne que pour les applications écrites pour l'environnement X11, sur OS X, atom-shell utilise Cocoa pour l'affichage, ce qui, je pense, ne peut pas fonctionner avec Xvfb.

Ouais un peu mettre ça ensemble. Probablement pas vraiment un moyen de compiler à partir des sources pour X11 à la place ?

@zcbenz, il n'est actuellement pas possible de créer un BrowserWindow plus grand que la résolution actuelle sur OS X, même si vous utilisez new BrowserWindow({show: false});

@FWeinb pouvez-vous ouvrir un ticket spécifique séparé pour ce qui précède ?

Créé #475

Je ferme ceci car il n'y a aucun moyen de dessiner une page sans réellement créer un widget natif dans Chromium, et je ne pense pas qu'ils le permettront jamais.

Pour les tests automatiques, nous prenons en charge Selenium.

Le projet CEF prend en charge le rendu hors écran , vous pouvez donc dessiner l'écran dans un tampon au lieu d'une fenêtre. Concernant le serveur X pour Linux, il semble qu'il existe un moyen de travailler sans lui en ajoutant une cible appelée Ozone (voir la discussion ici ).

@etiktin Merci pour l'information ! Je rouvre ceci car il existe une implémentation existante sur la façon de le faire.

Nous pourrions vraiment utiliser le support pour cela. Nous avons récemment remplacé Phantom par Electron dans Nightmare et nous l'aimons jusqu'à présent, mais cela ne fonctionne pas immédiatement sous Linux.

Voici ce que nous devons faire dès maintenant pour que cela fonctionne : https://github.com/segmentio/nightmare/issues/224#issuecomment -141575361

On m'a confié la tâche d'automatiser le comportement des utilisateurs pour l'une de nos applications Web qui sera convertie en une application Electron de bureau autonome. Avant que notre entreprise ne décide de faire cette démarche, nous avons créé des objets de page à l'aide du pilote Web Chrome et interagi avec l'application Web en appelant des boutons/listes déroulantes/zones de texte à l'aide des sélecteurs CSS. Existe-t-il un moyen de le faire avec une application Web enveloppée avec le shell Electron? La société prévoit d'utiliser les options de la barre de menus pour invoquer certaines fonctionnalités et j'ai essayé d'accéder aux options de la barre de menus par défaut telles que Fichier/Modifier/Aide à l'aide du pilote JavaScript sans succès. Existe-t-il des exemples sur la façon de procéder?

https://github.com/segmentio/nightmare/issues/224#issuecomment -141575361 il semble que l'extrait de

Est-ce que quelqu'un a fait des tests sans tête sur SuSE ? Spécifiquement SLES ?

@fritx Le même que celui utilisé pour SlimerJS, mais ce n'est PAS le mode sans tête.

@fritx c'est ce que @zcbenz disait, vous devez avoir Xvfb en cours d'exécution. CEF3 et Chromium Content Shell dépendent actuellement de Xlib. Mais avec l'achèvement d'Ozone : https://www.chromium.org/developers/design-documents/ozone
vous seriez en mesure de fournir n'importe quelle E/S de bas niveau.

Apparemment, il y a un bug principal dans Chromium lui-même : https://code.google.com/p/chromium/issues/detail?id=546953

C'est intéressant:

Date : mer. 02 déc. 15:35:21 2015

[headless] Squelette initial de headless/public/

Créer un aperçu de la future API Headless.

ChromeDriver fonctionne-t-il avec des électrons ?

Un binaire sans tête qui ne nécessite pas de xvfb ouvrirait de nouveaux environnements tels qu'AWS Lambda - inscrivez-moi !

@Vanuan Avez-vous entendu parler de Nightmare ? Cela pourrait vous aider s'il n'y a rien dont vous avez spécifiquement besoin de ChromeDriver.

A-t-il le pilote Capybara/Selenium ?

+1

Je suis un peu confus. Existe-t-il un mode sans tête ? Pouvons-nous le faire efficacement avec BrowserWindow({show : false}) ? Cela me serait très utile, j'essaie de faire fonctionner cela afin que nous puissions créer des composants Web côté serveur : https://github.com/scramjs/scram-markup-engine

Je pense avoir répondu à ma propre question en regardant autour de moi. Electron ne supporte pas nativement un mode sans tête sophistiqué. Nightmare semble permettre quelque chose comme ça, mais vous devez encore faire une certaine configuration pour le faire fonctionner sur certains systèmes sans environnement graphique. Electron peut également le faire si vous utilisez BrowserWindow({show: false}), mais vous devez utiliser xvfb pour fournir un environnement graphique sur les systèmes Linux sans tête (ce qui ne semble pas trop mal en fait). Corrigez-moi si je me trompe, et +1 à cette fonctionnalité.

Avec le nouveau projet sans tête au chrome [1], serait-il possible de fabriquer des électrons sans tête sans utiliser xvfb ?

Je crois que la limitation actuelle était avec libchromium? Les gars de Chrome ont-ils corrigé cela?

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

Il existe un forum associé : https://groups.google.com/a/chromium.org/forum/#!forum/headless -dev

Des progrès à ce sujet ? Ce serait vraiment utile pour tester

segmentio/nightmare est parfait pour cela. Simplement:

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

@amilajack Pour des cas simples comme l'exécution de tests unitaires Mocha simples sans tête, Nightmare reviendrait à utiliser un marteau de 20 livres pour enfoncer un petit clou (lire: surpuissance massive). Il s'agit d'une bibliothèque d'automatisation de navigateur à part entière, avec piles incluses, qui peut non seulement effectuer une navigation et une saisie de base, mais même enregistrer des fichiers HTML et PDF sur le disque ou prendre des captures d'écran. Exactement 0% de cette bibliothèque devrait être nécessaire pour exécuter des tests unitaires simples.

@isiahmeadows @mcolyer a déclaré qu'il voulait une version sans tête d'atom-shell qui pourrait être utilisée en remplacement ». Electron est à peu près exactement cela avec des fonctionnalités supplémentaires.

Oui, mais pourquoi auriez-vous besoin de sucre pour ce que vous n'utilisez pas ? (Je faisais référence à tout le sucre - vous pourriez théoriquement ré-implémenter Electron dans son intégralité avec juste des liaisons vanille + OpenGL).

Le cas d'utilisation le plus courant pour les navigateurs sans tête est des choses comme ce pour quoi mocha-phantomjs et Karma existent déjà - l'exécution de tests unitaires de navigateur à partir de la CLI. La plupart des gens utilisent xvfb, un serveur X sans tête, sur Travis s'ils ont besoin de tester Firefox/Chrome, car il n'y a pas de serveur X en cours d'exécution, et vous pouvez même exécuter Electron avec ça, mais les navigateurs sans tête comme PhantomJS et SlimerJS ne le font pas. t besoin d'un serveur X. Electron + Nightmare a toujours besoin d'un serveur X quelconque (même s'il s'agit de xvfb) pour fonctionner, et ce problème demande la suppression de cette dépendance, mais cela n'arrivera probablement pas tant que Chromium lui-même ne pourra pas devenir sans tête et que ces changements se seront propagés à libchromiumcontent .

Headless est désormais disponible dans Chrome 59 : https://www.chromestatus.com/features/5678767817097216

@sindresorhus @zcbenz Ce changement dans Chromium fera-t-il une différence ici ?

Electron est déjà merveilleux, et un mode sans tête le rendrait encore meilleur !

(Ce serait aussi utile pour Nightmare , qui est basé sur Electron)

J'ai pu faire travailler Xvfb sur lambda, ce qui pourrait être utile pour les tests basés sur lambda... https://github.com/nisaacson/aws-lambda-xvfb

Un mot sur quand Electron supportera le vrai sans tête? Pouvons-nous compter sur cela? J'ai hâte de laisser tomber xvfb.

@lastmjs avez-vous réussi à faire fonctionner Electron sur AWS Lambda basé sur xvfb ?

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

Merci pour votre commentaire @MrSaints. Je débogue en effet ce repo depuis plusieurs heures maintenant car je n'arrive pas à faire fonctionner nightmare . Est-ce que ça marche pour toi?

@zcbenz FYI chrome 59 obtiendra la prise en charge du mode sans tête https://www.chromestatus.com/features/5678767817097216

@schickling voir https://github.com/JohannesHoppe/nightmare-html2pdf -- cauchemar dans docker, avec Xvfb

Merci @JohannesHoppe , j'ai fait travailler Nightmare dans Docker avec Xvfb mais je veux plutôt l'exécuter sur AWS Lambda.

J'ai ouvert un problème pour remplacer Electron par Chrome sans tête dans Nightmare : https://github.com/segmentio/nightmare/issues/1092

@schickling essayez ceci: https://github.com/dimkir/nightmare-lambda-tutorial

Désolé si cela est répondu ailleurs, mais je ne trouve pas de réponse concrète. Dans son commentaire hautement +1 ci-dessus, @sandstrom a souligné que sans tête est désormais disponible dans Chrome 59.

La prise en charge du drapeau sans tête de Chrome figure-t-elle dans la feuille de route de développement d'Electron ? Il semble que ce soit une "victoire" potentiellement énorme pour Electron car cela rend possible une véritable utilisation sans tête.

Je suis d'accord avec @rinogo. Avoir une option sans tête pour l'électron sera très utile pour exécuter des tests dans les systèmes ci et sur la boîte de développement sans avoir besoin d'affichage virtuel et de prendre en charge la machine. Je suis également intéressé de connaître la feuille de route pour les électrons et d'y contribuer éventuellement.

Xvfb est ennuyeux, ce sera génial si Electron prend en charge le vrai sans tête !

xvfb-peut-être en attendant

Il y a un nouvel article de Google : https://developers.google.com/web/updates/2017/04/headless-chrome

Ça arrive bientôt.

On dirait que Chrome 59 est maintenant sur le canal stable. Quelles sont les prochaines étapes pour prendre en charge les appareils sans tête dans Electron ?

S'il vous plaît, faites-en une réalité - en faisant cela et en permettant à NightmareJS d'exécuter Electron sans tête, vous élimineriez finalement comme un tiers de tous les cas d'utilisation de Selenium.*

* Être hyperbolique mais pas vraiment non plus

@aendrew Je pense que NightmareJS pourrait être _réécrit_ pour utiliser / inclure un backend CDP à la place, plutôt que de tergiverser pour rendre Electron (avec une philosophie: _construire des applications de bureau multiplateformes _) sans tête. Voir : https://github.com/cyrus-and/chrome-remote-interface

@MrSaints Je

Quoi qu'il en soit, le fait qu'Electron soit orienté vers le bureau est bien compris.

@aendrew @MrSaints Au risque de headless ) est-il difficile à mettre en œuvre ? Je ne sais pas comment Electron s'interface avec / étend Chromium, mais il me semble que les étapes pour implémenter ceci sont:

1. Mettez à niveau le chrome d'Electron vers la version 59+.
2. Fournissez le paramètre de configuration/indicateur de ligne headless commande
3. D'autres trucs dont je ne compte évidemment pas. :)

Je suppose que ce que je dis, c'est qu'avec headless maintenant disponible dans Chromium, la mise en œuvre d'un mode sans tête (par exemple pour NightmareJS) semble être relativement simple. Certes, une version à usage général d'Electron peut prendre un certain temps pour aplanir certains cas d'utilisation. Cependant, pour générer une version conçue pour quelque chose comme NightmareJS, cela devrait être assez simple, non ?

Si j'avais un besoin immédiat d'amélioration de la vitesse, je me lancerais et je tenterais le coup. Cependant, nous nous débrouillons toujours avec NightmareJS tel quel, donc tout va bien pour le moment.

Quoi qu'il en soit, merci aux mainteneurs de tous ces projets pour leurs contributions et leur travail acharné ! :)

Concernant NightmareJS : nous travaillons actuellement sur une version de Nightmare basée sur Chrome sans tête, même capable de s'exécuter dans des environnements sans serveur tels que AWS Lambda. Nous l'ouvrirons bientôt @graphcool. ??

@schickling ça va être génial !

Une chose à garder à l'esprit avec --headless dans Chrome est qu'il désactive la prise en charge de tous les plugins. Donc, si vous avez besoin de flash (ce qui est faisable avec des électrons/cauchemars) ou de la visionneuse PDF, etc., --headless n'est pas pour vous et vous voudrez utiliser xvfb.

J'ai hâte d'exécuter Electron dans AWS Lambda... je pense

Amen @lastmjs Amen

Et cette solution ?
https://github.com/dimkir/nightmare-lambda-tutorial

Je ne l'ai pas encore essayé par contre

@xplodedthemes utilise une version précompilée de xvfb

Prise sans vergogne : https://github.com/joelgriffith/navalia. Cela a été construit sur Chrome sans tête pour les tests fonctionnels et plus encore. Comprend quelques fonctionnalités intéressantes telles que la parallélisation de plusieurs tâches, un front-end GraphQL, etc.

Je me réjouis de tout PR/problèmes/commentaires !

Salut tout le monde! Désolé de vous faire attendre tous... 💤

Nous venons d'ouvrir Chromeless . Il est basé sur Chrome sans tête et fonctionne à la fois localement et sur AWS Lambda. L'API est assez similaire à NightmareJS.

Vous pouvez l'essayer ici : https://chromeless.netlify.com

Chromeless vient-il de remplacer Nightmare ? Chromeless a un long chemin à parcourir avant de rattraper Nightmare.

Nous l'utilisons en remplacement de Nightmare car nous avons besoin de pouvoir exécuter plusieurs tests en même temps.

Question (peut-être pas bonne pour ce fil) : envisagez-vous de faire fonctionner la fonctionnalité pdf ? Si c'est le cas, cela pourrait nous éviter une tonne de maux de tête (et de coûts).

Wow, c'est incroyable. Bon travail les gars !

@zcbenz, il semble que des solutions aient émergé pour cela : est-il possible de fermer ?

Umm cette question est toujours extrêmement valable. Les "solutions" impliquent toutes de quitter complètement Nightmare.

Tout à fait d'accord avec @keithkml - les solutions, bien que bien intentionnées (merci !), ont plutôt été du type "alternatives" jusqu'à ce qu'une solution réelle soit fournie. Dans ce sens, est-ce que quelqu'un ici a une expertise suffisante pour répondre aux questions que j'ai posées dans mon commentaire précédent ? (Et encore, excusez mon ignorance ! :))

Je ne comprends toujours pas le point dans les réponses. Quelqu'un pourrait-il me préciser si nous avons le mode sans tête NATIVE pour que l'application électronique s'exécute dans le CI ou non?

@hitliubo Chrome a un --headless , mais cela ne fonctionne que si vous n'utilisez pas de plugins comme Flash ou le lecteur PDF. Si vous êtes , alors la réponse est un non affirmatif pour le moment. Si vous ne l' êtes --disable-gpu si nécessaire - ils ont corrigé cette implication manquante dans les nouvelles versions de Chrome IIRC) lors de la création du contexte du navigateur et voir si cela fonctionne. (Notez que si vous utilisez quelque chose comme Nightmare et que vous tombez dans la deuxième catégorie, vous devriez vraiment déposer un problème dans le référentiel respectif de ce projet s'il n'y en a pas déjà.)

Même si vous ne pouvez pas utiliser --headless (ou si cela ne fonctionne pas), il existe des options :

• Windows : à moins que vous n'utilisiez quelque chose d'obscur, vous aurez toujours un contexte de fenêtre dans lequel effectuer le rendu. Windows Server 2016 a abandonné la prise en charge de l'interface graphique par défaut, mais il prend toujours en charge la création de fenêtres d'interface graphique, et AFAICT devrait prendre en charge le strict minimum pour les tests Selenium.
• macOS : vous aurez toujours une interface graphique ici (et donc un contexte de fenêtre dans lequel effectuer le rendu). Apple ne fournit pas de version qui ne le fait pas.
• Linux : xvfb est un serveur X sans tête qui est disponible pour à peu près toutes les distributions Linux courantes (et je veux dire "commun" assez vaguement ici). Si vous utilisez Travis, ils ont des instructions sur la façon de l'ajouter à votre projet .

@isiahmeadows Merci pour vos informations. Actuellement, j'ai une application Web exécutée dans un navigateur et avec chrome/firefox, je pourrais toujours ajouter --headless pour les tests sans tête. Récemment, nous aimerions la convertir en application Electron et j'ai essayé avec --headless qui ne fonctionne pas dans mon macOS. Maintenant je connais ta raison. Merci!

En fait, je n'aime pas la solution de xvfb car elle n'est pas native. Cependant, étant donné que nous ne prenons pas en charge le headless natif, je suppose que je dois l'essayer.

Pour info - Maintenant, j'utilise capybara pour les tests.

Ce serait super (y)

Y a-t-il une mise à jour à ce sujet ?

J'ai été redirigé ici à partir d'un article sur le rendu directement vers un tampon de trame Linux, mais cela semble être axé sur les tests sans tête. Des progrès ont-ils été réalisés pour le rendu directement dans un _real_ frame buffer ?

@quinn Je suis à peu près certain que vous aurez besoin d'un serveur X, bien que vous puissiez exécuter X11 (Xorg) sur un frame-buffer si vous le souhaitez (voir : https://www.x.org/releases/current/ doc/man/man4/fbdev.4.xhtml).

_Éditer:_

En fait, après avoir examiné un peu plus cela, cela peut également être réalisé en utilisant de l'ozone. (https://github.com/jakwu/ozone-fb)

L'ajout d'ozone permettrait également la prise en charge de wayland, une autre fonctionnalité qui manque à l'électron car la majorité des distributions Linux ont depuis migré vers cela.

Sur la base de la description d'ozone-fb et du commentaire

@trusktr C'est un commentaire vieux de 2 ans. Je recommanderais de ne pas considérer mon commentaire comme faisant autorité, car cela aurait pu changer (je n'ai pas vérifié depuis).

J'ajoute une bibliothèque sans tête à electron et appelle le HeadlessShellMain。
Cours:

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

alors il affiche :

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.

Cela signifie-t-il que Headless a été mis en œuvre?

@ bigben0123 c'est intéressant et très excitant ! Vous avez donc compilé votre propre version d'électron incorporant la coque sans tête en chrome ?

Avez-vous testé dans un environnement sans X sous Linux pour voir si cela fonctionne ?

Lorsque Chromium est exécuté en mode sans tête, les sous-processus de rendu sont démarrés avec le drapeau — sans tête (vous pouvez voir que vous utilisez « ps args » à partir de la mémoire). Cela se passe-t-il pour vous ?

(Étrangement avec l'électron actuellement si vous essayez de le démarrer avec - sans tête, le drapeau n'est pas transmis aux processus de rendu mais au processus GPU.)

@ bigben0123 c'est intéressant et très excitant ! Vous avez donc compilé votre propre version d'électron incorporant la coque sans tête en chrome ?

Avez-vous testé dans un environnement sans X sous Linux pour voir si cela fonctionne ?

Lorsque Chromium est exécuté en mode sans tête, les sous-processus de rendu sont démarrés avec le drapeau — sans tête (vous pouvez voir que vous utilisez « ps args » à partir de la mémoire). Cela se passe-t-il pour vous ?

(Étrangement avec l'électron actuellement si vous essayez de le démarrer avec - sans tête, le drapeau n'est pas transmis aux processus de rendu mais au processus GPU.)

Oui, je l'exécute sur Ubuntu qui démarre simplement en mode commande utilisateur.
Headless a été adopté :

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 avez-vous vos modifications quelque part ? Même si cela n'en fait pas un noyau électronique pour une raison quelconque, j'aimerais pouvoir l'utiliser.

Ce commit ne fusionne que la bibliothèque sans tête chrome avec l'électron et vous pouvez l'utiliser de la même manière que Chrome.
https://github.com/bigben0123/electron/commit/b6cad8993d68d39f1732aa6ed5ece0135b9ae0c8

En ce qui me concerne, chrome et headless ont une implémentation de couche de contenu différente. Comme deux shells de navigateur, si vous démarrez sans tête, cela n'a rien à voir avec chrome, sauf que vous commencez par "chrome --headless".

L'un des objectifs headless est de « Minimiser le nombre de modifications invasives ou spécifiques (par exemple, #ifdefs) à la base de code de Chromium ».

Par conséquent, il est difficile de mettre en œuvre cet électron sans tête pour supprimer xvfb. Nous pouvons simplement laisser le support électronique sans tête, mais vous ne pouvez pas exécuter d'applications électroniques.

Nous pouvons utiliser l'implémentation sans tête pour remplacer celle des électrons pour obtenir une nouvelle branche sans tête.

supprimer la dépendance 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" ]

remplacer par:
"//ui/affichage",
"//ui/événements/périphériques",