Description of problem: In OPS UI we have a method ManageIQ.qe.anythingInFlight() source - function () { var e=ManageIQ.qe.inFlight(); return 0 != e.autofocus || e.debounce || "complete" != e.document || 0 != e.jquery || e.spinner } We use this method in our automation code to check If ajax for loading a page is complete . We need a similar method in SUI to go ahead with automation. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hi Shveta, I think we will need to do a deeper dive with this. As described this just wouldn't work in the SUI (due to the drastic differences between the way each works). That said, if you all want, we would love to do a deep dive to really understand what in your automation needs it (and why) so we can code around that...vs. trying to "force" this to work in the SUI (which would probably take more time than starting from scratch). Just let me know who I need to coordinate with, and I can setup something.
The simple answer is that we only need a function that will tell us if it is safe to touch the UI - that it is in good state and all requests we kicked off finished an their results have affected the UI. An example is a click. After each click, our framework triggers a waiting procedure that repeatedly executes that javascript function until the javascript function says: "We're good". I understand the differences between the classic ui and the SS ui, the main point of the javascript check in classic ui is to check if there are no ajax requests and there is no more debounce (+ a couple of less important things). There is also one related thing we do in classic ui, after each keyboard input into an input we check if the input has an observer and wait for it to kick off and finish. Does anything like that happen in the SS ui as well?
@allen - we spoke about this, and I don't remember what you said. Could you please address this?
SUI polls the api continuously. SUI views have a "loading" screen that will appear during the initial loading of each (view) there after, the content on the page is continuously refreshed, updated when changes are present. This is to say there are constant requests going back and fourth that might impact the contents of each view. (Mostly) each page has a primary collection or api call that will load once, if we were to have a single "everything is loaded" it might happen after this initial instance, but again, completion of loading the primary view collection does not mean page content is codified. Probs should set up a technical meeting of all involved to talk about our options with regards to this @chris
A Pivotal Tracker story has been created for this Bug: https://www.pivotaltracker.com/story/show/150117270
Chris Kacerguis added a comment in Pivotal Tracker: Spoke to Milan and Shveta. They are trying to run Selenium tests, and the refresh is causing issues (same as it has caused for us). In talking with QE we decided to add a pause at the end of the refresh loops. The pause should default to 0 seconds, and then allow a parameter to be passed so they can change the pause time in seconds.
Chris Hale added a comment in Pivotal Tracker: Commit by Chris Hale https://github.com/ManageIQ/manageiq-ui-service/commit/96ca4f92ffc901cf83842dd2418de6fff83a955a [Finishes #150117270] Added ability to customize polling interval
Chris Hale added a comment in Pivotal Tracker: In order to test this please add the following to your URL on the login page like localhost:3001/login?pause=30. This would make all polling requests take 30 seconds.
Milan Falešník added a comment in Pivotal Tracker: Can we trigger this also from within the page using javascript? We never modify URLs, our automation executes javascript on the page.
Chris Hale added a comment in Pivotal Tracker: We do not have any globally scoped javascript functions built set this variable. We could possible talk about adding one but at this point we do not have anything that you could call directly to set this.
Milan Falešník added a comment in Pivotal Tracker: Okay. So using this get parameter will make the polling long enough that we will be able to just wait for any ajax happening in $.active and then have plenty of time to interact with the page without risking any stale elements etc., right?
PR: https://github.com/ManageIQ/manageiq-ui-service/pull/869
Fixed in 5.9.0.4.20171024163837_ef71ea6
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0380