Issue #3040507: Add FunctionalJavascript coverage for the embed flow
Adds the FunctionalJavascript coverage this issue has been open for.
Why there was none
The flow the module exists for is entirely AJAX — the CKEditor 5 toolbar button, the entity browser iframe, the inline entity form inside it, and the embed step. None of it is reachable from BrowserTestBase, which is why the existing tests stopped at "the form renders".
What ParagraphsIEFEmbedTest covers
testParagraphTypeSelector — the toolbar button opens the dialog, and the module's own entity browser widget renders one image button per allowed paragraph type, each carrying the bundle in the data attribute its JavaScript reads on click.
testEmbedParagraph — the whole round trip:
- choose a paragraph type;
- that type's inline entity form loads in the iframe;
- saving it returns to the dialog, where this module has replaced the back button with Edit paragraph, pointing at the paragraph's own edit form;
- Embed inserts the widget and the editor data carries
data-entity-type="paragraph"; - the node saves and renders the paragraph.
Verified against Drupal 11.4.5. 16 tests green in total — 7 unit, 7 functional, 2 functional-javascript.
Two findings worth knowing
Editors need a permission that is easy to miss. Entity Browser generates access <browser> entity browser pages per browser. Without access paragraph_items entity browser pages, the dialog opens on an Access denied page rather than the type selector. That is what the test hit first, and it is worth a line in the docs.
The flow logs a JavaScript error that is not ours. Selecting an embedded entity makes Entity Embed build its widget balloon toolbar, which reads icons.pencil — an export CKEditor 5 removed in v47. The embed still works, but WebDriverTestBase fails any test that logs a console error, so this would fail every test that embeds anything. Rather than disable the check, the test discards that one error by signature and still fails on any other. See #3619182 — note the fix belongs in Entity Embed, not here.
Running them
The drupalci container ships no browser, so:
make selenium-start # once per container
make test-local-js
make selenium-stopselenium-start puts a Selenium container on a shared network with the module container so the browser can reach the site as web, mirroring what drupal.org CI does. It uses selenium/standalone-chromium because standalone-chrome has no Apple Silicon build.
CI needs no change — the shared template's test jobs already attach a Selenium service and _PHPUNIT_TESTGROUPS defaults to every test in the module, so these run automatically.