Protractor: Implémenter elementNotToBeCovered pour la bibliothèque ExpectedConditions

Vraiment besoin de ça. ça résoudrait un gros problème

C'est exactement notre problème dans les globaleaks traitant du chargeur d'applications et des opérations asynchrones.

+1

Vraiment besoin de cela pour les pop-ups et les superpositions qui apparaissent en haut de la page, le ExpectedConditions.elementToBeClickable n'aide pas dans ce cas...

Oui ca! Je suis constamment confronté à _"L'élément n'est pas cliquable au point (x,y). Un autre élément recevrait le clic :"_ erreurs après avoir fait défiler et essayé de cliquer sur un élément.. mais seulement environ 14% du temps.. frustrant. Même attendre elementVisible ou elementToBeClickable ne fonctionne pas toujours.

+1

+1

+1

J'aimerais voir cette fonctionnalité publiée dès que possible. Ce problème est tellement ennuyeux. Existe-t-il une solution de contournement?

+1

+1

+1

+1

@sjelin, vous mentionnez que cela pourrait être fait dans un autre fil, non?

We would address this using document.elementFromPoint and element.getBoundingClientRect pretty easily actually. elementFromPoint isn't totally standard at this point, though it appears to be supported by all browsers. The consistency issue is real though. Donno if we should leave this the way it is or "fix" it

+100000000

+999

+2000000

+2000000

+999

+1

+1

+1

+1
EDIT : Désolé alors. J'ai vu que c'était une pratique assez courante ailleurs de voter sur des problèmes avec un +1 et c'est un problème que j'ai beaucoup exécuté en écrivant des tests de rapporteur, donc je serais intéressé de le voir implémenté. Je m'en souviendrai pour l'avenir cependant.

Veuillez arrêter +{nombre} ce PR. Cela n'aide pas...

Une mise à jour pour ceci?
Pour mon cas d'utilisation, j'utilise ce qui suit pour faire défiler l'élément dans la vue, mais je sais que ce n'est pas une solution pour tous les cas d'utilisation tels que les modaux et autres.

var el = $('.myElement');
browser.executeScript('arguments[0].scrollIntoView()', el.getWebElement());

Nous avons développé une solution de contournement pour le moment. Nous identifions l'élément ( id="spinner" ) qui "bloque" l'élément sur lequel nous voulons réellement cliquer et attendons simplement que l'élément bloquant soit invisible comme ceci :
broswer.wait(EC.invisibilityOf($(‘#spinner’)), 5000)

EC.invisibilityOf ne suffit pas toujours. Parfois, Protractor signale un élément comme étant couvert par un autre élément qui ne devrait pas être invisible.

Par exemple, dans l'un de mes tests, un lien est signalé comme étant couvert par son div parent, et invisibilityOf attendra indéfiniment. Seconder le désir de toNotBeCoveredBy

Ce problème date de 2 ans. Existe-t-il déjà une solution à ce problème, car je ne la trouve pas et je rencontre toujours ce problème? Dans ma situation, je ne peux pas attendre que l'élément soit invisible, car l'élément de couverture ne sera invisible à aucun moment et il ne couvrira pas visuellement l'élément, mais j'obtiens toujours l'erreur de non-cliquable à un moment donné, car un autre élément serait recevoir le clic.

+1 pour le "toNotBeCoveredBy"

J'ai résolu ce problème dans un cas avec ce qui suit :

"use strict";

function elementWithAttributeHasNotValue(htmlElement, attribute, value) {
    return htmlElement.getAttribute(attribute).then((elementAttribute) => {
        return !elementAttribute.includes(value);
    });
}

class Helper {
    waitForAngularInRoomAnimationToBeDone() {
        const inRoomElement = element(by.className("in-room"));

        browser.wait(elementWithAttributeHasNotValue(inRoomElement, "class", "ng-animate"), browser.params.DEFAULT_TIMEOUT_MS);
    }
}

module.exports = Helper;

Le nom de la méthode et de la constante sont spécifiques de mon cas d'utilisation, mais je pense que le reste pourrait être utilisé de manière plus générique.

Ensuite, dans mon test, je l'utilise comme ceci:

helper.waitForAngularInRoomAnimationToBeDone();

Le fait est que dans ma situation, lorsque je regarde la capture d'écran de l'erreur, qui capture l'état de l'écran du navigateur au moment de l'erreur, tout semble bien et l'élément sur lequel je veux cliquer est visible, mais Protractor est signalant toujours que l'élément n'est pas cliquable, car un autre recevrait le clic et attendrait que l'élément soit visible ou activé ne fonctionne pas car l'élément est déjà visible à l'écran et est activé. J'ai ce problème dans Chrome et il n'apparaît pas à chaque fois, seulement 20 % du temps. J'ai essayé le code ci-dessus, mais cela ne fonctionne pas pour moi.

@MihailSeykov J'ai découvert que s'il y a une animation, la capture d'écran peut être prise vers la fin de l'animation et il semble donc que l'élément ne soit pas visible alors qu'il l'est en fait. Vous pouvez utiliser EC.and pour attendre invisibilityOf plusieurs éléments qui pourraient couvrir cet élément

Parfois, l'élément sera toujours visible, mais à un autre endroit après l'animation

J'apprécie tout le travail acharné que les développeurs donnent aux projets open source (j'essaie de le faire quand je le peux).

Mais,... Je ne vois vraiment pas pourquoi ce n'est pas le défaut/bloc/problème le plus important à résoudre. Je ne peux écrire aucun test sans un tas de sommeils pour attendre que les éléments soient cachés ou visibles dans le dom. J'ai essayé de nombreuses combinaisons d'attente d'invisibilité ou d'attente de visibilité... mais je ne peux pas écrire de tests qui ne sont pas des hacks hacky hacky.

Je ne comprends pas pourquoi tout le monde n'a pas ce problème de visibilité.

Cela a plus de 2 ans et toujours pas réparé ??! C'est vraiment IMPORTANT pour tester avec des hacks, veuillez corriger dès que possible !

Y a-t-il des progrès là-dessus :)
Je pensais que j'avais enfin un remède à mon problème

Pouvons-nous s'il vous plaît avoir des commentaires à ce sujet. Est-ce que quelqu'un le regarde ou il ne sera jamais réparé ? Cela cause beaucoup de problèmes à beaucoup de gens...

Autant que je sache, ce n'est pas sur la feuille de route. Mais pour pouvoir essayer de trouver une solution à ce problème, ce serait bien si nous avions un exemple de projet et un exemple de code rapporteur pour "preuve" où se trouve le vrai problème. Est-ce possible?

Je lis aussi beaucoup dans les commentaires sur le problème de défilement vers l'élément et que dans certains cas, il échoue toujours. Cela pourrait être dû au fait que le défilement lui-même prend également du temps, mais cela étant dit, un exemple de projet serait très bien !

Qui peut nous fournir ça ?

J'aimerais ajouter que pour moi, c'est aussi le problème n°1 que j'ai avec Selenium. Très ennuyeux que vous ayez à construire des attentes, etc. pour tenir compte des animations.

J'ai écrit une petite méthode d'utilitaire de vérification, gardez à l'esprit qu'elle cliquera sur l'élément immédiatement lorsqu'il deviendra cliquable :

import { ElementFinder, promise } from 'protractor';
export let testHelpers = {
  isClickable(el: ElementFinder): promise.Promise<boolean> {
    return new promise.Promise(resolve => {
      let interval = setInterval(() => {
        el.click().then(() => {
          clearInterval(interval);
          setTimeout(() => {
            resolve(true);
          }, 500);
        }, () => { });
      }, 100);
    });
  }
}

Dans votre code de test :

import { testHelpers } from '../src/core/e2e/helpers';
describe('App', () => {
  it('should do something', () {
    let btn = $('.cls');
    browser.wait(testHelpers.isClickable(btn), 3000);
  });
});

Ma solution de contournement a été, avant de cliquer sur l'élément, de supprimer du DOM l'élément qui recouvre l'élément sur lequel je veux cliquer.
await browser.executeScript("arguments[0].remove();", coverElement);

Nous sommes presque à 3 ans dans ... cette fonctionnalité demandée ne peut-elle pas être résolue à partir de _Protractor_ ?
Nos tests ont sleep partout pour tenir compte des animations qui bloquent la cliquabilité des éléments 😞

@nmfernandes Je pense que cela pourrait être un peu moins dramatique mais fonctionne toujours pour utiliser arguments[0].style.visibility='hidden'; . Mais en tout cas, votre idée m'a été utile. Merci d'avoir partagé.

Presque 4 ans plus tard, pouvons-nous avoir ça s'il vous plaît ? Il est très gênant de créer de courts sommeils entre les interactions juste pour contourner ce problème. De plus, les sleeps accumulent beaucoup de temps que moi (et je crois que beaucoup de gens aussi) aimeraient éviter.

Est-ce que quelqu'un a un code où je peux simuler ce problème ? Si possible, transmettez-moi le référentiel github pour ne cloner et exécuter que.

Je doute fortement que l'équipe de rapporteurs puisse faire quoi que ce soit à ce sujet. Pour moi, cela ressemble à un problème avec Selenium ou Chromedriver.

• 1

Me désaffecter car je ne travaille plus pour Google

J'ai créé une fonction d'assistance usinc async / wait pour moi-même qui prend 1 ou 2 arguments en entrée, elem et
retryCount . Ce qu'il fait, il essaie de cliquer sur un élément toutes les 0,5 secondes et si une erreur est renvoyée, il essaie de cliquer à nouveau jusqu'à ce que le retryCount s'épuise ou que le bouton soit cliqué.

export const clickOnElementWithRetry = async (elem: ElementFinder, retryCount: number = 5) => {

    while (retryCount) {
        try {
            await elem.click();
            retryCount = 0;
        }
        catch (e) {
            if(retryCount === 0)
                throw "Couldn't click element";
            await browser.sleep(500);
            retryCount--;   
        }
    }

}

Dans le fichier de spécifications ou à l'endroit où vous souhaitez l'utiliser :

import { clickOnElementWithRetry } from './helpers/';
it('Clicks on some element', async () => {

    const someButton = element(by.id("someElementId"));
    clickOnElementWithRetry(someButton)
})