Layout Builder jumps to top when removing section/block

Oh wow, that is very annoying indeed.

It looks like this code was added in #2994909: Highlight active element while working with dialogs in Layout Builder.
It makes sense for the cases where something is being added or configured. But in the case of removal, I agree it should stay put.

Please try this patch (don't worry about the 9.1 vs 8.9, it should be the same for both)

Not working for me either. Testing on 8.9.15.

I also tried removing all the "scroll"-code I could find in the layout builder javascript files, but that made no difference to this behavior.

The only way I was able to stop it from happening was by removing the AjaxResponse in the LayoutRebuildTrait, but then nothing happens obviously, but just creating a new AjaxResponse in rebuildLayout function with none of the other code cause it to happen. Like it still happens if my LayoutRebuildTrait looks like this:

trait LayoutRebuildTrait {

  /**
   * Rebuilds the layout.
   *
   * @param \Drupal\layout_builder\SectionStorageInterface $section_storage
   *   The section storage.
   *
   * @return \Drupal\Core\Ajax\AjaxResponse
   *   An AJAX response to either rebuild the layout and close the dialog, or
   *   reload the page.
   */
  protected function rebuildAndClose(SectionStorageInterface $section_storage) {
    $response = $this->rebuildLayout($section_storage);
//    $response->addCommand(new CloseDialogCommand('#drupal-off-canvas'));
    return $response;
  }

  /**
   * Rebuilds the layout.
   *
   * @param \Drupal\layout_builder\SectionStorageInterface $section_storage
   *   The section storage.
   *
   * @return \Drupal\Core\Ajax\AjaxResponse
   *   An AJAX response to either rebuild the layout and close the dialog, or
   *   reload the page.
   */
  protected function rebuildLayout(SectionStorageInterface $section_storage) {
    $response = new AjaxResponse(); // <-- If the entire AjaxResponse is removed then we no longer scroll to the top of the page when removing a block or layout section.
//    $layout = [
//      '#type' => 'layout_builder',
//      '#section_storage' => $section_storage,
//    ];
//    $response->addCommand(new ReplaceCommand('#layout-builder', $layout));
    return $response;
  }

}

Maybe you can alter the AjaxResponse and something else is altering in some behavior which causes the browser to scroll to the top of the page if the response is there? I dunno, I'm not very knowledgable about how anything fits together in Drupal, especially not if involves javascript. :p

I'm changing the priority to "Major" as I feel this is currently a huge UX issue, albeit one which hopefully has a very simple fix. I'm just not able to find it.

Just tested this patch on 9.1.10 and also doesn't work :(
I agree that this is quite a major UX issue especially as pages can get quite long.

I just tested this against 9.3.x and the patch still applies, but the behavior that it causes does not seem correct. What I would expect to see is that the page does not scroll/jump to the top before scrolling/jumping to the location of the block or section being removed. Instead what the patch does is preserves the initial jump to the top, but then the jump back to the element being removed never happens.

After investigation, the issue doesn't always reproduce. I added steps to reproduce to the issue summary. And updated the proposed resolution block.

I tested the solution on 9, 10 and 11-dev.
I opened a MR with the proposed solution. Likewise, I also attach a patch for history and usage in a project.

I'm not sure if we can add tests for this change.

Verified the issue following the steps in the IS
Patch #16 did solve the issue.

Lowering to normal though as annoying as this is doesn't seem to break anything.

Thanks!

I agree this would be difficult to test, and it can be easily manually tested. On the basis of our new proposed heuristics I think this can go in without tests.

I checked in gitlab for any other classes in contrib that extend this class that may not want this behaviour but could not find any.

Committed to 11.x and backported to 10.1.x