Threads loaded with AJAX lose their CSS and JS libraries

Problem/Motivation

When you click a thread in the inbox, AjaxController::loadThread() renders the thread and sends back only its drupalSettings, through a SettingsCommand. The thread's #attached libraries never reach the page. Anything in the thread that depends on a library the page does not already have renders unstyled and without its behaviors.

This came in with #3054106: Javascript files loaded twice when clicking on thread link in PM block. Back then the thread JS loaded threads with a plain $.ajax() call, which sends no ajax_page_state, so the attachments processor treated every library as new and sent all of them again. The fix there dropped the attachments and kept the settings. Since then the thread JS moved to Drupal.ajax() (private_message_thread.js, loadThread()), and core adds ajax_page_state to every Drupal.ajax() request (core/misc/ajax.js, beforeSerialize()). The original cause is gone and the side effect is still there.

We hit it with a reaction field (votingapi_reactions) on private messages. Open the messages page with no thread selected, click a thread in the inbox, and the reaction icons collapse to nothing because the formatter's CSS is missing.

The other callbacks in AjaxController render to a string the same way (getNewPrivateMessages(), getOldPrivateMessages(), getOldInboxThreads() and getNewInboxThreads()), so a new message or older messages that need a library the page lacks have the same problem.

Steps to reproduce

1. Add a field to the private_message entity whose formatter attaches a library, and show it on the default display.
2. Create a thread with a message that has a value in that field.
3. Log in as a member of that thread and open the messages page with no thread selected.
4. Click the thread in the inbox block.
5. The field renders without its CSS. The load_thread response holds only settings, privateMessageInsertThread and privateMessageUpdateUnreadItemsCount commands.

Proposed resolution

Hand the thread's attachments back to the response, and let core's AjaxResponseAttachmentsProcessor work out what the page still needs. It reads the libraries listed in ajax_page_state and only adds CSS and JS the page does not have, so nothing loads twice.

$rendered_thread = (string) $this->renderer->renderRoot($renderable);

$response->setAttachments($renderable['#attached']);
$response->addCommand(new PrivateMessageInsertThreadCommand($rendered_thread));

The SettingsCommand can go, since the processor sends the settings too. The same change applies to the other callbacks that insert rendered markup.

This is the pattern core uses for every AJAX render, AjaxRenderer::renderResponse() calls $response->setAttachments($main_content['#attached']). The module already does it in PrivateMessageForm, where the AJAX submit calls $response->setAttachments($new_form['#attached']) before replacing the form.

The MR adds two tests to InboxBlockTest, both clicking a thread with the existing clickThread() helper. The first uses a test module whose field formatter attaches a library, and checks its CSS is on the page after the thread loads, which proves the bug by failing without the fix. The second checks private_message_thread.js and the test library's files are each on the page exactly once after loading a thread, and again after switching to a second thread and back. That is the regression #3054106: Javascript files loaded twice when clicking on thread link in PM block fixed, so it keeps the double loading from coming back.

Remaining tasks

• MR with the change and the two tests.