Do these changes also have an inpact on the narrow mode/mobile view? Currently we are not focusing in that cases when clicking on parameter name and wikitext (like it is said here in the requirements). Should we change that as well, @Lena_WMDE ?

Thanks for the question @lilients_WMDE ! No, this only applies to desktop. Mobile/Narrow mode behaviour should remain as is. I'll update the ticket.

Change 730721 had a related patch set uploaded (by Svantje Lilienthal; author: Svantje Lilienthal):

[mediawiki/extensions/VisualEditor@master] Remove focus from first input field when clicking on template name in sidebar

https://gerrit.wikimedia.org/r/730721

Change 730721 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Remove focus from first input field when clicking on template name in sidebar

https://gerrit.wikimedia.org/r/730721

The focus goes to the link in the template description on the right. This is standard behaviour of OOUI.

But we do have a problem when there is no link, because the template is not existing (which was the reason for focusing the input field in the first place).

We would suggest the following options:

1. accept that in this edge case the focus is left behind
2. add a link to create the template that can be focused then
3. making the whole title focusable (maybe hidden because there is interaction available).

What way would you prefer, @ECohen_WMDE @Lena_WMDE ?

@lilients_WMDE does option 1 have knock on impacts? The lack of automatic focus seems fine to me if there are no major downsides (e.g. it doesn't scroll into view on the right, or you can't delete or move the template in a multipart transclusion) and would suggest we go with this option as a first step.

Regarding option 3, what do you mean by this:

...maybe hidden because there is interaction available).

@Lena_WMDE We can check that out and see if we find other impacts. What I see now is that the lack of automatic focus does lead to a missing focus on the add param button and the first input field if there is one (only after creating it, during creation the focus works most of the times).

We could also re-add the auto-focus of input fields for this edge case. Not sure if that would be more confusing though, because it would then behave different than the known template name click.

I am not completly sure how option 3 would work, because normally all stuff that is being focused does have an interactionable part e.g. a link or a button or an input field. If we set the focus to a template header that has nothing like this, we would make the focus hidden. Also not sure how this would look to the users then. Maybe @awight can elaborate?

In my opinion adding a link to create a new template with the added name (option 2) would be the easiest solution. Because we would only need to adapt the text and nothing in the code. This way the focusing would also be consistent for all templates - known or unknown.

Hi @lilients_WMDE thanks for the clarification and video. @Elisha and I reviewed and see no problem in this case. Therefore I would like to go with option 1, leaving the focus behind, as long as the template scrolls into view on the right.

Ok, in that case there is nothing to do in this ticket anymore. Option 1 is already implemented. :)

Note that the one patch https://gerrit.wikimedia.org/r/730721 linked to this ticket doesn't touch the code that causes the described issues, and therefor doesn't really solve them. The same issues still happen when following other click paths.

It would be possible to make a click on a template name in the sidebar:

1. … scroll the template name into view on the right side of the dialog.
2. … properly enable the up/down/delete buttons in the toolbar.
3. … and still put the text cursor in the input field for the first parameter.

The code that currently makes this impossible is in the old sidebar that is still active, but hidden. The moment we can remove this old code the issue will disappear, and we can re-enable the removed feature. As long as we can't do this the patch https://gerrit.wikimedia.org/r/730721 is indeed helpful.

I'm not sure how this factors in, but it would be nice if the next <tab> after clicking on the template header brought you to the search input field.

This might not be solved yet. I can uncheck several boxes and the interface is correct, there's no scrolling side-effect. However, if the deleted field is the *one that was focused*, then we scroll to the first input on the content pane. I would expect this to be a common occurrence, since users may have clicked on the parameter name before clicking to uncheck the box.

Update: I'm just catching up with everyone else. Now I see this bug was already split into T293635: Focus jumps to first element after deactivating any parameter, great!