ChromeDriver显示丢失的UI共享上下文 [英] ChromeDriver showing Lost UI Shared Context

问题描述

我有一台运行Windows 7虚拟机的Windows 10笔记本电脑.在虚拟机内部，当我启动WebDriver时，启动时会出现错误 gpu_process_transport_factory.cc< 1009>丢失的UI共享上下文:

I have a Windows 10 laptop running a Windows 7 Virtual Machine. Inside the Virtual Machine, when i start the WebDriver, it gives the error gpu_process_transport_factory.cc<1009> Lost UI shared context when it is started:

IWebDriver driver = new ChromeDriver() //This causes the 1009 Error

然后针对无法查询立体声录音和无法发送GpuChannelMsg_CreateCommandBuffer 和 command_buffer_proxy_impll.cc< 115>共享内存而有所不同句柄无效.

这已经工作了几个月，并且未进行任何更改(此WebDriver是虚拟机的唯一用途)，运行它的笔记本电脑运行良好(例如没有GPU问题). WebDriver仍然可以浏览页面，但会给出更多错误，并且速度会慢10倍.

This has been working for months and no changes were made (this WebDriver is the sole purpose of the Virtual Machine), the laptop running it is running fine (ie. no GPU problems). The WebDriver still navigates through pages, but giving further errors and 10x slower.

编辑:已更新为ChromeDriver到2.35，并且仍然具有相同的行为.

EDIT: Updated to ChromeDriver to 2.35 and still the same behavior.

推荐答案

Headless Chrome 由 Google团队引入了 Chrome 59 在 Headless环境中运行 Chrome浏览器的方法.

Headless Chrome was shipped in Chrome 59 by Google Team which introduced a way to run the Chrome Browser in a Headless Environment.

注释添加为:

Headless mode has been available on Mac and Linux since Chrome 59. Windows support came in Chrome 60.

文章 Getting Started with Headless Chrome 提到:

--disable-gpu \                # Temporarily needed if running on Windows.

注释添加为:

现在，如果您在Windows上运行，则还希望包含--disable-gpu标志.

根据讨论 Headless: make --disable-gpu flag unnecessary 很明显:

在 Linux 或 Mac OSX 上不再需要--disable-gpu标志.错误 是固定的.

The --disable-gpu flag is no longer necessary on Linux or Mac OSX. It will also become unnecessary on Windows as soon as the bug SwiftShader fails an assert on Windows in headless mode is fixed.

引擎盖下发生了什么?

根据讨论 headless: Switch from osmesa to SwiftShader 随着Google/Chromium小组决定将 SwiftShader 与 Chrome 一起提供，该小组认为开始使用它来呈现 GL内容在 Headless Mode .这需要进行以下几处更改:

What happened under the hood?

As per the discussion headless: Switch from osmesa to SwiftShader as Google/Chromium team decided to ship SwiftShader with Chrome, the team thought to start using it to render GL content in Headless Mode. This required a couple of changes as follows :

• 以 Headless模式跳过GPU数据收集，因为该代码未将 SwiftShader 视为软件实现，当我们尝试从窗口系统.
如果我们打算使用 osmesa ，请
• 仅跳过 InitializeStaticEGLInternal 中的 GL初始化. SwiftShader 需要像其他非软件实现一样进行初始化.
Mac OSX 当前不支持
• SwiftShader ，因此团队决定在 Headless模式下继续使用物理GPU 在该平台上(不同于在其他平台上所有由软件呈现的平台).
• 因此，为了禁用 Headless模式中的 WebGL 支持，他们决定使用-disable-gpu 和-disable-软件光栅化器

• Skip GPU data collection in Headless Mode since SwiftShader isn't considered a software implementation by that code which lead to a failure when we tried to retrieve information from the Window System.
• Only skip GL initialization in InitializeStaticEGLInternal if we intend to use osmesa. SwiftShader requires initialization like the other non-software implementations.
• SwiftShader is currently not supported on Mac OSX, so the team decided to continue to use the physical GPU in Headless Mode on that platform (unlike on other platforms where everything is software rendered).
• So, to disable WebGL support in Headless Mode they decided to use --disable-gpu and --disable-software-rasterizer

Support WebGL in headless 仍在讨论中，但 SwiftShader fails an assert on Windows in headless mode > ，错误为:

The idea to Support WebGL in headless is still under discussion but SwiftShader fails an assert on Windows in headless mode with an error as :

[0117/125830.649194:ERROR:gpu_process_transport_factory.cc(1043)] Lost UI shared context.
DevTools listening on ws://127.0.0.1:37429/devtools/browser/1f0b2bf7-dfdd-44ac-9da7-f2659d352f0d

结论

此错误不会影响您的@Test，您暂时可以忽略该错误.

Conclusion

This error doesn't impact your @Test and you can ignore the error for the time being.

这篇关于ChromeDriver显示丢失的UI共享上下文的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！