Attributes of a block content are applied to block itself

I am running into this problem with exposed forms in blocks, but it only surfaced when I updated to D 9.5. I was using views_block_filter_block because my views were block displays and I needed the exposed filters in separate blocks. It seems like the D9 update superseded views_block_filter_block, changing where the attributes were attached.

I patched with the MR, but it doesn't seem to be working, exposed form class attributes are still being moved to the containing block. If you have a custom block template for blocks containing views exposed forms that don't output all of the attributes, it breaks the ajax as well as the CSS in my case.

I worked around the issue by refactoring my template structure, I was fortunate to find a relatively simple solution, unfortunate that it cost me half a day to discover the problem and fix it.

dcam → changed the visibility of the branch 2486267-attributes-of-a to hidden.

dcam → changed the visibility of the branch 11.x to hidden.

Based on comment #10 I checked to see if this is still an issue in Drupal 11. It is. The same problem with the Search block form's data-drupal-selector attribute being applied to the block wrapper still exists.

There was no need to make a new test for this. The test created for the related original issue, #2171269: Handle block rendering's #attributes correctly (fixes in-place editing of custom blocks) → , can be adapted to check the change.

MR 1402 was broken. I don't know why some of the additional changes in it were made because they aren't well documented. The change from #atrributes to #wrapper_attributes was lost. I think that's the reason for the confusion in the more recent comments. I'm sure that it did stop doing anything to fix the issue. Since it's difficult or impossible to rebase MRs for old Core versions anyway, I hid the branch and created a new one for D11 restarting from the #5 patch. We'll see if this causes other tests to fail.

I didn't expect it to pass. I assumed that something else was probably relying on the attributes as they were. Oh well.

I made a change record: https://www.drupal.org/node/3525287 → .

I worked on this issue over the weekend not realizing that I'd experience it first-hand two days later. I've been adding inline styles to the .views-exposed-form class. Then I navigated to a different page where the exposed form is in a separate block. The class was bubbled up to the block wrapper, causing the block heading to be displayed in-line with the form as shown in the image below.

This seems like it could be an immediate breaking change if I had css written for before.

I ran into this logic recently on another issue and the current behaviour is very confusing as #48 demonstrates. We can't assume that everything rendered via block module is never rendered in any other context - especially with layout builder / experience builder and etc.

If we aren’t concerned with #49 can add to my review list for tomorrow

I keep running into this error as I apply my new theme to more sites. But now I've had a WSoD crash because of it. I'm altering Views exposed forms to format them as USWDS Search components. It involves applying a few classes, changing the text input type to search, and setting role="search" on the form. For some reason, that last one, setting the role attribute, really caused a problem when the exposed form is in a block and that block has its title display on. template_preprocess_block() (this site is still in D10) tries to set a unique ID for the block with Html::getUniqueId(). When the role attribute is bubbled up to the block due to this issue, suddenly the preprocess function starts passing the title render array to getUniqueId(). Then the error is thrown because the expected input is a string, not an array.

I didn't bother trying to figure out what weird code path causes that to happen. I'm fortunate that I can simply turn the title display off in this one instance. I just want to point out that there are scenarios where this isn't harmless. I'm lucky that I knew about this issue so I could work out what was going on.