I cannot think of why the collection would change automatically, but here are some things that might help debug the issue:
1. Share the webdriver logs for the scenario (enable using Selenium::WebDriver.logger.level = :info) 2. Is "errors" a custom method or variable? The smalls accessor only generates #errors_elements, so there could be an issue with how "errors" is defined. 3. Which of the errors disappear (eg the first 2, last 2, etc)? Is it always the same 7 that disappear? 4. Is the smalls accessor defined in the main page object or inside a page section? 5. If you copy the HTML to a static .html file, does the page-object have the same problem interacting with that page? Justin On Tuesday, September 24, 2019 at 8:41:45 AM UTC-4, Jeff Nyman wrote: > > My title for this is terrible but I can't think of a better way to word it > right now. > > I have a web screen where if you click a submit button without filling in > fields, 9 validation error messages appear. I have defined a page object > with these elements as a collection: > > smalls :errors, class: ["form__error", "!ng-hide"] > > This is using a page object model where "errors" becomes a method that can > be called, essentially wrapping the HTMLElements. A key thing there is I'm > negating a class attribute. > > If I do this: > > puts errors.count > > It outputs 9 correctly. So I know the element definition is referencing > the right collection and finding the appropriate objects with the class. > > However, if I do this: > > puts errors.count > puts errors.count > puts errors.count > > I get the following output: > > 9 > 2 > 2 > > This is without any change to the page. Somehow it's losing reference to 7 > of the errors, even though on the screen nothing has changed. I have a > sleep in place to make sure I can see the screen. And when I do a check in > the console for ".form__error", I see 9 returned and I see they have the > same class attributes. But somehow just calling "errors" again is losing > reference to some of the elements in the collection. > > Here's another example of how this happens. > > If I do this: > > errors.each do |error| > puts(error.text) > end > > I get the text of all nine errors correctly, once again showing that my > element definition is working and finding only those elements with the > class. But now I'll combine the things I'm doing and do this: > > puts errors.count > > errors.each do |error| > puts(error.text) > end > > I get an output of 9 with no error messages listed. So it only recognized > the "errors" on the first execution. Now I'll change the order of those: > > errors.each do |error| > puts(error.text) > end > > puts errors.count > > In this case, I get the nine error messages text listed out but no count > at all. > > Now here's the kicker: if I remove the negated class element, everything > works: > > smalls :errors, class: "form__error" > > This now returns consistent results. They are wrong results unfortunately > because the app has some extra "form__error" text that I don't want to > count. I only want the "form__errors" that also not have a "ng-hide" > attribute as part of the class. > > I'm hoping I'm describing this well enough that it makes sense to someone > what might be happening. > -- -- Before posting, please read https://github.com/watir/watir_meta/wiki/Guidelines-for-Posting-to-Watir-General-Google-Group. In short: search before you ask, be nice. [email protected] http://groups.google.com/group/watir-general [email protected] --- You received this message because you are subscribed to the Google Groups "Watir General" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/watir-general/928761d2-3d14-4ecf-a27f-3f24bfa55841%40googlegroups.com.
