Uploaded image for project: 'Community Edition'
  1. Community Edition
  2. MGNLCE-86 UI Test improvements as preparation for using docker and chrome
  3. MGNLCE-89

Fix incorrect usage of Selenium implicitly wait timeout to deal with dynamic ui behavior



    • Type: Sub-task
    • Status: Closed
    • Priority: Neutral
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.5.7, 5.6
    • Component/s: None
    • Labels:
    • Sprint:
      Basel 106, Basel 107, Basel 108, Basel 109, Basel 110, Basel 111, Basel 112
    • Magnolia Release:
      5.5.7, 5.6


      We set the implicitlyWait timeout of selenium to a high number: 10 seconds compared to the default of 0.
      The implicitlyWait timeout is the timeout the remote driver will poll the DOM to decide if an element is there or not. This implicit timeout should not be mixed with the explicit timeout like the waitUntils. They have an unfortunate influence on each other and should not be used both at the same time because:

      • They operate on different levels: implicit timeout is implemented on the specific driver where as the explicit timeouts are implemented on the tests
      • They influence each other because inside a waitUntil (explicit timeout) you will use the driver (implicit timeout) which can lead for example to a total timeout which is longer than both timeouts

      In a little bit more detail:
      We use the waitUntil as a polling mechanism, executed every 0.5 sec, to repeatedly evaluate if a condition becomes true or not. In the end its like an assert with function and timeout of 10 sec.
      Inside that condition we use the driver to find elements in the DOM which in turn will poll the DOM until the element can be found or the implicit wait timeout of 10 sec is reached.

      So we have two polling loops inside each other operating with the same timeouts which renders one of them useless. If we look at the functionality on each and how they are intended to be used it becomes clear we want to use the functionality of conditions and waitUntils and therefore the implicit wait has to be reduced.


      Just as an example where this caused a concrete issue: AbstractMagnoliaUITest#getTabWithCaption.
      We have the situation with tabs in dialogs that the dialog is dynamically loaded and, depending on the space, tabs can appear directly on the top or hidden in the context menu. So we have to wait for a condition to be met because we don't know how long it will take until the dialog is open and ready. The condition is met if either the tab is visible or in the menu. So one of the conditions has to be met where as the other one most certainly will not.
      If the dialog is loaded immediately we have no issue but if its a little bit slower the following things happen:

      1. Enter the or condition for either hidden or visible tab
      2. Evaluate the first condition: try to find the tab in the visible top for max 10sec
      3. Tab is dynamically added to the DOM top bar
      4. First condition evaluates to false and returns because the element could be found but its not visible yet (visibility is not an attribute of the DOM element but a result of the rendering of the DOM)
      5. Evaluate the second condition: try to find the tab hidden in the menu
      6. Tab is rendered and becomes visible
      7. Second condition evaluates to false because the find element in the condition times out after 10 sec because the element could not be found (and will never be found as the tab was added to the top)
      8. The or condition would now try to evaluate the two conditions over and over again but because we are already past 10 sec (needless implicitly waiting for the hidden tab) the whole condition times out now as well after >10sec.

      Further Reading:




            mmuehlebach Michael Mühlebach
            mmuehlebach Michael Mühlebach
            0 Vote for this issue
            1 Start watching this issue