Moodle
  1. Moodle
  2. MDL-40246

Edit post as student scenario fails using slow servers/clients

    Details

    • Testing Instructions:
      Hide
      1. Run the whole suite (will be done automatically by the CI server, but confirm with integrators that it ran and finished with a 100% success)
      2. Edit a scenario of any of the codebase feature files without the @javascript tag
        • Add a custom @MDL-40246 tag in the preceding line of that scenario
        • Add a And I wait "3" seconds in the when or then sections of the scenario
        • Save the file
      3. Run behat using --tags @MDL-40246 option
      4. You SHOULD see a failure and the message SHOULD state that Waits are disabled in scenarios without Javascript support
      Show
      Run the whole suite (will be done automatically by the CI server, but confirm with integrators that it ran and finished with a 100% success) Edit a scenario of any of the codebase feature files without the @javascript tag Add a custom @ MDL-40246 tag in the preceding line of that scenario Add a And I wait "3" seconds in the when or then sections of the scenario Save the file Run behat using --tags @ MDL-40246 option You SHOULD see a failure and the message SHOULD state that Waits are disabled in scenarios without Javascript support
    • Affected Branches:
      MOODLE_25_STABLE, MOODLE_26_STABLE
    • Fixed Branches:
      MOODLE_25_STABLE
    • Pull from Repository:
    • Pull 2.5 Branch:
    • Pull Master Branch:
      MDL-40246_master
    • Rank:
      51010

      Description

      Detected when using saucelabs, which adds a network delay + their VMs delay; to edit a forum discussion as a student takes around 25 seconds when running locally, and around 1 minute + 20 seconds using saucelabs through the CI server.

      With MDL-40123 integrated we save a few seconds but is not enough to provide stability.

      The problem comes with Edit forum post scenario of mod/forum/tests/behat/edit_post_student.feature, we set the site with a 1 minute to edit posts, but the process takes more than one minute, so an exception is thrown and the scenario fails. As we are not testing something related with javascript, I would propose to switch from @javascript to a goutte driver test (headless without JS).

        Issue Links

          Activity

          Hide
          David Monllaó added a comment -

          Marked as major as is the last of the CI job's fails

          Show
          David Monllaó added a comment - Marked as major as is the last of the CI job's fails
          Hide
          David Monllaó added a comment -

          I've been thinking about it because if we want to add more non-JS tests it would be good to be able to reuse the current scenarios through background sections when is possible (I mean running the same steps with and without JS without having to copy&paste the steps list) if we want to do it would be better that these steps, instead of failing the non-JS tests throwing an exception, will just ignore the wait and continue or add a PHP sleep(N) otherwise; there would be other steps to adapt for JS and non-JS reuse without receiving unexpected failures, but we lose specific feedback when providing exceptions to tests writers writting non-JS tests. Feel free to discard this last patch if you think is not worth (MDL-40246 behat: Adding custom exception to wait methods) to add it now.

          I think we need to discuss about it in general and the testing meeting could be a good opportunity, the whole suite is currently taking 11 hours (using saucelabs) and around 4 hours running Selenium locally, and we can not run the whole suite for each integrated issue because of those slow runs, but most of our checkings are not JS related and to run the tests with JS disabled would be much quicker, so maybe another option is to run no-JS after each push to integration or currently in integration (for each issue I mean) and run all including JS features pulling latest integration every day or running forever like Damyon's script does.

          Show
          David Monllaó added a comment - I've been thinking about it because if we want to add more non-JS tests it would be good to be able to reuse the current scenarios through background sections when is possible (I mean running the same steps with and without JS without having to copy&paste the steps list) if we want to do it would be better that these steps, instead of failing the non-JS tests throwing an exception, will just ignore the wait and continue or add a PHP sleep(N) otherwise; there would be other steps to adapt for JS and non-JS reuse without receiving unexpected failures, but we lose specific feedback when providing exceptions to tests writers writting non-JS tests. Feel free to discard this last patch if you think is not worth ( MDL-40246 behat: Adding custom exception to wait methods) to add it now. I think we need to discuss about it in general and the testing meeting could be a good opportunity, the whole suite is currently taking 11 hours (using saucelabs) and around 4 hours running Selenium locally, and we can not run the whole suite for each integrated issue because of those slow runs, but most of our checkings are not JS related and to run the tests with JS disabled would be much quicker, so maybe another option is to run no-JS after each push to integration or currently in integration (for each issue I mean) and run all including JS features pulling latest integration every day or running forever like Damyon's script does.
          Hide
          David Monllaó added a comment -

          Sending to integration as with this we return to a 100% success in CI.

          Show
          David Monllaó added a comment - Sending to integration as with this we return to a 100% success in CI.
          Hide
          Dan Poltawski added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          TIA and ciao

          Show
          Dan Poltawski added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
          Hide
          David Monllaó added a comment -

          rebased

          Show
          David Monllaó added a comment - rebased
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Really it's tricky the wait thing, it seems to be the major headache with acceptance tests, grrr.

          IMO ideally we should allow "And I wait (UP TO!) X seconds" or "And I wait until the page is ready", no matter if the tests is JS or no. Just we should be able to "accelerate" the wait (make it shorter) with the continuous evaluation of some other condition (much like the page is ready does).

          I'm not sure about building the steps conditionally that way is the best way really. Why not, instead, make the "I wait (UP TO! X seconds" instead to behave different if the test is a javascript or no?

          I mean why cannot we do something like:

          public function i_wait_seconds($seconds) {
          
              if (!$this->running_javascript()) {
                  // Nothing to wait. The driver waits till output completed by default.
              } else {
                  $this->getSession()->wait($seconds * 1000, SOME_OTHER_BLOODY_EVALUATION_THAT_MAY_REDUCE_THE_WAIT);
              }
          }
          

          That means, more or less, if the page is non-js, then the wait is not needed (apparently, based on your changes). But if the page is js then we wait UP TO X seconds but trying to reduce the wait with some continuous search (obviously document.readyState is not valid in this case). Note I don't know if that SOME_OTHER_BLOODY_EVALUATION_THAT_MAY_REDUCE_THE_WAIT is really possible or no, surely it's not or you had implemented it already.

          But in any case, with condition or without it, that way the same exactly steps will work both under js and non-js scenarios, hence they can be shared/reused/background-ed easier.

          I think it's a better approach than the current exception and/or build scenarios conditionally code that your code introduced.

          Thoughts?

          Show
          Eloy Lafuente (stronk7) added a comment - Really it's tricky the wait thing, it seems to be the major headache with acceptance tests, grrr. IMO ideally we should allow "And I wait (UP TO!) X seconds" or "And I wait until the page is ready", no matter if the tests is JS or no. Just we should be able to "accelerate" the wait (make it shorter) with the continuous evaluation of some other condition (much like the page is ready does). I'm not sure about building the steps conditionally that way is the best way really. Why not, instead, make the "I wait (UP TO! X seconds" instead to behave different if the test is a javascript or no? I mean why cannot we do something like: public function i_wait_seconds($seconds) { if (!$ this ->running_javascript()) { // Nothing to wait. The driver waits till output completed by default . } else { $ this ->getSession()->wait($seconds * 1000, SOME_OTHER_BLOODY_EVALUATION_THAT_MAY_REDUCE_THE_WAIT); } } That means, more or less, if the page is non-js, then the wait is not needed (apparently, based on your changes). But if the page is js then we wait UP TO X seconds but trying to reduce the wait with some continuous search (obviously document.readyState is not valid in this case). Note I don't know if that SOME_OTHER_BLOODY_EVALUATION_THAT_MAY_REDUCE_THE_WAIT is really possible or no, surely it's not or you had implemented it already. But in any case, with condition or without it, that way the same exactly steps will work both under js and non-js scenarios, hence they can be shared/reused/background-ed easier. I think it's a better approach than the current exception and/or build scenarios conditionally code that your code introduced. Thoughts?
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Added the iTeam, to discuss about this a bit. Note we can integrate this now (to start getting immediate passes).

          Or discuss a bit and find if my suggestion is possible, no matter if the BLOODY_EVALUATION is possible or no.

          I keep this under integration for now...

          Show
          Eloy Lafuente (stronk7) added a comment - Added the iTeam, to discuss about this a bit. Note we can integrate this now (to start getting immediate passes). Or discuss a bit and find if my suggestion is possible, no matter if the BLOODY_EVALUATION is possible or no. I keep this under integration for now...
          Hide
          David Monllaó added a comment -

          Hi Eloy,

          I agree with you, the race conditions are being the worst headache we are dealing with, this waiting thing was one of the points I had for the testing meeting In this case there is a wait because of the redirect() with message that users sees after adding a post and states that they can modify it, without JS we can click on the 'Continue' link because we know that it will be fast enough to click on the 'Continue' link before the user is redirected, with JS enabled and a lot of delays because of selenium or network delays (using saucelabs for example) we can not be sure of it, the wait is hardcoded according to the redirect() wait value. An alternative would be a modification in redirect() and if BEHAT_SITE_RUNNING avoid all redirect() with waits, it would be cleaner and probably we will avoid the same hardcoded wait in future tests.

          Talking about the waits in general the main problem is having the JS completely loaded or not, Sam commented about setting a JS var after all the footer modules load, so we can begin running the steps being sure that that page's DOM elements modified by JS are available (for example simple forms and the 'Expand all' link) from the behat steps definitions we can check those vars. This neither covers all cases, for example filepicker is specially tricky (MDL-40033)

          Show
          David Monllaó added a comment - Hi Eloy, I agree with you, the race conditions are being the worst headache we are dealing with, this waiting thing was one of the points I had for the testing meeting In this case there is a wait because of the redirect() with message that users sees after adding a post and states that they can modify it, without JS we can click on the 'Continue' link because we know that it will be fast enough to click on the 'Continue' link before the user is redirected, with JS enabled and a lot of delays because of selenium or network delays (using saucelabs for example) we can not be sure of it, the wait is hardcoded according to the redirect() wait value. An alternative would be a modification in redirect() and if BEHAT_SITE_RUNNING avoid all redirect() with waits, it would be cleaner and probably we will avoid the same hardcoded wait in future tests. Talking about the waits in general the main problem is having the JS completely loaded or not, Sam commented about setting a JS var after all the footer modules load, so we can begin running the steps being sure that that page's DOM elements modified by JS are available (for example simple forms and the 'Expand all' link) from the behat steps definitions we can check those vars. This neither covers all cases, for example filepicker is specially tricky ( MDL-40033 )
          Hide
          David Monllaó added a comment -

          Let me know if you prefer the redirect() modification, if we can add more of those BEHAT_SITE_RUNNING conditions we open the gate for other cool checking that will solve us more future behat-related headaches.

          Show
          David Monllaó added a comment - Let me know if you prefer the redirect() modification, if we can add more of those BEHAT_SITE_RUNNING conditions we open the gate for other cool checking that will solve us more future behat-related headaches.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Oh, yes. In fact yesterday I was thinking if it wouldn't be perfect to custom-add something to all the JS (a class, a method, a variable...) to be able to evaluate when JS is really ready (at least for normal page loading requiring JS, dialogs surely are another history).

          Also, if by adding BEHAT_SITE_RUNNING conditional code to a FEW places helps, I think it could be a good way to solve general problems here and there. But of course, never, to TRICK the output for a given test. Only "common" things.

          I'd like to see more opinions here.... I keep this open...

          Show
          Eloy Lafuente (stronk7) added a comment - Oh, yes. In fact yesterday I was thinking if it wouldn't be perfect to custom-add something to all the JS (a class, a method, a variable...) to be able to evaluate when JS is really ready (at least for normal page loading requiring JS, dialogs surely are another history). Also, if by adding BEHAT_SITE_RUNNING conditional code to a FEW places helps, I think it could be a good way to solve general problems here and there. But of course, never, to TRICK the output for a given test. Only "common" things. I'd like to see more opinions here.... I keep this open...
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Just guessing if... perhaps... instead of waiting for a given time or to page load... we can inspect something else (like the url/location being served, or some headers inspection...). For example for some other drivers (not selenium), I saw this:

          http://docs.behat.org/cookbook/intercepting_the_redirections.html

          And it would be great if we can achieve the same with Selenium, because I find really natural to say "When I submit the form with/without redirection" and then verify a redirection is/is not set and we wait till the "next" (the 1st not having a redirection) loads (current url/location).

          Just writing while I think... and apart from the idea of introducing BEHAT_SITE_RUNNING conditional code in some key places.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Just guessing if... perhaps... instead of waiting for a given time or to page load... we can inspect something else (like the url/location being served, or some headers inspection...). For example for some other drivers (not selenium), I saw this: http://docs.behat.org/cookbook/intercepting_the_redirections.html And it would be great if we can achieve the same with Selenium, because I find really natural to say "When I submit the form with/without redirection" and then verify a redirection is/is not set and we wait till the "next" (the 1st not having a redirection) loads (current url/location). Just writing while I think... and apart from the idea of introducing BEHAT_SITE_RUNNING conditional code in some key places. Ciao
          Show
          Eloy Lafuente (stronk7) added a comment - A bit more: http://blog.scur.pl/2012/06/conditional-intercepting-redirections-behat-mink/ Ciao
          Hide
          David Monllaó added a comment -

          Thanks for the links Eloy but we already follow redirects using Goutte (is set by default, maybe it was disabled by default when that docu was created) the problem is that when $OUTPUT->redirect_message() the returned HTTP status code is 200 (we redirect using a meta with refresh) and Goutte only follows redirects when

          • vendor/symfony/browser-kit/Symfony/Component/BrowserKit/Client.php
            if ($status >= 300 && $status < 400) {
            

          So we have the same problem using both Goutte and Selenium, thinking on a common way to solve all the redirect+message issues I would propose to add a step definition like I wait to be redirected and there we wait for X seconds where X is the content attribute value of //meta[@http-equiv='refresh'] in this issue's case we also have i_add_a_forum_discussion_to_forum_with() and i_reply_post_from_forum_with() to add it as a sub-step.

          Another option would be to autowait if //meta[@http-equiv='refresh'] is found, but this will run for all steps and will make the suite slower... The test writer is supposed to know if there is a redirect+message so in my opinion rather that auto-check it we should run the step on demand.

          Updating branch with the proposed solution.

          Show
          David Monllaó added a comment - Thanks for the links Eloy but we already follow redirects using Goutte (is set by default, maybe it was disabled by default when that docu was created) the problem is that when $OUTPUT->redirect_message() the returned HTTP status code is 200 (we redirect using a meta with refresh) and Goutte only follows redirects when vendor/symfony/browser-kit/Symfony/Component/BrowserKit/Client.php if ($status >= 300 && $status < 400) { So we have the same problem using both Goutte and Selenium, thinking on a common way to solve all the redirect+message issues I would propose to add a step definition like I wait to be redirected and there we wait for X seconds where X is the content attribute value of //meta [@http-equiv='refresh'] in this issue's case we also have i_add_a_forum_discussion_to_forum_with() and i_reply_post_from_forum_with() to add it as a sub-step. Another option would be to autowait if //meta [@http-equiv='refresh'] is found, but this will run for all steps and will make the suite slower... The test writer is supposed to know if there is a redirect+message so in my opinion rather that auto-check it we should run the step on demand. Updating branch with the proposed solution.
          Hide
          David Monllaó added a comment -

          I pushed the updated patches

          Show
          David Monllaó added a comment - I pushed the updated patches
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Just posting here an unrelated link (yes unrelated to the redirect issue, but related with waits and JS.

          I just found it interesting because what it does is to add some handler to the jQuery events model, so they get notifications every time a function / whatever is executed (ajaxStart()...). So instead of looking for the DOM and similar, just wait until the JS library itself notifies the given action has happened.

          Just guessing if perhaps we could try something similar against YUI (I don't know if it has a similar event model, easily hookable or no, but sounds like something we could try to adhere to and would provide us with valid conditions to end the wait().

          http://blog.scur.pl/2012/06/ajax-callback-support-behat-mink/

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Just posting here an unrelated link (yes unrelated to the redirect issue, but related with waits and JS. I just found it interesting because what it does is to add some handler to the jQuery events model, so they get notifications every time a function / whatever is executed (ajaxStart()...). So instead of looking for the DOM and similar, just wait until the JS library itself notifies the given action has happened. Just guessing if perhaps we could try something similar against YUI (I don't know if it has a similar event model, easily hookable or no, but sounds like something we could try to adhere to and would provide us with valid conditions to end the wait(). http://blog.scur.pl/2012/06/ajax-callback-support-behat-mink/ Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Integrated (25 & master), thanks!

          Show
          Eloy Lafuente (stronk7) added a comment - Integrated (25 & master), thanks!
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Not sure if related or no, but I've got 3 failures here, all them with "nasty_strings.feature"

          01. Catchable Fatal Error: Argument 1 passed to behat_forms::i_fill_the_moodle_form_with() must be an instance of Behat\Gherkin\Node\TableNode, string given in lib/tests/behat/behat_forms.php line 70
              In step `When I fill the moodle form with:'.      # behat_forms::i_fill_the_moodle_form_with()
              From scenario `Use nasty strings on table nodes'. # admin/tool/behat/tests/behat/nasty_strings.feature:26
              Of feature `Transform steps arguments'.           # admin/tool/behat/tests/behat/nasty_strings.feature
          
          02. Catchable Fatal Error: Argument 1 passed to behat_forms::i_fill_the_moodle_form_with() must be an instance of Behat\Gherkin\Node\TableNode, string given in lib/tests/behat/behat_forms.php line 70
              In step `When I fill the moodle form with:'.      # behat_forms::i_fill_the_moodle_form_with()
              From scenario `Use double quotes'.                # admin/tool/behat/tests/behat/nasty_strings.feature:37
              Of feature `Transform steps arguments'.           # admin/tool/behat/tests/behat/nasty_strings.feature
          
          03. Catchable Fatal Error: Argument 1 passed to behat_forms::i_fill_the_moodle_form_with() must be an instance of Behat\Gherkin\Node\TableNode, string given in lib/tests/behat/behat_forms.php line 70
              In step `And I fill the moodle form with:'.        # behat_forms::i_fill_the_moodle_form_with()
              From scenario `Nasty strings with other contents'. # admin/tool/behat/tests/behat/nasty_strings.feature:50
              Of feature `Transform steps arguments'.            # admin/tool/behat/tests/behat/nasty_strings.feature
          
          177 escenarios (174 exitosos, 3 fallidos)
          3581 pasos (3559 exitosos, 19 omitidos, 3 fallidos)
          154m50.108s
          

          And running with --tags 'tool_behat'... ended with exactly the same 3 errors.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Not sure if related or no, but I've got 3 failures here, all them with "nasty_strings.feature" 01. Catchable Fatal Error: Argument 1 passed to behat_forms::i_fill_the_moodle_form_with() must be an instance of Behat\Gherkin\Node\TableNode, string given in lib/tests/behat/behat_forms.php line 70 In step `When I fill the moodle form with:'. # behat_forms::i_fill_the_moodle_form_with() From scenario `Use nasty strings on table nodes'. # admin/tool/behat/tests/behat/nasty_strings.feature:26 Of feature `Transform steps arguments'. # admin/tool/behat/tests/behat/nasty_strings.feature 02. Catchable Fatal Error: Argument 1 passed to behat_forms::i_fill_the_moodle_form_with() must be an instance of Behat\Gherkin\Node\TableNode, string given in lib/tests/behat/behat_forms.php line 70 In step `When I fill the moodle form with:'. # behat_forms::i_fill_the_moodle_form_with() From scenario `Use double quotes'. # admin/tool/behat/tests/behat/nasty_strings.feature:37 Of feature `Transform steps arguments'. # admin/tool/behat/tests/behat/nasty_strings.feature 03. Catchable Fatal Error: Argument 1 passed to behat_forms::i_fill_the_moodle_form_with() must be an instance of Behat\Gherkin\Node\TableNode, string given in lib/tests/behat/behat_forms.php line 70 In step `And I fill the moodle form with:'. # behat_forms::i_fill_the_moodle_form_with() From scenario `Nasty strings with other contents'. # admin/tool/behat/tests/behat/nasty_strings.feature:50 Of feature `Transform steps arguments'. # admin/tool/behat/tests/behat/nasty_strings.feature 177 escenarios (174 exitosos, 3 fallidos) 3581 pasos (3559 exitosos, 19 omitidos, 3 fallidos) 154m50.108s And running with --tags 'tool_behat'... ended with exactly the same 3 errors. Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Whops, perhaps my previous problems are a local thing, feel free to ignore them because I also reported those errors @ MDL-40322 some days ago.

          Show
          Eloy Lafuente (stronk7) added a comment - Whops, perhaps my previous problems are a local thing, feel free to ignore them because I also reported those errors @ MDL-40322 some days ago.
          Hide
          David Monllaó added a comment -

          Hi,

          This issue seems to be breaking other tests http://integration.moodle.org/job/4.-%20Run%20all%20behat%20features%20(master)/18/console I'm guessing (just looked quickly) that in when we get the attribute https://github.com/dmonllao/moodle/compare/moodle:master...MDL-40246_master#L0R81 the browser already redirected.

          Show
          David Monllaó added a comment - Hi, This issue seems to be breaking other tests http://integration.moodle.org/job/4.-%20Run%20all%20behat%20features%20(master)/18/console I'm guessing (just looked quickly) that in when we get the attribute https://github.com/dmonllao/moodle/compare/moodle:master...MDL-40246_master#L0R81 the browser already redirected.
          Hide
          Sam Hemelryk added a comment -

          I've been running the tests for this issue this morning.
          There is another issue that cluttered output that I'm waiting on Eloy to integrate a fix for (http://integration.moodle.org/job/4.-%20Run%20all%20behat%20features%20(master)/19/console).
          I'm re-running the complete suite locally this morning and will report back if I see the same thing David.

          Show
          Sam Hemelryk added a comment - I've been running the tests for this issue this morning. There is another issue that cluttered output that I'm waiting on Eloy to integrate a fix for ( http://integration.moodle.org/job/4.-%20Run%20all%20behat%20features%20(master)/19/console ). I'm re-running the complete suite locally this morning and will report back if I see the same thing David.
          Hide
          Sam Hemelryk added a comment -

          I am passing this now, It's just completed locally and while I saw the three errors Eloy had above I did not experience any other failures.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - I am passing this now, It's just completed locally and while I saw the three errors Eloy had above I did not experience any other failures. Cheers Sam
          Hide
          Damyon Wiese added a comment -

          This issue is fixed! Hurray! Hurray!
          Your issue is fixed, what a wonderful day!

          Cheers, Damyon

          Show
          Damyon Wiese added a comment - This issue is fixed! Hurray! Hurray! Your issue is fixed, what a wonderful day! Cheers, Damyon
          Hide
          David Monllaó added a comment -

          I thought I commented about the 3 failures you are experiencing but I can't see the message; probably you are using the 1.26.0 version of moodlehq/behat-extension, you can search the version in composer.lock; you can delete vendor/ and composer.lock and the behat init.php script will download the correct packages, this 1.26.0 version was introduced by MDL-39489 but reverted as there are framework changes in the way TableNodes behaves and some steps definitions need to be changed.

          Show
          David Monllaó added a comment - I thought I commented about the 3 failures you are experiencing but I can't see the message; probably you are using the 1.26.0 version of moodlehq/behat-extension, you can search the version in composer.lock; you can delete vendor/ and composer.lock and the behat init.php script will download the correct packages, this 1.26.0 version was introduced by MDL-39489 but reverted as there are framework changes in the way TableNodes behaves and some steps definitions need to be changed.
          Hide
          David Monllaó added a comment -

          Ow, I have just seen MDL-40322 about dependencies versions, I'll comment there

          Show
          David Monllaó added a comment - Ow, I have just seen MDL-40322 about dependencies versions, I'll comment there
          Hide
          David Monllaó added a comment -

          This issue has not really solved anything, locally it works as expected, but the CI server still reports failures (http://integration.moodle.org/job/4.-%20Run%20all%20behat%20features%20(master)/) seems the same problem, saucelabs requires too much time and when we are getting the content attribute the page has already been redirected, so the element can not be found in the DOM. Creating a new issue and linking.

          Show
          David Monllaó added a comment - This issue has not really solved anything, locally it works as expected, but the CI server still reports failures ( http://integration.moodle.org/job/4.-%20Run%20all%20behat%20features%20(master)/ ) seems the same problem, saucelabs requires too much time and when we are getting the content attribute the page has already been redirected, so the element can not be found in the DOM. Creating a new issue and linking.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: