Ajax page state header can become too large

Thanks for the report. I'll verify and get a fix out or post back swiftly as it worked the last time I used it!

I did a fresh site build of a plain 10.2.7 site and changed my ddev setup to php 8.2 (8.2.20). With HTMX as the only contrib module, I could not reproduce the error. I've attached a video → . I don't know what to suggest since your logs are empty. If this is in a built up site, could there be a conflict with another module?

Hi,

Thanks for looking into this. Yes, in your video it looks nice. In this case, sure it could be some conflict with other module(s). I would suggest setting the status to "Postponed (maintainer needs more info)" instead of closing directly because others might have this issue, and for me atm it's unusable.
I will try to find out more information from debugging to share since on your end it's fine, I do have other contrib modules installed. Here's a video of what happens for now: https://www.awesomescreenshot.com/video/29945599?key=a0cd9d8c603272365a1...

Thanks for continuing to examine this on your end for clues. Switching the status of this issue to "needs info" is the right idea too. Because HTMX is designed to work with standard HTML responses, you can copy the failing request from your network tab and load it directly as your admin user. In a working setup, the dialog tag will be present and populated. I've added a screenshot. In your case, perhaps you can get better insight into the 500 error working with the request directly.

I have more information.
So, in my project (that was originally a 9.5.* updated to 10.2.7) with all sorts of contrib modules installed vs. a project that I have for testing stuff using 10.2.7, and just a few contrib modules: the first one fails, the other one works well.

For the broken one I discovered the following errors at a higher level:

Premature end of script headers: index.php, referer: https://car.ddev.site/admin/structure/htmx-block
AH01070: Error parsing script headers, referer: https://car.ddev.site/admin/structure/htmx-block
AH01075: Error dispatching request to : , referer: https://car.ddev.site/admin/structure/htmx-block

After analysing the response in web/core/lib/Drupal/Core/EventSubscriber/FinishResponseSubscriber.php, I noticed that the broken site has a hx-trigger-after-swap header in the response that the other one does not.

Removing that header results in the dialog appearing. Now, idk why this difference, but sharing this information for now. I just hope it's not something stupid from a custom module, but I'll try to investigate further :D
Here are the screenshots of the two site responses, dump of headers:

Broken response:

Working response:

That's super helpful. Removing the header makes it work because the header size is huge. It looks like there is markup stored in drupalSettings. We may have to revert or adjust a design choice.

HTMX allows us to trigger an event via header and include data for that event. So rather than appending JSON into a script tag with new ajax page state at the bottom of the DOM and then spending time to find, load and parse it as core ajax does, we included the data in this way.

It looks like Magento has had a similar problem with cache tags:

• https://magento.stackexchange.com/questions/287621/ah01070-error-parsing...
• https://alanastorm.com/fixing-x-magento-tags-too-large-errors/

Oh, I see.
Well, I'm glad that this helps, and now you have the necessary info. If you need anything else, lemme know.

@bbu23 I've tagged version 1.2.2-alpha1 with a refactor to address this issue. Would you be willing to see if it fixes your failure?

@FatherShawn sure, thanks. I'll try it out and let ya know. 😊

The error is gone, I got the popup and added a successfully added block.
How do I load it now? Using the method here: https://project.pages.drupalcode.org/htmx/blocks/loading/ ?

That's great! Thanks for testing. Yes - you use the standard core block, HTMX Loader, which is placed and configured normally. When configuring it you can choose what triggers along with some other htmx attributes. The default swap behavior is that HTMX block replaces the HTMX Loader, but you can configure that too.

The HTMX block feature definitely has utility: using load as the event one could conditionally lazy load a block as one one use case. However, it principally demonstrates how a developer could use HTMX to create dynamic elements.

Thanks also for fixing it!
Gotcha, I'll explore it then.👍