I did some further testing and confirmed that this issue occurs only when using a custom theme. Switching to a core theme like Claro or Olivero eliminates the error, which suggests the problem might stem from hidden or visually collapsed required fields that become non-focusable.
The browser's native constraint validation throws the "invalid form control not focusable" error when a required field (like a select or text area) is hidden via CSS or not properly rendered in the DOM. One possible solution is to ensure that required fields remain focusable—either by avoiding hidden required inputs or by setting required dynamically via JS only when the field is visible.
I agree with the core concern—calling ::getFormObject() twice is inefficient and can lead to unexpected behavior like duplicate hook_entity_create() triggers. The proposed fix to retrieve the entity manually from the route match object is a clean and straightforward improvement.
Regarding @catch's suggestion: copying the logic from FormController::getContentResult() into WorkspacesHtmlEntityFormController seems reasonable here, especially since it avoids unnecessary indirection and the performance hit of redundant instantiation. It's only a few lines and would help make the control flow clearer and more predictable in this workspace-specific context.
After reviewing the Symfony Flex implementation and Composer plugin architecture, it’s clear this workaround is necessary due to a missing Composer API that would allow plugins to inspect the packages being installed at `composer require` time.
I’ve reviewed the proposal in #3355485 and support the recommendation to create an upstream Composer issue. I’ve filed a request (or added a comment to an existing Composer issue) suggesting a new event or API to cleanly expose the list of packages to be installed, which would allow us to remove the backtrace hack entirely.
himani_219 → made their first commit to this issue’s fork.
himani_219 → created an issue.
"You can try a few optimizations to reduce memory usage during install_config_import_batch. First, increasing the memory_limit in php.ini might help handle large configurations. Another option is reducing the batch size in core/lib/Drupal/Core/Batch/BatchStorage.php to process smaller chunks at a time, which lowers peak memory consumption. If skipping the config import during installation is feasible, you could install the site with a minimal profile and then run drush cim after installation to handle the import separately. Additionally, temporarily disabling non-essential modules during installation and enabling garbage collection (gc_enable()) before the batch process starts can help free up memory.
"Hey, I ran into a similar issue before, and in my case, it was related to DDEV's docroot configuration. Could you check your .ddev/config.yaml file and make sure docroot is set correctly? For a standard Drupal setup, it should be docroot: web. If it's misconfigured, the web server might not be able to locate index.php, causing a 403 error.
Also, after making any changes, try running ddev restart to apply them. If that doesn’t help, could you confirm whether your web directory (or the appropriate docroot) actually contains index.php? That file is essential for serving Drupal.
If the issue persists, you might want to check out the DDEV troubleshooting guide (https://ddev.readthedocs.io/en/stable/users/usage/troubleshooting/)
himani_219 → created an issue.