Closed danepowell closed 7 years ago
I've seen this happening too. My solution was to remove the sometimes-failing test, since this particular site wasn't actively using Panelizer, and the test where this failure most frequently occurred was for Panelizer functionality.
Is this for Lightning tests only or for all tests? I'm not sure I'd consider this a BLT issue.
I'm not running Lightning tests. It's BLT-based project tasks. Although it is a Lightning-based install.
So it may not be a BLT issue per se (more likely a bug with Chromedriver, or a problem with responsive formatting), but BLT could probably make everyone's life easier by implementing some sort of workaround.
See related: https://github.com/geerlingguy/drupal-vm/issues/1152 (well, only sorta).
I don't think we're running tests within a DrupalVM on Travis, but that thread might have a useful recommendation of "known good" package versions: https://github.com/geerlingguy/drupal-vm/issues/1152#issuecomment-280092215
Specifically, it might be worth trying to upgrade selenium to 3.0.1 and/or chromedriver to 2.25 or 2.27. Although I'm still unconvinced that this is necessarily a bug. Seems more like a race condition with responsive layouts.
We've had to add this in a bunch of places to get around this issue. This makes me cringe a little, but if it helps anyone...
When I click "Promotional"
And I wait for AJAX to finish
This waits 5 seconds and can add an obnoxious amount of time to the build if you have to use it enough. Definitely will be following this issue closely and happy to help if I can...
You might also have luck switching back to phantomjs... see https://github.com/acquia/blt/issues/1134#issuecomment-284428843
behat:
paths:
- your-paths-go-here
launch-selenium: false
launch-phantomjs: true
Just a note that you need to run blt tests:behat
locally after making this change. This will trigger changes to your local config that must then be committed.
True—and note that if you're like me and do some work inside Drupal VM and some work on your host, this might also change some paths and get Behat all confused!
For a lovely companion bug to this one, check out https://github.com/acquia/blt/issues/1201 — I don't know which pain is worse—having Chromedriver always fail on local environments, or having PhantomJS poop out about 3/4 of the time on Travis CI...
Suddenly, today, I'm getting this when using @javascript
-tagged tests with chromedriver on Travis CI:
Drupal\DrupalExtension\Context\MinkContext::assertAtPath()
[ERROR - 2017-04-06T21:46:43.946Z] Session [6cc52470-1b12-11e7-8ba6-f71a84bbd51d] - page.onError - msg: AjaxError:
An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /quickedit/attachments
StatusText: error
ResponseText:
ReadyState: 0
:262 in error
[ERROR - 2017-04-06T21:46:43.947Z] Session [6cc52470-1b12-11e7-8ba6-f71a84bbd51d] - page.onError - stack:
error (http://127.0.0.1:8888/core/misc/ajax.js?v=8.3.0:965)
complete (http://127.0.0.1:8888/core/misc/ajax.js?v=8.3.0:510)
i (http://127.0.0.1:8888/core/assets/vendor/jquery/jquery.min.js?v=2.2.4:2)
fireWith (http://127.0.0.1:8888/core/assets/vendor/jquery/jquery.min.js?v=2.2.4:2)
z (http://127.0.0.1:8888/core/assets/vendor/jquery/jquery.min.js?v=2.2.4:4)
(anonymous function) (http://127.0.0.1:8888/core/assets/vendor/jquery/jquery.min.js?v=2.2.4:4)
dispatchEvent (:0)
U (phantomjs://webpage.evaluate():119)
$ (phantomjs://webpage.evaluate():108)
$ (phantomjs://webpage.evaluate():101)
gh (phantomjs://webpage.evaluate():141)
sh (phantomjs://webpage.evaluate():152)
(anonymous function) (phantomjs://webpage.evaluate():152)
(anonymous function) (phantomjs://webpage.evaluate():152)
(anonymous function) (phantomjs://webpage.evaluate():153)
:262 in error
Strangely, this happens if I have the following in project.yml
:
behat:
paths:
- '${repo.root}/tests/behat'
launch-selenium: true
launch-phantomjs: false
I thought that would disable phantomjs and use chromedriver, no?
See related: Running Selenium with the new Headless Chrome
This appears to be a bug in Chromedriver.
As a solution, I have added headless chrome support to BLT. You can now use behat.web-driver: chrome
rather than Selenium or PhantomJS.
See #1705
My system information:
Since upgrading to the BLT release that switched to Chromedriver, we're seeing intermittent (~50%) Behat failures. The error is:
Typically this is on administrative pages, especially bulk-edit views.
I suspect it's a race condition with responsive formatting. When you first load the page on a small viewport, it gets rapidly reformatted to e.g. consolidate menu tabs, and things shift around. Simply adding a 2-second delay to tests after page loads might help, haven't had time to test anything yet.