Problem/Motivation

Drupal\Tests\layout_builder\FunctionalJavascript\InlineBlockPrivateFilesTest is randomly failing at the moment. The fail is:

1) Drupal\Tests\layout_builder\FunctionalJavascript\InlineBlockPrivateFilesTest::testPrivateFiles
Behat\Mink\Exception\ElementNotFoundException: Form field with id|name|label|value "files[settings_block_form_field_file_0]" not found.

/var/www/html/vendor/behat/mink/src/Element/TraversableElement.php:292
/var/www/html/core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockPrivateFilesTest.php:272
/var/www/html/core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockPrivateFilesTest.php:177
/var/www/html/core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockPrivateFilesTest.php:120
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:726

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

alexpott created an issue. See original summary.

alexpott’s picture

Status: Active » Needs review
StatusFileSize
new2.04 KB

Let's cause it fail all the time...

Status: Needs review » Needs work

The last submitted patch, 2: 3315490-2-test-only.patch, failed testing. View results

alexpott’s picture

Status: Needs work » Needs review
StatusFileSize
new2.84 KB

Status: Needs review » Needs work

The last submitted patch, 4: 3315490-4.patch, failed testing. View results

alexpott’s picture

Status: Needs work » Needs review
StatusFileSize
new4.12 KB

Let's get a screenshot of what happens

Status: Needs review » Needs work

The last submitted patch, 6: 3315490-6.patch, failed testing. View results

alexpott’s picture

Status: Needs work » Needs review
StatusFileSize
new4.29 KB

Status: Needs review » Needs work

The last submitted patch, 8: 3315490-8.patch, failed testing. View results

alexpott’s picture

Status: Needs work » Needs review
StatusFileSize
new2.13 KB
alexpott’s picture

StatusFileSize
new2.04 KB

Status: Needs review » Needs work

The last submitted patch, 11: 3315490-11-test-only.patch, failed testing. View results

alexpott’s picture

Status: Needs work » Needs review
StatusFileSize
new6.15 KB

Let's get more info...

Status: Needs review » Needs work

The last submitted patch, 13: 3315490-13.patch, failed testing. View results

alexpott’s picture

Status: Needs work » Needs review
StatusFileSize
new6.4 KB

Status: Needs review » Needs work

The last submitted patch, 15: 3315490-15.patch, failed testing. View results

alexpott’s picture

Status: Needs work » Needs review
StatusFileSize
new6.51 KB

Status: Needs review » Needs work

The last submitted patch, 17: 3315490-17.patch, failed testing. View results

alexpott’s picture

Status: Needs work » Needs review
StatusFileSize
new6.61 KB

So the problem is that for some reason clicking on the remove button in replaceFileInBlock doesn't work...

  /**
   * Replaces the file in the block with another one.
   *
   * @param \Drupal\file\FileInterface $file
   *   The file entity.
   */
  protected function replaceFileInBlock(FileInterface $file) {
    $assert_session = $this->assertSession();
    $page = $this->getSession()->getPage();
    $this->clickContextualLink(static::INLINE_BLOCK_LOCATOR, 'Configure');
    $assert_session->assertWaitOnAjaxRequest();
    $page->pressButton('Remove');
    $this->attachFileToBlockForm($file);
    $page->pressButton('Update');
    $this->assertDialogClosedAndTextVisible($file->label(), static::INLINE_BLOCK_LOCATOR);
  }
alexpott’s picture

StatusFileSize
new6.75 KB

Borrowing code from \Drupal\Tests\layout_builder\FunctionalJavascript\InlineBlockTestBase::removeInlineBlockFromLayout() which also clicks a remove button in off canvas after opening the setting tray.

alexpott’s picture

StatusFileSize
new1.7 KB

Another one done.

alexpott’s picture

StatusFileSize
new1.11 KB
new1.7 KB

Let's use the local variable. Makes no difference to the fix.

alexpott’s picture

Interesting fail on postgres - so #20 does not 100% fix the issue but it does help in 349/350 instances... Maybe this is good enough to commit here and open a follow-up to make better?

The last submitted patch, 21: 3315490-21.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 22: 3315490-21.patch, failed testing. View results

wim leers’s picture

Status: Needs work » Reviewed & tested by the community
  1. +++ b/core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockPrivateFilesTest.php
    @@ -171,9 +171,9 @@ protected function replaceFileInBlock(FileInterface $file) {
    +    $assert_session->waitForElement('css', "#drupal-off-canvas input[value='Remove']");
         $assert_session->assertWaitOnAjaxRequest();
    -    $page->pressButton('Remove');
    -    $assert_session->assertWaitOnAjaxRequest();
    +    $page->find('css', '#drupal-off-canvas')->pressButton('Remove');
    

    Removes one excess "wait on AJAX request" and just waits for the button to be pressed to appear. Makes sense.

  2. +++ b/core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockPrivateFilesTest.php
    @@ -269,6 +269,7 @@ protected function getFileSecret(FileInterface $file) {
       protected function attachFileToBlockForm(FileInterface $file) {
         $assert_session = $this->assertSession();
         $page = $this->getSession()->getPage();
    +    $this->assertSession()->waitForElementVisible('named', ['field', 'files[settings_block_form_field_file_0]']);
         $page->attachFileToField("files[settings_block_form_field_file_0]", $this->fileSystem->realpath($file->getFileUri()));
         $assert_session->assertWaitOnAjaxRequest();
         $this->assertNotEmpty($assert_session->waitForLink($file->label()));
    

    This one looks more suspicious: we're waiting for something even though we didn't do anything here, so why wait?

    Unless this is a helper method that should always be called after waiting for an AJAX response maybe?

    Hah, #23 seems to confirm this.

    What would IMHO help here is to use something like \Drupal\Tests\ckeditor5\FunctionalJavascript\AdminUiTest::getAjaxResponseCount() — that would make these tests deterministic in terms of how many AJAX responses should've been processed at every point. Right now, the code is just sprinkled with assertWaitOnAjaxRequest() at both necessary and unnecessary times; it's both waiting too much and too little, which is why it's so sensitive to timing problems.

    Opened #3316274: Stabilize FunctionalJavascript testing AJAX: add ::assertExpectedAjaxRequest() for that.

I agree with

Maybe this is good enough to commit here and open a follow-up to make better?

🚢

P.S.: ironically, the failures in #21 and #22 are in Drupal\FunctionalJavascriptTests\Tests\JSWebAssertTest, 100% unrelated to this patch :P

catch’s picture

Version: 10.1.x-dev » 9.4.x-dev
Status: Reviewed & tested by the community » Fixed

Committed/pushed to 10.1.x, cherry-picked back through to 9.4.x, thanks!

  • catch committed eb62ad3 on 10.0.x
    Issue #3315490 by alexpott, Wim Leers: Random fail in Drupal\Tests\...
  • catch committed 7690a8e on 10.1.x
    Issue #3315490 by alexpott, Wim Leers: Random fail in Drupal\Tests\...
  • catch committed 2831fc6 on 9.4.x
    Issue #3315490 by alexpott, Wim Leers: Random fail in Drupal\Tests\...
  • catch committed 140b06e on 9.5.x
    Issue #3315490 by alexpott, Wim Leers: Random fail in Drupal\Tests\...
catch’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.