Protractor: Implementar elementNotToBeCovered para la biblioteca ExpectedConditions

Creado en 7 jul. 2015  ·  48Comentarios  ·  Fuente: angular/protractor

PRs plz! easy untriaged user experience feature request

Comentario más útil

+1

Todos 48 comentarios

Realmente necesito esto. Resolvería un gran problema

Este es exactamente nuestro problema en las fugas globales que tratan con el cargador de aplicaciones y las operaciones asincrónicas.

+1

Realmente necesito esto para ventanas emergentes y superposiciones que aparecen en la parte superior de la página, ExpectedConditions.elementToBeClickable no ayuda en este caso ...

¡Si esto! Constantemente me encuentro con _ "No se puede hacer clic en el elemento en el punto (x, y). Otro elemento recibiría el clic:" _ errores después de desplazarse e intentar hacer clic en un elemento ... pero solo como ~ 14% del tiempo ... frustrante. Incluso esperar a elementVisible o elementToBeClickable no siempre funciona.

+1

+1

+1

Me gustaría ver esta funcionalidad lanzada lo antes posible. Este problema es tan molesto. ¿Existe alguna solución alternativa?

+1

+1

+1

+1

@sjelin mencionas que esto se podría hacer en otro hilo, ¿verdad?

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

+1000000000

+999

+2000000

+2000000

+999

+1

+1

+1

+1
EDITAR: Lo siento entonces. Lo he visto como una práctica bastante común en otros lugares para votar sobre problemas con un +1 y este es un problema. He ejecutado muchas pruebas de transportador de ángulos, así que me interesaría verlo implementado. Sin embargo, lo recordaré para el futuro.

Detenga + {número} este PR. Esto no ayuda ...

¿Algún avance en esto?
Para mi caso de uso, estoy usando lo siguiente para desplazar el elemento a la vista, pero sé que esta no es una solución para todos los casos de uso, como modales y demás.

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

Hemos desarrollado una solución alternativa por ahora. Identificamos el elemento ( id="spinner" ) que está "bloqueando" el elemento en el que realmente queremos hacer clic y simplemente esperamos a que el elemento de bloqueo sea invisible así:
broswer.wait(EC.invisibilityOf($(‘#spinner’)), 5000)

EC.invisibilityOf no siempre es suficiente. A veces, Transportador informa que un elemento está cubierto por otro elemento que no debería ser invisible.

Por ejemplo, en una de mis pruebas, se informa que un enlace está cubierto por su div principal, y invisibilityOf esperará para siempre. Secundando el deseo de toNotBeCoveredBy

Este número tiene 2 años. ¿Existe ya alguna solución para esto, porque no puedo encontrarla y sigo encontrando este problema? En mi situación, no puedo esperar a que el elemento sea invisible, porque el elemento de cobertura no va a ser invisible en ningún punto y no está cubriendo visualmente el elemento, pero todavía obtengo el error de que no se puede hacer clic en el punto, porque otro elemento lo haría. recibir el clic.

+1 para "toNotBeCoveredBy"

He resuelto tal problema en un caso con lo siguiente:

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

El nombre del método y de la constante son específicos de mi caso de uso, pero creo que el resto podría usarse de una manera más genérica.

Luego, en mi prueba, lo uso así:

helper.waitForAngularInRoomAnimationToBeDone();

El caso es que en mi situación, cuando miro la captura de pantalla del error, que está capturando el estado de la pantalla del navegador en el momento del error, todo se ve bien y el elemento en el que quiero hacer clic está visible, pero Transportador está todavía informa que no se puede hacer clic en el elemento, porque otro recibiría el clic y esperar a que el elemento sea visible o habilitado no funciona porque el elemento ya está visible en la pantalla y está habilitado. Tengo este problema en Chrome y no aparece siempre, solo como el 20% del tiempo. Probé el código anterior, pero no me funciona.

@MihailSeykov He descubierto que si hay una animación, la captura de pantalla podría tomarse hacia el final de la animación y, por lo tanto, parece que el elemento no es visible cuando en realidad lo está. Puede usar EC.and para esperar invisibilityOf elementos múltiples que podrían estar cubriendo ese elemento

A veces, el elemento seguirá siendo visible, pero en otro lugar después de la animación.

Aprecio todo el arduo trabajo que los desarrolladores dan a los proyectos de código abierto (lo intento y lo hago cuando puedo).

Pero, ... realmente no puedo ver por qué este no es el problema / bloqueo / problema predeterminado más importante a resolver. No puedo escribir ninguna prueba sin un montón de sueño para esperar a que los elementos estén ocultos o visibles en el dom. He intentado muchas combinaciones de esperar a la invisibilidad o esperar a la visibilidad ... pero no puedo escribir pruebas que no sean hack de hacky hack hack.

No entiendo por qué no todo el mundo tiene este problema de visibilidad.

Esto tiene más de 2 años y aún no se ha solucionado. Es realmente IMPORTANTE para probar sin hacks, ¡corríjalo lo antes posible!

¿Hay algún progreso en eso :)
Pensé, finalmente tuve una cura para mi problema.

¿Podemos tener algunos comentarios sobre esto? ¿Alguien lo está mirando o nunca se arreglará? Está causando muchos problemas a mucha gente ...

Hasta donde yo sé, no está en la hoja de ruta. Pero para poder tratar de encontrar una solución para este problema, sería bueno si tuviéramos un proyecto de ejemplo y un código de transportador de ejemplo para "probar" dónde está el problema real. ¿Es eso posible?

También leo mucho en los comentarios sobre el problema con el desplazamiento al elemento y que en algunos casos aún falla. Esto podría tener que ver con el hecho de que el desplazamiento en sí también lleva tiempo, pero dicho esto, ¡un proyecto de ejemplo sería muy bueno!

¿Quién nos puede proporcionar eso?

Me gustaría agregar que para mí, este también es el problema número uno que tengo con Selenium. Es muy molesto que tengas que construir esperas, etc. para tener en cuenta las animaciones.

Escribí el método de utilidad de cheque pequeño, tenga en cuenta que hará clic en el elemento inmediatamente cuando se pueda hacer clic en él:

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

En su código de prueba:

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

Mi solución ha sido, antes de hacer clic en el elemento, eliminar del DOM el elemento que cubre el elemento en el que quiero hacer clic.
await browser.executeScript("arguments[0].remove();", coverElement);

Estamos a casi 3 años en ... ¿esta característica solicitada no se puede resolver desde _Protractor_?
Nuestras pruebas tienen sleep todas partes para tener en cuenta las animaciones que bloquean la capacidad de hacer clic en los elementos 😞

@nmfernandes Creo que podría ser un poco menos dramático, pero aún así funciona usar arguments[0].style.visibility='hidden'; . Pero en cualquier caso, tu idea fue útil. Gracias por compartir.

Casi 4 años después, ¿podemos tener esto? Es muy inconveniente crear períodos cortos entre interacciones solo para solucionar este problema. Además, los sleeps acumulan mucho tiempo que yo (y creo que muchas personas también) me gustaría evitar.

¿Alguien tiene un código donde pueda simular este problema? Si es posible, pásame el repositorio de github para solo clonar y ejecutar.

Dudo mucho que el equipo de Transportador pueda hacer algo al respecto. Para mí, parece un problema con Selenium o Chromedriver.

  • 1

Darme de baja porque ya no trabajo para Google

Creé una función auxiliar usinc async / await para mí que toma 1 o 2 argumentos como entrada, elem y
retryCount . Qué hace: intenta hacer clic en un elemento cada 0,5 segundos y, si se produce algún error, intenta hacer clic de nuevo hasta que se agota el retryCount o se hace clic en el botón.

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

}

En el archivo de especificaciones o donde quiera usarlo:

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

    const someButton = element(by.id("someElementId"));
    clickOnElementWithRetry(someButton)
})
¿Fue útil esta página
0 / 5 - 0 calificaciones