Bug 1470357 - RFE : Add ManageIQ.qe.anythingInFlight() method to SUI javascript
RFE : Add ManageIQ.qe.anythingInFlight() method to SUI javascript
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: UI - Service (Show other bugs)
Unspecified Unspecified
medium Severity medium
: GA
: 5.9.0
Assigned To: Chris Hale
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2017-07-12 15:50 EDT by Shveta
Modified: 2018-03-01 08:15 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2018-03-01 08:15:21 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0380 normal SHIPPED_LIVE Moderate: Red Hat CloudForms security, bug fix, and enhancement update 2018-03-01 13:37:12 EST

  None (edit)
Description Shveta 2017-07-12 15:50:08 EDT
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:

Actual results:

Expected results:

Additional info:
Comment 2 Chris Kacerguis 2017-07-13 20:16:22 EDT
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.
Comment 3 Milan Falešník 2017-07-14 04:22:58 EDT
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?
Comment 4 Chris Kacerguis 2017-07-24 13:50:32 EDT
@allen - we spoke about this, and I don't remember what you said.  Could you please address this?
Comment 5 Allen W 2017-07-24 14:01:49 EDT
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
Comment 7 Chris Kacerguis 2017-08-09 18:58:31 EDT
A Pivotal Tracker story has been created for this Bug: https://www.pivotaltracker.com/story/show/150117270
Comment 8 Chris Kacerguis 2017-08-09 18:58:52 EDT
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.
Comment 9 Chris Kacerguis 2017-08-15 08:37:47 EDT
Chris Hale added a comment in Pivotal Tracker:   
Commit by Chris Hale

[Finishes #150117270] Added ability to customize polling interval
Comment 10 Chris Kacerguis 2017-08-15 10:26:16 EDT
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.
Comment 11 Chris Kacerguis 2017-08-15 10:48:33 EDT
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.
Comment 12 Chris Kacerguis 2017-08-16 11:28:37 EDT
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.
Comment 13 Chris Kacerguis 2017-08-16 12:30:01 EDT
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?
Comment 14 Satoe Imaishi 2017-08-16 17:37:01 EDT
PR: https://github.com/ManageIQ/manageiq-ui-service/pull/869
Comment 15 Shveta 2017-11-01 00:47:36 EDT
Fixed in
Comment 18 errata-xmlrpc 2018-03-01 08:15:21 EST
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.


Note You need to log in before you can comment on or make changes to this bug.