Maintain focus on last added paragraph

I don't find a visual problem here - no scrolling is required - but the keyboard/cursor focus does not seem to move to the new paragraph.

Core's multi-value entity reference fields also behave like this, so perhaps it should be postponed or closed as won't fix. I can't see a core issue on the subject.

I see that if i click on the label of a WYSIWYG field, the focus does not work. The WYSIWYG is not receiving any focus. We need to check the core issue queue if this is reported already.

The focus via label also doesn't work for multivalue fields via its table heading.
And yeah, when i add another item to a multivalue field, the newly added item does not get any focus.

Agree that adding an element should move the focus to the element. But again, also agree that this should be established consistently, starting in core.

Let's search or create all related core issues and figure out how to best improve and implement this.

@miro_dietiker I've gone through the issues queue as best I can. I wanted to add to this as I'm having same issue - although wanted to clarify on previous submitter.

I can't find tasks that align with the comments below as they UX - tell me where to move them - and I'm happy to help test a few things if it's ux. I hope this is helpful and not annoying...

I'm not sure the original poster meant focus visible.

The issue I'm having is when adding another paragraph field set to a node the user is kept at the bottom of the page after it's been added. So there is little visual clue that the paragraph set was added. A better UX would be to auto scroll to the top of the newly added paragraph set. Even a success message on creation along side the Add Item message would give users a visual clue.

One of my examples is a complicated paragraph/field set where there can be dozens of items added. I note the progress towards collapsing paragraph sets (or fields sets within a paragraph?) which would be a big help.

Other changes:

Background styling/table for each paragraph set

A styled heading for each [paragraph item]

I can confirm, that issue still isn't fixed. Focus doesn't follow recently added paragraph.

We are short before adding scroll persistency at the related issue.

This would be a second step of modifying the scroll / focus behavior to improve UX significantly.
Promoting as add + focus is a common operation.

This issue is also evident when simply adding a new item - the focus stays on the button instead of moving to the new paragraph fields.

WIP patch for scrolling to newly added paragraph.

WIP patch for scrolling to newly added paragraph.

On my side, as a workaround, I've implemented it directly in an overridden field widget plugin, as an additional AJAX command :

<?php

namespace Drupal\my_custom_module\Plugin\Field\FieldWidget;

use Drupal\Core\Ajax\AjaxResponse;
use Drupal\Core\Ajax\InsertCommand;
use Drupal\Core\Form\FormStateInterface;
use Drupal\paragraphs\Plugin\Field\FieldWidget\InlineParagraphsWidget as OriginalInlineParagraphsWidget;
use Drupal\views\Ajax\ScrollTopCommand;

/**
 * Custom plugin implementation of the 'entity_reference paragraphs' widget.
 * Overrides the AJAX behavior to add a scroll to the top of any added paragraph.
 */
class InlineParagraphsWidget extends OriginalInlineParagraphsWidget {

  /**
   * {@inheritdoc}
   */
  public static function addMoreAjax(array $form, FormStateInterface $form_state) {
    $element = parent::addMoreAjax($form, $form_state);
    $response = new AjaxResponse();
    $response->addCommand(new InsertCommand(NULL, $element));
    $response->addCommand(new ScrollTopCommand('#'.$element[$element['#max_delta']]['#id']));
    return $response;
  }

}

I could prepare a nice patch to implement this directly in the module codebase, if you think it's the right way to go.
Maybe an option on the widget could be added to enable/disable the automatic scrolling ?

Thanks for the idea @Renrhaf.

I tried to implement and test that, but doesn't seem to work properly. First of all, that ScrollTopCommand() is in ajax_view.js, so that means we need to depend on the views module. We can solve that by implementing Drupal.AjaxCommands.prototype.viewsScrollTop() in the module though. I hacked that quickly by setting a dependency. Secondly, that would only scroll to position, but not focus the element.
I then tested the "add paragraph" and "add above" functionality, but the scrolling didn't seem to scroll to the right position. A couple of times console.log($(scrollTarget).scrollTop()); returned undefined, which means that the js code ran even before the element was loaded in the content?

Attaching an initial testing patch with the suggestion in #11.

Tried patch #11 no luck, but patch #17 does.

@sasanikolic

Same approach here but using InvokeCommand & fucus.

Sending the correct file

This is in addition to #17. We introduce back in ScollTo and make sure that focus goes to the very first input element. It seems that his would be the "Remove" button.

After slightly fixing the patch above, I noticed it was not focusing the right element. The first visible input is the "Collapse" button in my case, so that one got the focus.

This patch improves the selector with the first form-item and focusable element inside. I tried to look for the first focusable element, but can't select the first element of the returned jquery array with the current commands. We would need to define a new command for that, I believe?
The second issue is that ckeditor textarea is not a focusable element?

I also tried setting the tabindex="-1" so that the new paragraph's div becomes focusable, but that doesn't look nice.

I think what would be best is to be able to focus the draggable parent, but we can't do that with the current implementation and would need to define a new command that looks for the draggable parent. @miro_dietiker what do you think?

I implemented a new Ajax command that focuses the draggable table row parent of the newly added paragraph.

I moved the scrollTo command to the paragraphs module and fixed the testEditPerspectives() failing test.

I looked at the tests and it seems that there are some problems here.

First, there is a window resize just before the test fails but testing locally, it seems that the window is just resized in width and not in height so this makes the tests a bit bogus, as we are checking that the perspective tabs are displayed in the viewport, which since the screen is big in height, they are never hidden.

I checked the code but it doesn't seem to be a problem with the tests about the window resizing, most likely that is a chromedriver bug (?). I will keep investigating and probably try with a workaround for the time being.

The thunder people started to look into this problem over at

https://www.drupal.org/project/paragraphs_features/issues/3185154

Here is a patch based on Paragraphs Features module updates

1. +++ b/src/Ajax/ScrollToElementCommand.php	(date 1627288071041)
   @@ -0,0 +1,52 @@
   +
   +/**
   + * Provides an AJAX command for scrolling an element into the view.
   + *
   + * This command is implemented in Drupal.AjaxCommands.prototype.scrollToElement.
   + */
   +class ScrollToElementCommand implements CommandInterface {
   

   This should be namespaced to the paragraphs module, we don't want it to conflict with another scroll to command that another module might be adding.

2. +++ b/src/Ajax/ScrollToElementCommand.php	(date 1627288071041)
   @@ -0,0 +1,52 @@
   +      'command' => 'scrollToElement',
   +      'drupalElementSelector' => $this->elementSelector,
   +      'drupalParentSelector' => $this->parentSelector,
   

   within the actually response, I don't think we need to prefix it anything with drupal, do other commands do that too? that doesn't seem necessary to me.

3. +++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php	(date 1627288141883)
   @@ -1734,7 +1742,10 @@
    
   -    return $element;
   +    $response->addCommand(new InsertCommand(NULL, $element));
   +    $response->addCommand(new ScrollToElementCommand($element[$element['#max_delta']]['#attributes']['data-drupal-selector'], $element['#attributes']['data-drupal-selector']));
   +
   

   IIRC, by switching to a response, we need to possibly take care of some things ourself, for example messages. Returning a render array with prefix it with messages automatically. Are we certain that adding a paragraph never displays a message. I'm unsure.

Thanks for the quick feedback :)
I've fixed the first and second points. Could you please give me an example for the third one?

See \Drupal\Core\Render\MainContent\AjaxRenderer::renderResponse. by returning a response object we afaik bypass that and might need to replicate parts of what that is doing. There are also similar things in the form component, I'm not exactly sure which parts we really need.

Patch #32 with 200px offset.

Rerolling Patch #32 for Paragraph 8.x-1.15.

Patch #36 (based on #32) resolves the problem of where the form is positioned, but the focus is still moved to the wrong field, the focus is moved to the first field in the parent entity form, rather than the first item of the child paragraph being added.

In my scenario I'm using Layout Builder to control the fields on an inline block. The block has two text fields followed by a paragraphs field. When either click "Edit" to show the fields for the paragraph, or click the "add" button to add another paragraph item, the same thing happens - the focus moves to the first field of the block, not the first field of the paragraph.

Is it possible there are core issues complicating this, something with the AJAX logic?

Possibly related: #3033151: Add ['#ajax']['refocus'] property to FormAPI elements

fwiw this appears to describe the issue I'm facing, but the provided patch doesn't fix it: #3100133: Ajax replace inside a modal causes the current field to lose focus.

Hello,

Here a quick fix to get focus on the last element added.