Change 720773 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/VisualEditor@master] Make up/down/remove buttons behave sane on \u2026AddParameterPage

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

Change 721471 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/VisualEditor@master] Regression: Fix broken click on top-level template elements

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

Change 721471 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Regression: Fix broken click on top-level template elements

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

Change 721846 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/VisualEditor@master] Regression: Update selection in new sidebar relative to content

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

Change 721846 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Regression: Update selection in new sidebar relative to content

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

Change 720773 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Make up/down/remove buttons behave sane on \u2026AddParameterPage

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

Tracing shows that the outline controls are first set correctly, but then another chain of 6 events through onOutlineSelectWidgetSelect results in the entire part (template) being selected.

console.trace() update outline: !isMovable !isRemovable 
abilities { move: true, remove: true }
 
Object { elementId: null, visible: true, data: "part_3/ZWEIGLEISIG", "$element": {…}, elementGroup: {…}, bindings: {}, disabled: false, wasDisabled: false, "$label": {…}, label: "ZWEIGLEISIG", … }
OutlineControlsWidget.js:148:6
    onOutlineChange OutlineControlsWidget.js:148
    emit oojs.js:901
    selectItem SelectWidget.js:821
    selectItemByData SelectWidget.js:758
    focusPart ve.ui.MWTemplateDialog.js:649
    emit oojs.js:901
    emit oojs.js:901
    onTemplateParameterChoose ve.ui.MWTransclusionOutlineTemplateWidget.js:199
    emit oojs.js:901
    chooseItem SelectWidget.js:880
    onDocumentMouseUp SelectWidget.js:262


console.trace() update outline: isRemovable isMovable 
abilities { move: true, remove: true }
 
Object { elementId: null, visible: true, data: "part_3", "$element": {…}, elementGroup: {…}, bindings: {}, disabled: false, wasDisabled: false, "$label": {…}, label: "BS-daten", … }
OutlineControlsWidget.js:148:6
    onOutlineChange OutlineControlsWidget.js:148
    onUpdateOutlineControlButtons ve.ui.MWTemplateDialog.js:632
    emit oojs.js:901
    selectPartByPageName ve.ui.MWTransclusionOutlineContainerWidget.js:180
    onBookletLayoutSetPage ve.ui.MWTransclusionDialog.js:221
    emit oojs.js:901
    setPage BookletLayout.js:580
    onOutlineSelectWidgetSelect BookletLayout.js:266
    emit oojs.js:901
    selectItem SelectWidget.js:821
    selectItemByData SelectWidget.js:758
    focusPart ve.ui.MWTemplateDialog.js:649
    emit oojs.js:901
    emit oojs.js:901
    onTemplateParameterChoose ve.ui.MWTransclusionOutlineTemplateWidget.js:199
    emit oojs.js:901
    chooseItem SelectWidget.js:880
    onDocumentMouseUp SelectWidget.js:262

The problem stems from our use of "select" vs "highlight" semantics, we need to differentiate between the case where a template heading ("part") is selected, and when a parameter ("subitem") is selected, but rendered as highlighting and its containing template rendered as selected.

I might split some of the part-selection code to introduce a "highlight part" event, that styles the part without scrolling, focus, or affecting the outline buttons. Not sure if this is a wise name to give the new event because this is already a state we're abusing to highlight items—problematic itself because mouse hover interacts badly with highlighting.

Change 724020 had a related patch set uploaded (by Awight; author: Awight):

[mediawiki/extensions/VisualEditor@master] Distinguish between template select and \"highlight\"

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

Pulling this discussion out of the task description,

When a parameter is selected, the up/down and delete buttons are disabled.

Uh, no. Why?

@ECohen_WMDE Please check this assumption for us and link to or define what the toolbar buttons should look like when a parameter is selected. Thanks!

From Mattermost, for reference and to be considered by @ECohen_WMDE:

The misbehavior […] is "only" because the old sidebar is not yet disconnected. The old sidebar is flat. There is no way it can select a template and a parameter in the template the same time. The new sidebar was designed from the ground up to allow this. The problem is that the old sidebar still dictates how the new sidebar behaves.
Sure, we could "undo" our efforts, so to speak, and make the new sidebar as flat as the old one. That's pretty much what the suggestions implies. I'm not happy with this idea. Not only because it goes in the opposite direction of what we tried to do the past weeks. I also don't believe it will save us time in the long run. The moment we actually disconnect the old sidebar we will run into issues again, one way or the other.
I believe it should be possible to identify and disconnect the bad event that makes the buttons misbehave.

Pending design review. In the meeting today, we also noted that this feature interacts with:

• Clicking on a template header causes the first parameter to be focused.
• An unsaved changes warning would prevent accidentally deleting an entire template.

Clicking on a template header causes the first parameter to be focused.

• It's intentional.
• It's done to make it behave the same for all 3 types: wikitext parts focus the input field, template placeholders focus the search field. And templates focus the first input field as well.
• Without this the behavior is partly unspecified/bogus as it depends on the presence of "something" (the definition of "something" being hardcoded in OO.ui.findFocusable) that can be focused in the ve.ui.MWTemplatePage that represents a template. That's not always the case, most notably when all the header says is "This template doesn't exist". And even if there is a link, focusing it is of no use for the majority of (mouse) users.
• The patch that implemented this behavior was https://gerrit.wikimedia.org/r/719997.

An unsaved changes warning would prevent accidentally deleting an entire template.

I like that. 👍 I believe we have all the code that is necessary to do this.

We decided to remove the focus from the first parameter in this ticket T293250: Don't focus input field when clicking on template name in sidebar . Does this solve this issue?

@Lena_WMDE, yes. Well, kind of. What was done in T293250 didn't really "solve" the underlying issues, but improved the situation a lot. During today's demo time with @ECohen_WMDE we concluded that the current state is good enough. Some quirky behavior remains, but is probably very rare. We will create new tickets later, as necessary.

Just to elaborate on the quirky behavior: Given that a user is editing a multi-part template, there are some sequences of clicks which result in the toolbar delete button being enabled when the user has selected a parameter. Coming from the old workflow, this may appear to be a "parameter delete" action. But it's actually "template delete" now, which can cause the user to lose work. We've discussed possibly adding a confirmation popup before deleting templates. Currently the team is leaning towards cleaning this up after deployment, during BookletLayout cleanup.

Change 724020 abandoned by Awight:

[mediawiki/extensions/VisualEditor@master] Distinguish between template select and "highlight"

Reason:

stale

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