- Issue created by @jrb
- Status changed to Needs review
7 months ago 8:51pm 25 July 2024 - πΊπΈUnited States jrb Raleigh-Durham Area, NC, USA
Here is a patch that adds a counter and uses that to make sure that
uniqueBundleId
is always unique.This fixes our issue with Flag and should fix the other referenced issues above.
- Status changed to Needs work
7 months ago 9:44pm 25 July 2024 The Needs Review Queue Bot β tested this issue.
While you are making the above changes, we recommend that you convert this patch to a merge request β . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)
- Status changed to Needs review
7 months ago 12:37am 26 July 2024 - Status changed to Needs work
7 months ago 9:42am 26 July 2024 The Needs Review Queue Bot β tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide β to find step-by-step guides for working with issues.
- Merge request !8944Issue #3463875: Add, use counter for making bundle IDs passed to loadjs unique. β (Open) created by jrb
- Status changed to Needs review
7 months ago 3:06pm 26 July 2024 - πΊπΈUnited States jrb Raleigh-Durham Area, NC, USA
Here's a patch from the MR.
Note that this patch is for 11.x while the patch in #2 above will apply to 10.x.
- Status changed to Needs work
7 months ago 6:19pm 26 July 2024 - πΊπΈUnited States smustgrave
Thanks for reporting, as a bug can we get a test case showing the issue
- π΅π±Poland michal_liszka
Despite applying patch #2 for Drupal 10, the problem persists when request the controller for a response via AJAX dialogs.
The first request executes correctly, and the response is accurate on the second attempt. However, the same error continues to occur:
An error occurred during the execution of the Ajax response: LoadJS
Code snippet:
<a href="{{ url('controller_route_name') }}" class="use-ajax" data-dialog-options="{{ dialog_options|json_encode() }}" data-dialog-type="modal" data-ajax-http-method="GET" >
- πͺπΈSpain espurnes
After updating to Drupal version 10.3.1 (I was before at version 10.2.4), the "An error occurred during the execution of the Ajax response: LoadJS" error is generated on my custom code after CTAs with ajax actions that should replace page content. Big pipe is not enabled. So it should be related with the way I perform the ajax calls (or the addition of the libraries) and the way drupal 10.3 processed them.
Applying patch #2 solves the issue.
- π³π±Netherlands spokje
I've stumbled over this when trying to open a configuration on
/admin/config/development/configuration
more than once.
Might make it easier to reproduce in core only for testing.Patch #2 worked for me.
- Status changed to Needs review
7 months ago 5:21pm 12 August 2024 - π³π±Netherlands spokje
MR now has a test. Tried to do this in
\Drupal\Tests\system\FunctionalJavascript\ModalRendererTest
but couldn't get the error there, maybe/probably due to the lack of JS/CSS on that page?So I decided to use a bit of
\Drupal\Tests\config\Functional\ConfigImportUITest
in a new FunctionalJavascriptTest.
Not great, not fast, but we need JS testing for this and this was the only place in core I could reproduce the error.MR passes, test-only fails where it's expected to fail.
- First commit to issue fork.
- Merge request !9184Resolve #3463875 "Bigpipe loadjs errors isdefined" β (Closed) created by godotislate
Looking at the documentation for loadjs, there is a
isDefined()
method that checks for existing bundle IDs, so I think the counter might be unnecessary altogether. I created a new MR 9184 based on the original MR, and added isDefined() checks. It passes all tests, including the new one from #13.godotislate β changed the visibility of the branch 3463875-bigpipe-loadjs-errors to hidden.
- Status changed to RTBC
6 months ago 1:23pm 19 August 2024 - πΊπΈUnited States smustgrave
Believe adding the isDefined check makes sense.
- Status changed to Needs work
6 months ago 2:35am 26 August 2024 - π³πΏNew Zealand quietone
Trying for a descriptive of what is being fixed. I also left 2 comments in the MR about documentation that need attention.
- Status changed to Needs review
6 months ago 5:45am 26 August 2024 - π³π±Netherlands spokje
Thanks @quietone, applied your suggestion and added a comment.
- Status changed to RTBC
6 months ago 2:15pm 29 August 2024 - πΊπΈUnited States smustgrave
Believe additional feedback has been addressed.
Hoping eventually can help close resolved threads but can't help there either :(
- Status changed to Needs work
6 months ago 2:48pm 12 September 2024 - π«π·France nod_ Lille
I'm not sure why ajax.instanceIndex is 0 in each case, but it is. Maybe there are some cases where Drupal.ajax is called multiple times, resetting Drupal.ajax.instances?
In the case of bigpipe we reuse the same ajax object to execute all the ajax commands so that makes sense. What is surprising is why the same file is added in two different ajax requests, it means the ajax page state is not updated for some reason.
I tried with layout_builder_browser and could replicate the problem without removing the ajaxInstanceIndex from the bundle ID. Why is the ajaxIndex removed from the bundle Id?
I tried with layout_builder_browser and could replicate the problem without removing the ajaxInstanceIndex from the bundle ID. Why is the ajaxIndex removed from the bundle Id?
Replied in MR comment, but the idea is that the same resource is being prevented from being loaded twice by using
loadJs.isDefined()
to check whether the bundle ID still exists. The counter then should become unnecessary.Is the problem still replicable with layout_builder_browser even with the latest MR? If so, can you provide steps to reproduce?
- Status changed to Needs review
5 months ago 1:22am 20 September 2024 - πΊπΈUnited States pcate
I just ran into this error when loading a view block on Drupal 10.3.5. Layout Builder is not used on the site, the block was added via the regular block layout page. The big pipe placeholder element is rendered on the page but the error prevents it being replaced with the actual content.
The MR resolved the error and loaded the block fine.
- π«π·France nod_ Lille
Ok, Happy with the JS changes.
For the test, I understand but i'm not comfortable using a sideeffect of the config UI to test an ajax regression. Can we make a more explicit test by trying to load the same file twice through add_js and add_css? It's a missing test so I guess that's why you had to create a new one: #3301769: Add test for the new add_js command β
- π³π±Netherlands spokje
For the test, I understand but i'm not comfortable using a sideeffect of the config UI to test an ajax regression. Can we make a more explicit test by trying to load the same file twice through add_js and add_css? It's a missing test so I guess that's why you had to create a new one: #3301769: Add test for the new add_js command
I can understand this isn't a nice direct test, but it was the only way I could reproduce it in core.
I'm a tad confused why add_js/add_css could reproduce the issue when the commands are new, whilst I think the config UI didn't change that much in recent time?
Anyway, I'm sure someone with actual knowledge will pick this up in the end.
- π«π·France nod_ Lille
Committed and pushed d44fb628e45 to 11.x and 0b0d880cbfd to 11.0.x and b60151a2656 to 10.4.x and 9b977fc3f84 to 10.3.x. Thanks!
- π¦πΊAustralia interlated
This fixed a problem with ajax modals
- Install layout builder, linked_field
- Link the title in layout builder.
- install the code below in the custom theme
- clear cache
- Open modal once
- Close modal
- Open again.A cryptic 'LoadJS' error message is returned on the console. Line 1143 ajax.js.
function tn_preprocess_field(&$variables) { $element = $variables['element']; if ($element['#field_name'] == 'title' && $element['#bundle'] == 'course' && $element['#view_mode'] == '_custom') { tn_add_modal_attributes($variables); } } function tn_add_modal_attributes(&$variables) { $variables['items'][0]['content']['#options']['attributes']['class'][] = 'use-ajax'; $variables['items'][0]['content']['#options']['attributes']['data-dialog-type'][] = 'modal'; $variables['items'][0]['content']['#options']['attributes']['data-dialog-options'][] = '{"width":"80vw","height":"100%", "dialogClass": "course-dialog", "position": {"my": "right top", "at": "right top"}, "show":"slideDown","hide":"slideUp"}'; $variables['items'][0]['content']['#options']['attributes']['data-ajax-focus'][] = 'none'; }
Automatically closed - issue fixed for 2 weeks with no activity.
- π¨π¦Canada ambient.impact Toronto
Ah, I see I'm not the only one that was utterly confused by the cryptic "LoadJS" error. It turns out the library did this to keep the size down, which I personally feel was a bad move because it's so confusing and non-helpful. I opened a pull request to change it, but since they still want to keep the size down, they're only willing to throw the bundle ID as the error message rather than a fully descriptive thing that says why it was thrown. Glad to see this is being handled on the Drupal side.