ERROR: gpu_process_transport_factory.cc (1007) – Contexto compartido de la última interfaz de usuario: al inicializar el navegador Chrome a través de ChromeDriver en modo sin cabeza

Recibo este error cuando bash ejecutar el código en 2 de 3 computadoras:

[0502/155335.565:ERROR:gpu_process_transport_factory.cc(1007)] Lost UI shared context. 

Aquí está el código:

 from selenium import webdriver from selenium.webdriver.chrome.options import Options import os chrome_options = Options() chrome_options.add_argument("--headless") chrome_options.add_argument("--disable-gpu") chrome_options.add_argument("--window-size=1920x1080") chrome_driver = os.getcwd() + "\\chromedriver.exe" print "chrome driver:" + chrome_driver driver = webdriver.Chrome(chrome_options=chrome_options, executable_path=chrome_driver) driver.get("http://www.google.com") luck_button = driver.find_element_by_css_selector("[name=btnI") luck_button.click() driver.get_screenshot_as_file("capture.png") 

Ahora he comprobado todos los sistemas, están ejecutando Windows 10 de 64 bits, Google Chrome de 64 bits Versión: 66.0.3359.139, Python 2.7 de 32 bits, chromedriver.exe de 32 bits, pycharm 2018.1.1

Lo curioso es que si ejecuto esto sin las opciones sin cabeza, entonces todo funciona. Aparece el navegador, se presiona el botón I'm feeling lucky y se toma una captura de pantalla. Solo si agrego en el bit sin cabeza se produce este error.

No estoy seguro de qué podría ser diferente en 1 sistema que permitiría que esto funcione cuando los otros sistemas ejecutan el mismo software.

    Cuando Headless Chrome fue lanzado por primera vez como GA (disponibilidad general) por el equipo de Google, el artículo de Getting Started with Headless Chrome mencionó que:

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

    Se agregó una nota como:

    En este momento, también querrá incluir el indicador --disable-gpu si está ejecutando en Windows.

    Según la discusión Headless: make --disable-gpu flag unnecessary estaba claro que:

    El indicador --disable-gpu ya no es necesario en Linux o Mac OSX . También se volverá innecesario en Windows tan pronto como el error SwiftShader fails an assert on Windows in headless mode .

    ¿Qué pasó bajo el capó?

    De acuerdo con la discusión headless: Switch from osmesa to SwiftShader ya que el equipo de Google / Chromium decidió enviar SwiftShader con Chrome, el equipo pensó en comenzar a usarlo para procesar contenido GL en el modo sin cabeza . Esto requirió un par de cambios de la siguiente manera:

    • Omita la recostackción de datos de la GPU en el modo sin cabeza, ya que SwiftShader no se considera una implementación de software por ese código, lo que provocó una falla cuando intentamos recuperar información del sistema de ventanas .
    • Solo omita la inicialización de GL en InitializeStaticEGLInternal si pretendemos utilizar osmesa . SwiftShader requiere inicialización como las otras implementaciones que no son software.
    • SwiftShader actualmente no es compatible con Mac OSX , por lo que el equipo decidió continuar usando la GPU física en el Modo sin cabeza en esa plataforma (a diferencia de otras plataformas donde todo es software).
    • Entonces, para deshabilitar el soporte de WebGL en modo sin cabeza , decidieron usar –disable-gpu y –disable-software-rasterizer

    La idea de SwiftShader fails an assert on Windows in headless mode Support WebGL in headless aún está en discusión, pero SwiftShader fails an assert on Windows in headless mode con un error como:

     [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 

    Conclusión

    Este error no afecta su @Test y puede ignorarlo por el momento.

    Yo tuve el mismo problema. Intente agregar estas banderas a las opciones del controlador de Chrome:

     options.add_arguments("--proxy-server='direct://'"); options.add_arguments("--proxy-bypass-list=*"); 

    Mira este link para más información.