Closing the active tab does not fire events for tab change

[RSantosGIS]

Actual Behavior

Originally documented in #7155 but broken into a smaller bug report at the request of @mpriour .

When you close the active tab, the active tab automatically changes (as intended) but this does not fire the onCalciteTabsActivate or onCalciteTabChange events for CalciteTabTitle and CalciteTabNav, respectively

Expected Behavior

When you close the active tab and it moves you to a new tab, all of the events for tab navigation should fire.

Reproduction Sample

https://codesandbox.io/s/new-feather-qsyw8j?file=/src/App.js

Reproduction Steps

1. Open the dev console
2. Close the active tab - notice the console.log statements don't fire
3. click to navigate to another tab - notice that the console.log statements do fire

Reproduction Version

1.4.2

Relevant Info

No response

Regression?

No response

Priority impact

p3 - want for upcoming milestone

Impact

This prevents ArcGIS studio from being able to utilize callbacks on tab navigation events reliably. We have to do workarounds where tab closure triggers special handling to also consider navigation, rather than just have navigation events be handled by the actual navigation event handler on the component.

Esri team

ArcGIS Knowledge

[geospatialem]

Research to be conducted in August to determine the time estimate needed for a fix in a future milestone.

[Elijbet]

Research to be conducted in August to determine the time estimate needed for a fix in a future milestone.

Research Summary

The question revolves around whether the automatic movement of selection to the next tab after closing one should be considered a user-triggered activation or a programmatic action.

Currently, no TabsActivate or TabChange events, either public or internal, are being fired as part of the closable logic. The suggestion is to emit public events TabsActivate(userTriggered = true / TabChange(userTriggered = true) related to close events based on how the tab was closed (user-triggered vs. programmatic).

Here are some precedent examples where related events are emitted in response to user-initiated actions in other components:

• pick/value-list emits the remove item event and, after being removed, also emits the list change event.
• combobox emits filter and combobox change events when the value is cleared (there may be other similar examples).
• list emits a change event along with its item's select event.

It seems to make sense that emitting associated events should only occur when the user initiates an action that would trigger those events because internal events may not always be necessary; they have been used in specific cases as implementation details.

There was some confusion about the difference between tabActivate and tabChange due to overlap with variable naming across tabs/tab/tab-nav/tab-title. In some cases, calcite-tab refers to both "tab-title with corresponding tab" combo and "tab," depending on the component it's used in. This brought us back to previous discussions on tabs being overly complicated and overdue for restructuring.

Note that non-selected closable tab-title will not fire TabChange or TabActive events since it only affects closure without changing the tab state.

I'll be adding addendum documentation regarding emitting associated events for user-initiated actions in the conventions section under event handling guidelines.

@geospatialem @jcfranco @driskull @macandcheese

[github-actions]

Installed and assigned for verification.

[DitwanP]

🍠 Verified on 2.2.0-next.17