Problème possible avec Chromedriver 78, Selenium ne trouve pas l'élément Web du PDF ouvert dans Chrome

17

Jusqu'à ce que mon Google Chrome ne soit pas mis à jour vers la version 78, mon code fonctionnait bien. J'ai également mis à jour le chromedriver vers la version 78.0.3904.70. Je ne peux donc plus trouver WebElement avec id = 'plugin' en utilisant Selenium WebDriver et 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>

À part cette partie, mes tests fonctionnent bien. Je n'ai jamais eu de problème similaire auparavant. J'ai également essayé de trouver WebElement id = 'content' mais je reçois la même erreur.

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);

Mon script d'automatisation devrait trouver l'élément PDF et faire défiler la page vers le bas. Au lieu de cela, je reçois cette erreur: org.openqa.selenium.TimeoutException: expiration après 90 secondes d'attente pour la visibilité de l'élément localisé par By.id: plugin

Quelqu'un est-il confronté à un problème similaire? Merci d'avance.

java selenium selenium-webdriver selenium-chromedriver Mélanger
la source
Aujourd'hui, j'ai supprimé Google Chrome version 78 et installé la version 76 et mon test d'automatisation fonctionne à nouveau. Tout fonctionne parfaitement. J'espère que ce problème avec la version 78 sera résolu. J'utilisais donc chromedriver (version 78) et dans mon fichier .pom j'ai la dépendance suivante: <dependency> <groupId> org.seleniumhq.selenium </groupId> <artifactId> selenium-chrome-driver </artifactId> <version> 3.141.59 </version> </dependency>
Mix du
J'ai le même problème. Le code qui fonctionnait auparavant échoue maintenant car le pilote Web ne parvient pas à localiser l'élément Web que j'essaie de localiser. Les attentes implicites et explicites échouent de la même manière. Ce que je n'ai pas pu identifier, c'est le type d'éléments avec lesquels il a des problèmes ou s'il s'agit simplement de composants situés à l'intérieur d'un iframe. Comme solution de contournement, j'ai ajouté des Thread.sleependroits où j'avais des attentes implicites ou explicites avant cette mise à jour.
hfontanez
Chrome 78 avec chromedriver 77 fonctionne pour moi.
Yun

Réponses:

5

J'ai rencontré le même problème.

Apparemment, Chrome se met automatiquement à jour. Hier (29 octobre 19), mon ChromeDriver a commencé à se plaindre qu'il n'était pas compatible avec Chrome 78. J'ai mis à jour le pilote vers la version 78. J'ai commencé à obtenir des exceptions org.openqa.selenium.NoSuchElementException aléatoires lorsque j'essayais de trouver des éléments dont j'avais confirmé la présence. Les findElement [s] fonctionnent également lorsque j'ai utilisé des points d'arrêt. J'ai également essayé des attentes implicites, mais avec un succès limité.

J'ai essayé la solution ChromeOption de zsbappa mais pas de joie.

Google rend difficile l'obtention d'anciennes versions de Chrome, mais j'ai trouvé la version 76 sur https://www.neowin.net/news/google-chrome-76-offline-installer/ . Attention, le programme d'installation en ligne installe la dernière version. Je suis revenu au pilote pour 76 et tout va bien. Tous mes tests Selenium fonctionnent à nouveau.

Ma conclusion est que le Chrome 78 et son pilote associé ont une condition de concurrence où Selenium tente d'interroger la page Web avant qu'elle ne soit terminée.

wdtj
la source
J'ai ouvert le problème 3198 avec les développeurs ChromeDriver.
wdtj
1
J'ai reçu la réponse suivante à mon problème: Merci d'avoir signalé ce problème. Depuis la version 77, Chromedriver n'attend pas le chargement des cadres ou des iframes lors de la navigation vers une nouvelle page ou lors du changement de fenêtre. Cela introduit la nécessité pour le code d'attendre que les ressources soient disponibles. La plupart des liaisons ont une attente explicite ainsi que les paramètres d'attente implicites. Recherchez WebDriverWait dans la documentation Selenium pour plus d'informations.
wdtj
Mais nous utilisons des attentes explicites et cela n'aide pas. Cela aide à changer les iframes mais les balises HTML ne sont plus visibles pour le pdf intégré.
Mix
J'ai ouvert un nouveau problème sur le groupe chromedriver
Mixer
Vous pouvez utiliser Chromium pour les tests, c'est une version de base de Chrome sans les services Google, il ne se mettra pas à jour et cela fonctionne très bien avec Chromedriver: chromium.org/getting-involved/download-chromium
Blaise
3

Nous avons rencontré un problème similaire avec Chrome 78.0.3904.7, Chromedriver 77/78, Python Selenium 3.141.0.

Dans nos tests automatisés Python Selenium, nous avons vu plusieurs échecs où il semble que des clics sur les éléments ne se sont pas produits. Encore plus étrange, il semble que l'élément soit devenu actif (comme s'il allait être cliqué) mais l'événement de clic réel ne s'est jamais produit. En conséquence, les commutateurs de page, etc. ne se produisent pas, ce qui entraîne diverses défaillances en aval.

Par un processus de traînée et d'erreur, nous avons constaté que l'utilisation de la fonction standard .click () n'est plus fiable:

webdriver_element.click()

Mais l'utilisation des chaînes d'action semble fiable:

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

On ne sait pas pourquoi c'est le cas. Les échecs ont commencé dès la mise à niveau vers Chrome 78.0.3904.7. Nous utilisons Chromedriver 77.0.3865.90 mais les mêmes tests passent de manière fiable sur les versions de Chrome 77.x, il semble donc que quelque chose ne va pas ou a changé dans Chrome 78.

Oli Boorman-Humphrey
la source
Cela m'a beaucoup aidé, merci.
Piedone
1

En ajoutant l'argument suivant, j'ai résolu mon problème.

   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
la source
Salut @zsbappa! Merci pour votre réponse. Cependant, cela ne résout pas mon problème. Le problème est que chromedriver (version 78) ne trouve aucun élément Web dans le pdf intégré. Cette fonctionnalité a bien fonctionné jusqu'à ce que Google Chrome ne soit pas mis à jour vers la version 78. PS Je n'effectue PAS mes tests en mode sans tête
Mix
Il n'est pas clair comment ces options résolvent le problème des PO.
Cal Corbin
Cela ne résout pas le problème. Très probablement, vous exécutez des scénarios dans lesquels l'élément Web ne se trouve pas à l'intérieur d'un iframe.
hfontanez
1

J'ai rencontré le même problème lorsque j'essayais d'accéder à un onglet à l'intérieur d'un iframe, cela fonctionnait bien sur la version 76. Maintenant qu'il s'est mis à jour en 78, il échoue. Avoir essayé les attentes, les attentes implicites, le sommeil, localiser les éléments en utilisant xpath, CSS, id, changer de contexte, faire défiler jusqu'à view, etc., sans succès. J'utilise Windows 10, 1809. Je ne sais pas si cela se produit dans d'autres systèmes d'exploitation.

Voici la question que j'ai posée:

Problème d'utilisation des localisateurs chromedriver 78.0.3904.70

DavidRYV
la source
1

J'ai confirmé hier que ce problème ne semble se manifester que lorsqu'un élément est contenu dans un iframe. Dans ces cas, l'iframe est bien situé. Cependant, la tentative de localisation d'un élément Web à l'aide du pilote ou des objets d'attente du pilote Web entraînera respectivement un NoSuchElementou TimeoutException.

J'ai fourni à l'équipe de chromedriver un journal de pilote Chrome détaillé et ils y travaillent.

MISE À JOUR : à partir du numéro 3223 de chromedriver

Les journaux montrent que l'exécution finaleContextCreated pour le cadre ne se termine qu'après que le FindElement retourne null. À partir de la version 77, ChromeDriver a cessé d'attendre le chargement de toutes les images avant de poursuivre la navigation. Malheureusement, ce changement a empêché l'attente du chargement de la trame actuelle. 3164 attendra le chargement de la trame actuelle; cela devrait empêcher FindElement de rechercher tant que le cadre n'a pas arrêté le chargement et que le fichier executionContext n'est pas créé.

Fondamentalement, ce bogue a été introduit dans la v.77. Beaucoup d'entre nous viennent de remarquer ce problème car nous sommes passés de la v.76 à la .v78. Le mot est qu'ils visent un correctif pour .v80 (pas v. 79). Pour contourner ce problème, j'utilise Thread.sleepentre le moment où je passe à l'iframe et le moment où je tente de localiser le composant. Cette solution de contournement fonctionne bien. En fait, vous pouvez le vérifier par vous-même en exécutant simplement votre application en mode DEBUG. Lorsque vous suspendez l'exécution (en utilisant un point d'arrêt), vous remarquerez que votre code d'origine (sans sommeil) fonctionne correctement.

hfontanez
la source
0

Par exemple: vous pouvez essayer d'utiliser ces mots clés !.

1. implicit_wait=10
2. Sleep  10
Narasimhamurthy GN
la source
Bonjour @Narasimhamurthy GN, merci pour votre réponse. L'attente explicite n'est pas un problème, j'utilise les attentes explicites tout au long de mes tests et je ne suis pas confronté à un problème similaire. Le problème est que chromedriver (version 78) ne trouve aucun élément Web dans le pdf intégré.
Mix
Pour moi, certains cas de test, j'ai également rencontré le même problème que j'ai utilisé "geckodriver" (Firefox).
Narasimhamurthy GN
sinon, utilisez un autre mot clé de recherche de bibliothèque de sélénium pour trouver WebElement.
Narasimhamurthy GN
Malheureusement, il est recommandé que les utilisateurs de notre application Web utilisent Chrome ou Internet Explorer, Firefox n'est pas recommandé pour une raison quelconque. C'est pourquoi je ne peux pas utiliser Firefox pour automatiser les tests. J'ai essayé d'utiliser toutes les façons possibles de trouver n'importe quel élément Web sur pdf en utilisant du sélénium, mais cela ne fonctionne pas. J'ai également essayé d'utiliser différentes dépendances et chromedrivers et rien ne fonctionne.
Mixez
0

J'ai eu le même problème.

Après la mise à jour automatique de Chrome avec la version 78.0, mes scripts de test automatisés échouaient. J'ai donc mis à jour chromedriver vers la version 78, mais le pilote n'a toujours pas pu trouver d'élément Web. Après cela, j'ai essayé avec plusieurs versions de chromedriver et enfin mon problème est résolu avec la version 2.44 de chromedriver .

Cette version peut être trouvée à https://chromedriver.storage.googleapis.com/index.html?path=2.44/

Sagar Bhavsar
la source
-1

Vous pouvez gérer les packages Nuget , supprimer le lecteur Chrome et rechercher Chrome, télécharger la nouvelle version selenium.web.driver.ChromeDriver >> pour jsaKamoto

vous y trouverez la version chromée 78.

Thiago
la source
Merci pour la réponse, mais cela ne répond pas vraiment au problème des exceptions NoSuchElement dans la version 78 de chrome.
wdtj