Możliwy problem z Chromedriver 78, Selenium nie może znaleźć elementu internetowego PDF otwartego w Chrome

17

Dopóki mój Google Chrome nie został zaktualizowany do wersji 78, mój kod działał poprawnie. Zaktualizowałem również chromedriver do wersji 78.0.3904.70. Więc nie jestem już w stanie znaleźć WebElement z id = 'plugin' przy użyciu Selenium WebDriver i Java:

<html>
<div id="content">
<embed id="plugin" type="application/x-google-chrome-pdf" src="http://??????????/offer_printed.php?printable=yes&amp;reanudar=&amp;>
</div>
</html>

Poza tą częścią moje testy działają dobrze. Nigdy wcześniej nie miałem podobnego problemu. Próbowałem także znaleźć identyfikator WebElement = „content”, ale otrzymuję ten sam błąd.

WebDriverWait wait = new WebDriverWait (driver, 90);
WebElement scrollvalid = wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("plugin")));

scrollvalid.sendKeys(Keys.PAGE_DOWN);                       scrollvalid.sendKeys(Keys.PAGE_DOWN);

Mój skrypt automatyzacji powinien znaleźć element PDF i przewinąć stronę w dół. Zamiast tego otrzymuję ten błąd: org.openqa.selenium.TimeoutException: Przekroczono limit czasu po 90 sekundach oczekiwania na widoczność elementu zlokalizowanego przez By.id: plugin

Czy ktoś ma podobny problem? Z góry dziękuję.

Mieszać
źródło
Dzisiaj usunąłem Google Chrome w wersji 78 i zainstalowałem wersję 76, a mój test automatyzacji znów działa. Wszystko działa idealnie. Mam nadzieję, że problem z wersją 78 zostanie naprawiony. Używałem więc chromedriver (wersja 78) i w moim pliku .pom mam następującą zależność: <niezależność> <grupaId> org.seleniumhq.selenium </groupId> <artifactId> selenium-chrome-driver </artifactId> <wersja> 3.141.59 </version> </dependency>
Mix
Mam ten sam problem. Kod, który wcześniej działał, teraz nie działa, ponieważ sterownik sieciowy nie może zlokalizować elementu sieci, który próbuję zlokalizować. Niejawne i jawne oczekiwania kończą się niepowodzeniem. To, czego nie byłem w stanie wskazać, to rodzaj elementów, z którymi ma problemy lub jeśli są to tylko komponenty znajdujące się w ramce iframe. Aby obejść Thread.sleepten problem, dodawałem w miejscach, w których miałem domniemane lub jawne oczekiwania przed tą aktualizacją.
hfontanez
Chrome 78 z chromedriver 77 działa dla mnie.
Yun

Odpowiedzi:

5

Natrafiłem na ten sam problem.

Najwyraźniej Chrome sam się aktualizuje. Wczoraj (29 października 19) Mój ChromeDriver zaczął narzekać, że nie jest kompatybilny z Chrome 78. Zaktualizowałem sterownik do wersji 78. Zacząłem dostawać losowe wyjątki org.openqa.selenium.NoSuchElementException podczas próby znalezienia elementów, które potwierdziłem, że tam były. FindElement [s] działają również, gdy użyłem punktów przerwania. Próbowałem także ukrytych oczekiwań, ale z ograniczonym powodzeniem.

Próbowałem rozwiązania ChromeOption zsbappa, ale bez radości.

Google utrudnia uzyskanie starych wersji Chrome, ale znalazłem wersję 76 na https://www.neowin.net/news/google-chrome-76-offline-installer/ . Uwaga, instalator online instaluje najnowszą wersję. Wróciłem do sterownika za 76 i wszystko jest w porządku. Wszystkie moje testy selenu znów działają.

Doszedłem do wniosku, że Chrome 78 i powiązany z nim sterownik są w stanie wyścigu, w którym Selenium próbuje przesłuchać stronę internetową przed jej ukończeniem.

wdtj
źródło
Wydanie 3198 otworzyłem u programistów ChromeDriver.
wdtj
1
Otrzymałem następującą odpowiedź na mój problem: Dziękujemy za zgłoszenie tego problemu. Począwszy od wersji 77, Chromedriver nie czeka na załadowanie ramek lub ramek iframe podczas przechodzenia do nowej strony lub przełączania okien. Wprowadza to konieczność czekania kodu na dostępność zasobów. Większość powiązań ma jawne oczekiwanie, a także ustawienia niejawnego oczekiwania. Wyszukaj WebDriverWait w dokumentacji Selenium, aby uzyskać więcej informacji.
wdtj
Ale używamy wyraźnych oczekiwań i to nie pomaga. Pomaga to w zmianie ramek iframe, ale tagi HTML nie są już widoczne dla osadzonego pliku pdf.
Mix
Otworzyłem nowy numer w grupie chromedriver
Mix
Możesz używać Chromium do testów, jest to podstawowa wersja Chrome bez usług Google, nie aktualizuje się sama i działa dobrze z Chromedriver: chromium.org/getting-involved/download-chromium
Blaise
3

Napotkaliśmy podobny problem z Chrome 78.0.3904.7, Chromedriver 77/78, Python Selenium 3.141.0.

W naszych automatycznych testach Pythona Selenium widzieliśmy wiele awarii, w których wydaje się, że nie wystąpiły kliknięcia elementów. Co dziwniejsze, wydaje się, że element stał się aktywny (jakby miał zostać kliknięty), ale rzeczywiste zdarzenie kliknięcia nigdy nie miało miejsca. W rezultacie przełączenia stron itp. Nie występują, powodując różne awarie niższego szczebla.

W wyniku procesu śledzenia i błędów stwierdziliśmy, że użycie standardowej funkcji .click () nie jest teraz niezawodne:

webdriver_element.click()

Ale używanie Łańcuchów działań wydaje się niezawodne:

ActionChains(context.browser).click(webdriver_element).perform()

Nie jest jasne, dlaczego tak jest. Awarie rozpoczęły się, gdy tylko zaktualizowaliśmy Chrome do wersji 78.0.3904.7. Używamy Chromedriver 77.0.3865.90, ale te same testy przebiegają niezawodnie w wersjach Chrome 77.x, więc wydaje się, że coś jest nie tak lub zmieniło się w Chrome 78.

Oli Boorman-Humphrey
źródło
Bardzo mi to pomogło, dziękuję.
Piedone
1

Dodając następujący argument, rozwiązałem mój problem.

   ChromeOptions options = new ChromeOptions();
    options.addArguments("--disable-gpu");
    options.addArguments("--disable-extensions");
    options.setExperimentalOption("useAutomationExtension", false);
    options.addArguments("--window-size=1920,1080");
    options.merge(seleniumCapabilities);
    driver = new ChromeDriver(options);
zsbappa
źródło
Cześć @zsbappa! Dziękuję za odpowiedź. Nie rozwiązuje to jednak mojego problemu. Problem polega na tym, że chromedriver (wersja 78) nie może znaleźć żadnego elementu sieci w osadzonym pliku pdf. Ta funkcja działała dobrze, dopóki Google Chrome nie został zaktualizowany do wersji 78. PS NIE przeprowadzam testów w trybie bezgłowym
Mix
Nie jest jasne, w jaki sposób te opcje rozwiązują problem PO.
Cal Corbin,
To nie rozwiązuje problemu. Najprawdopodobniej uruchamiane są scenariusze, w których element WWW nie znajduje się w ramce iframe.
hfontanez
1

Napotkałem ten sam problem, gdy próbowałem uzyskać dostęp do karty w ramce iframe, wcześniej działała dobrze w wersji 76. Teraz, gdy zaktualizowała się do 78, nie działa. Próbowałem czekać, ukryte oczekiwania, spać, zlokalizować elementy za pomocą xpath, CSS, id, zmienić kontekst, przewijać do widoku itp., Bez powodzenia. Korzystam z systemu Windows 10, 1809. Nie wiem, czy dzieje się tak w innym systemie operacyjnym.

Oto pytanie, które postawiłem:

Problem z użyciem lokalizatorów chromedriver 78.0.3904.70

DavidRYV
źródło
1

Potwierdziłem wczoraj, że ten problem pojawia się tylko wtedy, gdy element jest zawarty w ramce iframe. W takich przypadkach element iframe znajduje się w porządku. Jednak próba zlokalizowania elementu WWW za pomocą sterownika lub obiektów oczekiwania sterownika sieci spowoduje odpowiednio NoSuchElementlub TimeoutException.

Dostarczyłem zespołowi chromedriver pełny dziennik sterowników chrome i oni nad tym pracują.

AKTUALIZACJA : Od wydania chromedriver 3223

Dzienniki pokazują, że końcowe wykonanieContextCreated dla ramki nie kończy się, dopóki FindElement nie zwróci wartości null. Począwszy od wersji 77, ChromeDriver przestał czekać na załadowanie wszystkich ramek przed kontynuowaniem nawigacji. Niestety ta zmiana uniemożliwiła oczekiwanie na załadowanie bieżącej ramki. 3164 będzie czekać na załadowanie bieżącej ramki; powinno to uniemożliwić wyszukiwanie przez FindElement aż do zatrzymania ładowania ramki i utworzenia kontekstu wykonania.

Zasadniczo ten błąd został wprowadzony w wersji 77. Wielu z nas właśnie zauważyło ten problem, ponieważ zaktualizowaliśmy wersję v.76 do .v78. Mówi się, że mają na celu naprawienie .v80 (nie v. 79). Aby obejść ten problem, używam Thread.sleepmiędzy czasem przełączania się na ramkę iframe a próbą zlokalizowania komponentu. To obejście działa dobrze. W rzeczywistości możesz to sprawdzić samodzielnie, po prostu uruchamiając aplikację w trybie DEBUG. Po wstrzymaniu wykonywania (przy użyciu punktu przerwania) zauważysz, że oryginalny kod (bez uśpienia) działa dobrze.

hfontanez
źródło
0

Na przykład: możesz spróbować użyć tych słów kluczowych!

1. implicit_wait=10
2. Sleep  10
Narasimhamurthy GN
źródło
Cześć, Narasimhamurthy GN, dziękuję za odpowiedź. Jawne oczekiwanie nie stanowi problemu, używam Jawnego oczekiwania we wszystkich testach i nie napotykam podobnego problemu. Problem polega na tym, że chromedriver (wersja 78) nie może znaleźć żadnego elementu sieci w osadzonym pliku pdf.
Mix
W przypadku niektórych przypadków testowych napotkałem ten sam problem, ponieważ użyłem „geckodriver” (Firefox).
Narasimhamurthy GN
w przeciwnym razie użyj innego słowa kluczowego lokalizatora biblioteki selenu, aby znaleźć WebElement.
Narasimhamurthy GN
Niestety zaleca się, aby użytkownicy naszej aplikacji internetowej korzystali z Chrome lub Internet Explorer, Firefox z jakiegoś powodu nie jest zalecany. Dlatego nie mogę używać Firefoksa do automatyzacji testów. Próbowałem użyć wszystkich możliwych sposobów, aby znaleźć dowolny element WWW na pdf przy użyciu selenu, ale to nie działa. Próbowałem też używać różnych zależencie i chromeedrivers i nic nie działa.
Mix
0

Miałem ten sam problem.

Po automatycznej aktualizacji Chrome do wersji 78.0 moje automatyczne skrypty testowe zawiodły. Zaktualizowałem więc chromedriver do wersji 78, ale sterownik nadal nie mógł znaleźć żadnego elementu WWW. Potem próbowałem z wieloma wersjami chromeedriver i wreszcie mój problem został rozwiązany w wersji chromedriver 2.44 .

Ta wersja jest dostępna na https://chromedriver.storage.googleapis.com/index.html?path=2.44/

Sagar Bhavsar
źródło
-1

Możesz menedżera pakietów Nuget , usunąć dysk Chrome i wyszukać Chrome, pobrać nową wersję selenium.web.driver.ChromeDriver >> dla jsaKamoto

tam znajdziesz chromowaną wersję 78.

Thiago
źródło
Dzięki za odpowiedź, ale tak naprawdę nie rozwiązuje problemu wyjątków NoSuchElement w wersji chromowanej 78.
wdtj 30.10-19