Electron: テスト用のヘッドレスバージョン

非表示のブラウザウィンドウを使用することで、atom-shellは実際にphantomjsが実行することを実行でき、phantomjsのホームページの例を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);

もちろん、自動化テストの目的で、さらにいくつかのAPIを追加する必要があるかもしれません。

唯一の問題は、仮想バッファーに描画する代わりに、アトムシェルが実際にページを実際のウィンドウに描画することです。これにはグラフィック環境が必要です。ウィンドウとOS Xでは問題ありませんが、Linuxではxvfbを使用する必要があります

私は最近これで成功しました（UbuntuサーバーでXvfbを使用）。 私のユースケースは、テンプレート化されたページのスクリーンショットをキャプチャすることです。 実際、サーバー（m3-large）上のXvfbを介したアトムシェルのパフォーマンスは、ローカルのMacbookProよりも優れていることがわかりました。 これにより、osxのXvfbでもアトムシェルを機能させたいと思いました。

osxにはXvfbが付属しているので、その部分は簡単です。 osxでXvfbディスプレイを使用するためにアトムシェルを取得できますか？ Linuxで行っているように、標準のDISPLAY env変数を使用しても機能しません。 おそらく、libchromiumcontentは、ダーウィンで実行しているときにX11を使用する方法を知らないのでしょうか。

Xvfbは、X11環境用に作成されたアプリケーションでのみ機能します。OSXでは、アトムシェルは表示にCocoaを使用しますが、Xvfbでは機能しないと思います。

ええ、ちょっとそれをまとめました。 おそらく、代わりにX11のソースからコンパイルする方法ではないでしょうか。

@zcbenz作成することはできないBrowserWindowあなたが使用している場合でも、OS X上の現在の解像度よりも大きいことnew BrowserWindow({show: false});

@FWeinb上記の別の特定のチケットを開くことができますか？

作成＃475

Chromiumで実際にネイティブウィジェットを作成せずにページを描画する方法はなく、許可されることはないと思うので、これを閉じます。

自動テストについては、Seleniumをサポートしています。

CEFプロジェクトはオフスクリーンレンダリングをサポートしているため、ウィンドウではなくバッファに画面を描画できます。 Linux用のXサーバーに関しては、オゾンと呼ばれるターゲットを追加することで、Xサーバーなしで動作する方法があるようです（ここでの説明を

@etiktin情報をありがとう！ それを行う方法に関する既存の実装があるので、私はこれを再開します。

私たちは本当にこれのサポートを使うことができました。 最近、ナイトメアでファントムをエレクトロンに置き換えて、今のところ気に入っていますが、Linuxではそのままでは機能しません。

これを機能させるために今必要なことは次のとおりです： https ：

スタンドアロンのデスクトップElectronアプリケーションに変換されるWebアプリケーションの1つに対するユーザーの動作を自動化するタスクが与えられました。 当社がこの移行を決定する前に、Chromeウェブドライバーを使用してページオブジェクトを作成し、cssセレクターを使用してボタン/ドロップダウン/テキストボックスを呼び出してウェブアプリケーションを操作しました。 ElectronシェルでラップされたWebアプリケーションでこれを行う方法はありますか？ 会社はメニューバーオプションを使用して特定の機能を呼び出すことを計画しており、JavaScriptドライバーを使用してファイル/編集/ヘルプなどのデフォルトのメニューバーオプションを取得しようとしましたが、成功しませんでした。 これを行う方法の例はありますか？

https://github.com/segmentio/nightmare/issues/224#issuecomment 1：-141575361それはLinux上での@matthewmuellerスニペットの作品を思わ：

SuSEでヘッドレステストを行っている人はいますか？ 具体的にはSLES？

@fritx SlimerJSで使用されているものと同じですが、ヘッドレスモードではありません。

@fritxは@zcbenzが言っていたことです、あなたはXvfbを実行している必要があります。 現在、CEF3とChromium ContentShellはどちらもXlibに依存しています。 しかし、オゾンの完成とともに： https ：
低レベルのI / Oを提供できます。

どうやら、Chromium自体にマスターバグがあります： https ：

これは面白い：

日付：2015年12月2日水曜日15:35:21

[ヘッドレス]ヘッドレス/パブリック/の初期スケルトン

将来のヘッドレスAPIの概要を作成します。

ChromeDriverは電子で動作しますか？

xvfbを必要としないヘッドレスバイナリは、 AWS Lambdaなどの新しい環境を開きます-サインアップしてください！

@Vanuan悪夢について聞いたことがありますか？ ChromeDriverに特に必要なものがない場合は、これが役立つ可能性があります。

Capybara / Seleniumドライバーはありますか？

+1

私は少し混乱しています。 ヘッドレスモードはありますか？ BrowserWindow（{show：false}）でこれを効果的に行うことができますか？ これは私にとって非常に便利です。サーバー側のWebコンポーネントを作成できるように、これを機能させようとしています： https ：

周りを見回しながら、自分の質問に答えたと思います。 Electronは、洗練されたヘッドレスモードをネイティブにサポートしていません。 ナイトメアはそのようなことを許可しているようですが、グラフィック環境のない特定のシステムで動作させるには、いくつかの構成を行う必要があります。 BrowserWindow（{show：false}）を使用する場合、Electronもそれを実行できますが、ヘッドレスLinuxシステムでグラフィカル環境を提供するにはxvfbを使用する必要があります（実際にはそれほど悪くはないようです）。 私が間違っている場合は私を訂正し、この機能に+1します。

新しいクロムヘッドレスプロジェクト[1]で、xvfbを使用せずに電子ヘッドレスを作成することは可能でしょうか？

現在の制限はlibchromiumにあったと思いますか？ Chromeの人たちはそれを修正しましたか？

1： https ：

関連するフォーラムがあります：

これについて何か進展はありますか？ これはテストに非常に役立ちます

segmentio / nightmareはこれに最適です。 単に：

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

@amilajack単純なMochaユニットテストをヘッドレスで実行するような単純なケースの場合、Nightmareは、20ポンドのハンマーを使用して小さな釘を打ち込むようなものです（読み：大規模なやり過ぎ）。 これは、基本的なナビゲーションと入力を実行できるだけでなく、HTMLファイルとPDFファイルをディスクに保存したり、スクリーンショットを撮ったりすることもできる、本格的なバッテリー付きのブラウザー自動化ライブラリです。 単純な単体テストを実行するには、このライブラリの正確に0％が必要です。

@isiahmeadows @mcolyerは、代わりに使用できるアトムシェルのヘッドレスバージョンが

ええ、でも、使わないものに砂糖が必要なのはなぜですか？ （私はすべての砂糖について言及していました-理論的には、バニラノード+ OpenGLバインディングだけでElectron全体を再実装できます）。

ヘッドレスブラウザの最も一般的な使用例は、 mocha-phantomjsやKarmaがすでに存在するもののようなものですChromium自体がヘッドレスになり、それらの変更が伝播されるまで発生しない可能性があります。 libchromiumcontentに。

ヘッドレスがChrome59に追加されました： https ：

@sindresorhus @zcbenz Chromiumのこの変更は、ここで何か違いがありますか？

電子はすでに素晴らしいです、そしてヘッドレスモードはそれをさらに良くするでしょう！

（ElectronをベースにしたNightmareにも

Xvfbをラムダで動作させることができました。これはラムダベースのテストに役立つ可能性があります... https：//github.com/nisaacson/aws-lambda-xvfb

Electronが真のヘッドレスをサポートする時期について何か言いたいことはありますか？ これが起こることを期待できますか？ xvfbをドロップするのが待ちきれません。

@lastmjsは、xvfbに基づいてElectronをAWS Lambdaで実行することに成功しましたか？

@schicklinghttps ： //github.com/nisaacson/aws-lambda-xvfbを参照してください

コメントありがとうございます@MrSaints。 nightmareを実行することができなかったので、私は実際にこのリポジトリを数時間デバッグしています。 それはあなたのために働きますか？

@zcbenz FYI https://www.chromestatus.com/features/5678767817097216

@schicklingはhttps://github.com/JohannesHoppe/nightmare-html2pdfを参照して-Xvfbを使用したDockerの悪夢

@JohannesHoppeに感謝します代わりにAWSLambdaで実行したいと思います。

NightmareでElectronをヘッドレスChromeに置き換える問題を開きました： https ：

@schicklingこれを試してください： https ：

他の場所で回答された場合はお詫びしますが、具体的な回答が見つかりません。 @sandstromは、上記の非常に+1されたコメントの中で、ヘッドレスがChrome59で利用できるようになったことを指摘しました。

Electronの開発ロードマップでChromeのヘッドレスフラグがサポートされていますか？ これは、真のヘッドレス使用を可能にするため、Electronにとって潜在的に大きな「勝利」のようです。

@rinogoに同意します。 電子用のヘッドレスオプションがあると、仮想ディスプレイを必要とせずにマシンを引き継ぐことなく、ciシステムや開発ボックスでテストを実行するのに非常に役立ちます。 私はまた、電子と可能性のある貢献のロードマップを知りたいと思っています。

Xvfbは煩わしいです、Electronが真のヘッドレスをサポートするならそれは素晴らしいでしょう！

xvfb-多分その間に

Googleから新しい記事があります： https ：

もうすぐです。

Chrome59は現在安定したチャンネルにあるようです。 Electronでヘッドレスをサポートするための次のステップは何ですか？

これを実現してください。これを実行し、NightmareJSでヘッドレスElectronを実行できるようにすることで、最終的にはすべてのSeleniumユースケースの3分の1のように排除できます。*

*双曲線であるが、実際にはそうではない

@aendrew NightmareJSは、Electron（哲学：_クロスプラットフォームデスクトップアプリの構築_）をヘッドレスにすることをめちゃくちゃにするのではなく、代わりにCDPバックエンドを使用/含めるように_書き直される_可能性があると思いhttps ：

@MrSaintsメンテナをうらやましくない。 彼らは1年前のようにPhantomJSからの変換を_ちょうど_終了しました。 どちらかといえば、ナイトメアのブラウザレイヤーをプラグイン可能にするのは良い動機かもしれません...

とにかく、Electronがデスクトップ指向であるという点はよく理解されています。

@aendrew @MrSaints私の無知をブロードキャストするリスクがあります...この変更（ headlessフラグをサポート）の実装はどのくらい難しいですか？ ElectronがChromiumとどのようにインターフェース/拡張するかはわかりませんが、これを実装する手順は次のように思われます。

1. Electron'sChromiumをバージョン59以降にアップグレードします。
2. headlessコマンドラインフラグ/構成パラメーターを指定します。
3. 私が明らかに説明していない他のもの。 :)

私が言っているのは、 headlessがChromiumで利用できるようになったため、ヘッドレスモード（NightmareJSなど）の実装は比較的簡単なようだと思います。 確かに、Electronの汎用バージョンでは、特定のユースケースを解決するのに時間がかかる場合があります。 ただし、NightmareJSのようなもののために設計されたビルドを生成するには、かなり簡単なはずですよね？

速度の改善がすぐに必要な場合は、飛び込んで試してみます。 ただし、NightmareJSは現状のままで対応しているので、当面は問題ありません。

とにかく、これらすべてのプロジェクトのメンテナの貢献と努力に感謝します！ :)

NightmareJSについて：現在、AWSLambdaなどのサーバーレス環境でも実行できるヘッドレスChrome上に構築されたバージョンのNightmareに取り組んでいます。 すぐに@graphcoolでオープンソース化します。 🚀

@schicklingそれは素晴らしいだろう！

Chromeの--headlessで覚えておくべきことの1つは、すべてのプラグインのサポートを無効にすることです。 したがって、フラッシュ（electron / nightmareで実行可能）やPDFビューアなどが必要な場合は、 --headlessは適しておらず、xvfbを使用することをお勧めします。

AWSLambdaでElectronを実行するのが待ちきれません...

アーメン@lastmjsアーメン

このソリューションはどうですか？
https://github.com/dimkir/nightmare-lambda-tutorial

まだ試していません

@xplodedthemesは、プリコンパイルされたバージョンの

恥知らずなプラグ： https ：

PR /問題/フィードバックを歓迎します！

こんにちは、みなさん！ ご迷惑をおかけして申し訳ありません...💤

Chromelessをオープンソース化した

あなたはここでそれを試すことができます： https ：

ChromelessはNightmareに取って代わったばかりですか？ Chromelessは、悪夢に追いつくまでに

複数のテストを同時に実行する機能が必要なため、ナイトメアの代わりに使用します。

質問（このスレッドには良くないかもしれません）：PDF機能を機能させることを検討していますか？ もしそうなら、これは私たちに頭痛（そしてコスト）のトンを節約することができます。

うわー、それはすごいです。 よくやった！

@zcbenzこれに対する解決策が出てきたようです：閉じても大丈夫ですか？

うーん、この問題はまだ非常に有効です。 「解決策」はすべて、ナイトメアから完全に離れることを含みます。

@keithkmlに完全に同意し前のコメントで提起した質問に答えるのに十分な専門知識を持って

私はまだ応答のポイントを取得していません。 誰かが私に、電子アプリをCIで実行するためのネイティブヘッドレスモードがあるかどうかを明確にしてください。

@hitliuboChromeには--headlessフラグがありますが、FlashやPDFリーダーなどのプラグインを使用していない場合にのみ機能します。 あなたがそうなら、答えは現時点では肯定的ではありません。 そうでない場合は、ブラウザコンテキストを作成するときに、そのフラグを（必要に応じて--disable-gpuとともに-新しいChromeバージョンIIRCでのこの欠落した影響を修正しました）渡して、それが機能するかどうかを確認できます。 （Nightmareのようなものを使用していて、2番目のカテゴリに分類される場合、まだない場合は、そのプロジェクトのそれぞれのリポジトリに問題を提出する必要があることに注意してください。）

--headless使用できない場合（または機能しない場合）でも、次のオプションがあります。

• Windows：あいまいなものを使用していない限り、レンダリングするウィンドウコンテキストは常にあります。 Windows Server 2016はデフォルトのGUIサポートを廃止しましたが、それでもGUIウィンドウの作成をサポートしており、AFAICT
• macOS：ここには常にGUIがあります（したがって、レンダリングするウィンドウコンテキストがあります）。 Appleは、提供していないバージョンを提供していません。
• Linux：xvfbはヘッドレスXサーバーであり、ほぼすべての一般的なLinuxディストリビューションで使用できます（ここでは「一般的な」という意味です）。 Travisを使用している場合は、プロジェクトに追加する方法についての説明があります。

@isiahmeadows情報ありがとうございます。 現在、ブラウザで実行されているWebアプリがあり、chrome / firefoxを使用すると、ヘッドレステスト用に--headlessをいつでも追加できます。 最近、それをElectronアプリに変換したいので、macOSでは機能しない--headlessを試してみました。 今、私はあなたの理由を知っています。 ありがとう！

実際、xvfbはネイティブではないため、このソリューションは好きではありません。 ただし、ネイティブヘッドレスはサポートされていないため、試してみる必要があると思います。

参考までに-現在、テストにカピバラを使用しています。

それは素晴らしいことです（y）

これに関する更新はありますか？

Linuxフレームバッファへの直接レンダリングに関する投稿からここにリダイレクトされましたが、これはヘッドレステストに焦点を当てているようです。 _real_フレームバッファへの直接レンダリングに進展はありましたか？

@quinn必要に応じて、フレームバッファでX11（Xorg）を実行できますが、Xサーバーが必要になることは

_編集：_

実際、これをもう少し調べた後、これはオゾンを使用することによっても達成できます。 （https://github.com/jakwu/ozone-fb）

オゾンを追加すると、ウェイランドのサポートも可能になります。これは、Linuxディストリビューションの大部分がこれに移行したため、電子が欠落しているというもう1つの機能です。

オゾン-fbと

@trusktrそれは2年前のコメントです。 コメントが変更された可能性があるため、コメントを信頼できるものと見なさないことをお勧めします（それ以来チェックしていません）。

電子にヘッドレスlibを追加し、HeadlessShellMainと呼びます。
走る：

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

次に、次のように表示されます。

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.

それはヘッドレスが実装されたことを意味しますか？

@ bigben0123それは面白くてとてもエキサイティングです！ それで、あなたはクロムからヘッドレスシェルを組み込んだあなた自身のバージョンの電子を編集しましたか？

Linux上のXのない環境でテストして、動作するかどうかを確認しましたか？

クロムがヘッドレスモードで実行されると、レンダリングサブプロセスはパススルーされたヘッドレスフラグで開始されます（これはメモリから「psargs」を使用していることがわかります）。 これはあなたのために起こっていますか？

（現在、電子で開始しようとすると、不思議なことに—ヘッドレスでは、フラグはレンダリングプロセスに渡されず、GPUプロセスに渡されます。）

@ bigben0123それは面白くてとてもエキサイティングです！ それで、あなたはクロムからヘッドレスシェルを組み込んだあなた自身のバージョンの電子を編集しましたか？

Linux上のXのない環境でテストして、動作するかどうかを確認しましたか？

クロムがヘッドレスモードで実行されると、レンダリングサブプロセスはパススルーされたヘッドレスフラグで開始されます（これはメモリから「psargs」を使用していることがわかります）。 これはあなたのために起こっていますか？

（現在、電子で開始しようとすると、不思議なことに—ヘッドレスでは、フラグはレンダリングプロセスに渡されず、GPUプロセスに渡されます。）

はい、ユーザーコマンドモードで起動するubuntuで実行します。
ヘッドレスが渡されました：

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どこかに変更がありますか？ なんらかの理由で電子コアにならない場合でも、使ってみたいです。

このコミットは、chromeヘッドレスlibをelectronにマージするだけであり、chromeと同じように使用できます。
https://github.com/bigben0123/electron/commit/b6cad8993d68d39f1732aa6ed5ece0135b9ae0c8

私に関する限り、chromeとheadlessではコンテンツレイヤーの実装が異なります。 2つのブラウザシェルのように、ヘッドレスで開始する場合は、「chrome --headless」で開始することを除いて、chromeとは関係ありません。

ヘッドレスの目標の1つは、「Chromiumのコードベースに対する侵襲的またはヘッドレス固有の変更（#ifdefsなど）の数を最小限に抑える」ことです。

したがって、xvfbを除去するために電子がヘッドレスであることを実装することは困難です。 電子サポートをヘッドレスにすることはできますが、電子アプリを実行することはできません。

ヘッドレスの実装を使用して電子を置き換え、新しいヘッドレスブランチを取得する場合があります。

electronic /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" ]

と置換する：
"// ui / display"、
"// ui / events / devices"、