AFAICS, the info box is the same and should match the XPath. My guess is that we don't have any wait, so when the testing machine is slow, this creates a flickering fail.
AFAICS, the info box is the same and should match the XPath. My guess is that we don't have any wait, so when the testing machine is slow, this creates a flickering fail.
``` this.tagPage.clickConfirmDeleteTag(); assertTrue(this.tagPage.hasConfirmationMessage()); ``` clickConfirmDeleteTag clicks a button that sends a query to the server and reloads the page, there's no wait in it.
hasConfirmationMessage uses `findElementsWithoutWaiting` with the XPath tested above. There shouldn't be any issue with it if the element was actually loaded. Since the screenshot from automated tests (which happens a few frames after the failing test) looks normal, my guess is that in some instances the check is run before the page is fully reloaded.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
