\Drupal\Core\Pager\PagerManager::getUpdatedParameters() merges the entire current request query string into every pager link, via \Drupal\Core\Pager\PagerParameters::getQueryParameters(), which excludes only page.
core/misc/htmx/htmx-assets.js adds _wrapper_format, ajax_page_state[...], and _triggering_element_name to every HTMX request (see its htmx:configRequest handler). The same file's htmx:beforeHistoryUpdate handler removes these keys before updating browser history, but PagerManager has no equivalent step.
A #type => pager element rendered while processing an HTMX request therefore emits links containing _wrapper_format=drupal_htmx. \Drupal\Core\EventSubscriber\MainContentViewSubscriber::onViewRenderArray() selects the response wrapper from this query parameter alone, without checking for the HX-Request header. A plain click on such a link is an ordinary navigation. It still receives a bare content fragment: no , no asset libraries, no HTMX script. Every later interaction depending on JavaScript, including HTMX, then stops working.
This was discovered in #3490391: Make listing revisions an option on the list usage page
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !17160
Comments
Comment #2
alexpottComment #4
alexpottI think we're also going to have problems with \Drupal\Core\Utility\TableSort::getQueryParameters() too... I wonder if we shouldn't have a more generic fix - not sure what that would be though.
Comment #5
alexpott@catch pointed out this is very similar to (and probably a duplicate of) #2504709: Prevent _wrapper_format and ajax_form parameters from bleeding through to generated URLs - I'm going to close this one.