Support ability to return attributes from elementResponseAttributes
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 55/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- ruby
- Área
- mobile-dev
Línea de trabajo
Comienza con Appium::Core::Base::Bridge, especialmente con find_element_by y find_elements_by, y luego inspecciona el acceso existente a los atributos de Appium::Core::Element. Confirma cómo se gestionan las respuestas de elementos no compactas y cómo pueden distinguirse los valores devueltos como cached_attributes de los atributos actualizados. Se considera completado cuando los atributos especificados se conservan y son accesibles sin cambiar el comportamiento de actualización existente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
This is a
- Feature Request
Summary
I've already written a patch to implement this feature, but just wanted to check before formatting it into a PR that it would be accepted.
The short is that when setting elementResponseAttributes for android/iOS and disabling compact responses with the capability shouldUseCompactResponses: false Calls to appium start returning the attributes specified, instead of just the element id which is great. The issue is that the appium bridge: Appium::Core::Base::Bridge which inherits from Selenium::WebDriver::Remote::Bridge doesn't actually do anything with these attributes, it only reads the element id. The methods find_element_by and find_elements_by need to be modified so that we can have our attributes returned and Appium::Core::Element needs to hold onto these attributes`
Currently when querying any attribute for an element, it always performs a HTTP request, so I think it needs to be very clear that when accessing these returned attributes, they aren't refreshed and can be stale. I used the method cached_attributes to represent the attributes returned when fetching the element, but very open to using different naming, it does feel important to differentiate between the existing behaviour of always fetching attributes vs when you want to fetch one of the values returned initially.
- Lenguaje dominante
- Ruby
- Estrellas
- 40
- Forks
- 22
- Merge medio
- 2 h 32 min
- PR fusionados (30 d)
- 17
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de appium/ruby_lib_core
-
Remove implicit capabilities handling in the coreQuizá libre de nuevo @KazuCocoa la tomó hace 1454 días y no hay ningún pull request abierto. Abierto
appium/ruby_lib_core#415 · 2 comentarios · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Options in Selenium 4 -> 5Abiertoenhancement
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
appium/ruby_lib_core#333 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de appium/ruby_lib_core
Issues similares
-
security
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
CircuitVerse/CircuitVerse#7967 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
simp/pupmod-simp-stunnel#173 ·
-
Polish QDrantAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
o19s/quepid#1825 · 1 comentario ·
Los mantenedores suelen responder en 1 día