Support ability to return attributes from elementResponseAttributes
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 55/100
- Type d'issue
- Fonctionnalité
- Clarté
- Plutôt claire
- Activité
- Active
- Stack technique
- ruby
- Domaine
- mobile-dev
Piste de recherche
Commencez par Appium::Core::Base::Bridge, en particulier find_element_by et find_elements_by, puis examinez l’accès existant aux attributs de Appium::Core::Element. Confirmez comment les réponses d’éléments non compactes sont gérées et comment les valeurs renvoyées peuvent être distinguées en tant que cached_attributes des attributs actualisés. Le travail est terminé lorsque les attributs spécifiés sont conservés et accessibles sans modifier le comportement d’actualisation existant.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- Ruby
- Étoiles
- 40
- Forks
- 22
- Merge moyen
- 2 h 32 min
- PR mergées (30 j)
- 17
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de appium/ruby_lib_core
-
Remove implicit capabilities handling in the corePeut-être à nouveau libre @KazuCocoa l’a pris il y a 1451 jours, et aucune pull request n’est ouverte. Ouverte
appium/ruby_lib_core#415 · 2 commentaires · 1 personne assignée ·
Les mainteneurs répondent en général sous 1 jour
-
Options in Selenium 4 -> 5Ouverteenhancement
Difficulté 3/5 1-2 jours Accessibilité débutants 45/100
appium/ruby_lib_core#333 · 3 commentaires ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de appium/ruby_lib_core
Issues similaires
-
security
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
IBM/aspera-cli#265 ·
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 92/100
Les mainteneurs répondent en général sous 7 jours
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 92/100
Les mainteneurs répondent en général sous 3 jours
-
[Bug]: QR Code do Evolution Go não aparece no CRM com Evolution Go 0.7.2 (campos em minúsculo)Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
evolution-foundation/evo-ai-crm-community#423 ·
Les mainteneurs répondent en général sous 1 jour