Problem/Motivation
Random, inconsistent errors in the ckeditor5 FunctionalJavascript tests.
Testing Drupal\Tests\ckeditor5\FunctionalJavascript\MediaTest
..............E........ 23 / 23 (100%)
Time: 07:06.351, Memory: 6.00 MB
There was 1 error:
1) Drupal\Tests\ckeditor5\FunctionalJavascript\MediaTest::testLinkManualDecorator with data set "unrestricted" (true)
Behat\Mink\Exception\ElementNotFoundException: Element matching css ".ck-balloon-panel_visible .ck-balloon-rotator__content > .ck.ck-link-actions" not found.
in https://www.drupal.org/pift-ci-job/2564452
10 Jan 2023 https://www.drupal.org/pift-ci-job/2564081
27 Mar 2023 https://www.drupal.org/pift-ci-job/2626370
Steps to reproduce
In a patch in another issue
I took screenshots just before the "balloon assertion" at line 1073.
Here's what a screenshot from a passing test looks like:

In another patch I took screenshots at the same spot for failing tests.
That looks like this:

Upon close inspection we see the differences:
The failing one has a different "balloon" (which is why the test fails) and an URL in the textfield below the actual media.
That textfield is actually the caption edit field, and seems to be default on in this test.
The test selects the media to be able to edit it by doing a
$this->assertNotEmpty($drupalmedia = $assert_session->waitForElementVisible('css', '.ck-content .ck-widget.drupal-media'));
$drupalmedia->click();
and seeing that '.ck-content .ck-widget.drupal-media' is the whole area surrounded by the blue border in the first image, there's a chance we click on the caption edit area.
When we do that the behaviour of the link-adding changes and doesn't follow the assertions in the test any more.
Proposed resolution
Toggle the Caption edit capability off, so we're sure we never add a link in there, instead of the wanted link on the media.
Remaining tasks
There are still 2 random test failures left that seem to stem from the inner bowels of CKEditor 5. To me they look like an upstream issue, but since I can't really pinpoint the root cause of those and seeing the fact that this patch drops the failure rate from about 10 in 1500 down to 6 in 45.000, I take that as a win.
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | 3332456-19.patch | 1.05 KB | spokje |
Comments
Comment #2
jastraat commentedComment #3
jastraat commentedComment #4
wim leersUgh! Thanks for reporting this! 🙏😊
Comment #5
wim leersPer #3325336-13: Add explicit test coverage to prove multiple CKEditor 5 instances on the same page can co-exist, in this DrupalCI run.
Comment #6
quietone commentedUpdating title per special issue titles.
Does this need two issues or is the same underlying problem?
Comment #7
jonathan1055 commentedThis happened on core 9.5 today. I know that we know this now, but adding the link for future reference
https://www.drupal.org/pift-ci-job/2626370
Comment #8
spokje@quietone in #6
I _think_ I found the problem with
MediaTest::testLinkManualDecorator()and that seems unrelated toMediaTest:: testEditableCaption(), so repurposing this issue for the first failure and creating a new issue for the second one.Comment #9
spokjeComment #10
spokjeLet's first proof that running
MediaTest::testLinkManualDecorator()alone, without any other tests in\Drupal\Tests\ckeditor5\FunctionalJavascript\MediaTeststill produces a random test failure.Here's a patch that runs
MediaTest::testLinkManualDecorator()andMediaTest::testLinkManualDecorator()alone 1500 times.Comment #11
spokjeThe actual fix should be back-portable (is that even a word?) to 9.4.x if needed, but since I'm needing to run the patches multiple times to proof both the "random" and the "failure" bit in random failure are solved, putting this to 11.x-dev, so I don't need to manually change the branch manually a gazillion times.
Comment #12
spokjeThe normal routine to prove a random failure is fixed is to run the failing patch and the patch with the fix at the same time, whilst the latter has to have ~8000 - 10.000 failure free runs to prove it's credibility.
So let's do that here (and do a write up in the IS to explain why this is the fix).
Comment #13
spokjeComment #14
spokjeComment #15
spokjeComment #16
spokjeHmmm,
promising, but the lack of a roll of dried tobacco leaves that people smoke, like a cigarette but bigger and without paper around it is disheartening.
At the very least the failure rate has dropped dramatically.
The failures in Sqlite are table locks, which most probably happen because I started 5 1500x runs at the same time.
The single test failure in
PHP 8.1 & MySQL 5.7is most probably cause by the fact that after I click the "Toggle caption off"-balloon-button (or rather, let TestBot click it 1500 times), I have no waiting period for the text-box to disappear and the "Drupal Media toolbar" being updated.Let's add that wait and see what happens with the attached patches.
Comment #17
spokjeComment #18
spokjeSo there are 2 remaining random test failures:
and
Both are "wierd" (Well, wadda you expect from random JS failures...).
Looking at patch [3362864-60], which adds some screenshots and logging when those failures occur:
1. The screenshot shows that the link was _NOT_ created and the expected balloon is _NOT_ present.

Weird stuff since it has passed all assertions on buttons being present, so the only thing I can come up with is that every once in a blue moon the actual CKEditor 5 (so not the Drupal code around it) fails to create a link.
2. The screenshot shows that the link was created and the expected balloon is present.

However the contents of
getEditorDataAsHtmlStringis , which seems "odd".My gut feeling is that 1) could be an upstream problem and 2) being a result of 1).
I'm a bit unsure if it's worth to open a new follow-up issue on these, since the failure rate seems in the range of /shrug-js-tests-fail-once-every-blue-moon.
Comment #19
spokjeSeeing the fact that this change drops the failure rate from about 10 in 1500 down to 6 in 45.000, and that there's a (IMHO) valid root cause identified, I'm going to post the actual patch for review.
The decision if we need a follow-up for the remaining (very less frequent) test-failures remains open.
Comment #20
spokjeComment #21
smustgrave commentedThink it if it significantly helps the fail rate that's better then what's currently there. I'm +1 for opening a follow up for the other failures (sticking to the agile thought) but will let the committer decide if it's worth it.
Comment #26
lauriiiCommitted 3b6179f and pushed to 11.x. Thanks! Cherry-picked all the way down to 9.5.x.