Some integration tests are flaky WRT "loader background"

[cwillisf]

Expected Behavior

Integration test results should only depend on the code: re-running a failed test without any code changes should never lead to success.

Actual Behavior

Occasionally, some of the integration tests fail with an error like this:

 FAIL  test/integration/blocks.test.js (57.199s)
  ● Working with the blocks › Blocks report when clicked in the toolbox
    WebDriverError: unknown error: Element <span>...</span> is not clickable at point (59, 74). Other element would receive the click: <div class="loader_background_2DPrW">...</div>

I have personally seen this issue with blocks.test.js and backpack.test.js but I suspect it's possible with other tests as well. These tests seem to fail for me locally more often than on Travis CI, but I have seen both.

Example: https://travis-ci.org/LLK/scratch-gui/builds/506044876#L2046

I believe this is a timing issue related to the loading / project creation screen sometimes being in the way of the test's simulated click.

Steps to Reproduce

1. Build with npm run build
2. Run integration tests with npm run test:integration

Alternatively:

1. Build with npm run build
2. Run an individual integration test with `./node_modules/.bin/jest test/integration/backpack.test.js'

[cwillisf]

I can fix this in an individual test by adding a step that waits for the loading screen node to become "stale" but it might be a good idea to fix it on a more systemic level, maybe in the Selenium helpers. On the other hand, there may be tests that don't want to wait for the loading screen to go away, either because they need to test something about the loading screen or because it's suppressed in some situations (is it?)

Anyway: input welcome!

CC @rschamp @paulkaplan @benjiwheeler

[kchadha]

Seen in build for PR from greenkeeper to update scratch-storage.

Unfortunately we cannot manually trigger a new build for PRs (only for branch builds), so I've attached the raw log from the broken build here.
broken-build-log.txt

Here is the gist of the actual failure:

FAIL test/integration/blocks.test.js (57.312s)
  ● Working with the blocks › Blocks report when clicked in the toolbox
    WebDriverError: element click intercepted: Element <span>...</span> is not clickable at point (59, 74). Other element would receive the click: <div class="loader_background_2DPrW">...</div>
      (Session info: headless chrome=74.0.3729.157)
      (Driver info: chromedriver=74.0.3729.6 (255758eccf3d244491b8a1317aa76e1ce10d57e9-refs/branch-heads/3729@{#29}),platform=Linux 4.4.0-101-generic x86_64)
      
      at Object.checkLegacyResponse (node_modules/selenium-webdriver/lib/error.js:546:15)
      at parseHttpResponse (node_modules/selenium-webdriver/lib/http.js:509:13)
      at doSend.then.response (node_modules/selenium-webdriver/lib/http.js:441:30)
          at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:189:7)
      From: Task: WebElement.click()
      at thenableWebDriverProxy.schedule (node_modules/selenium-webdriver/lib/webdriver.js:807:17)
      at WebElement.schedule_ (node_modules/selenium-webdriver/lib/webdriver.js:2010:25)
      at WebElement.click (node_modules/selenium-webdriver/lib/webdriver.js:2092:17)
      at test/helpers/selenium-helper.js:110:73
      at ManagedPromise.invokeCallback_ (node_modules/selenium-webdriver/lib/promise.js:1376:14)
      at TaskQueue.execute_ (node_modules/selenium-webdriver/lib/promise.js:3084:14)
      at TaskQueue.executeNext_ (node_modules/selenium-webdriver/lib/promise.js:3067:27)
      at asyncRun (node_modules/selenium-webdriver/lib/promise.js:2927:27)
      at node_modules/selenium-webdriver/lib/promise.js:668:7
          at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:189:7)