x goes away when the tab count is 1 and never comes back

[gayukumar]

Check existing issues

• I have checked for existing issues to avoid duplicates

Actual Behavior

• Open multiple tabs which are closable
• close all of them
• see the last one doesnt have close anymore
• and it does not come back when add the tab programmitically again
• also, if only one tab closable is appended this will have close button

Expected Behavior

The 'x' should always remain beside the tab name, regardless of if other tabs are deleted
OR

• the 'x' should return as soon as there are >1 tabs

Reproduction Sample

https://devtopia.esri.com/WebGIS/arcgis-web-analysis/issues/6994

Reproduction Steps

• Open multiple tabs which are closable
• close all of them
• see the last one doesnt have close anymore
• and it does not come back when add the tab programmitically again
• also, if only one tab closable is appended this will have close button

Reproduction Version

https://devtopia.esri.com/WebGIS/arcgis-web-analysis/issues/6994

Relevant Info

happens on any browser or any OS

Regression?

No response

Priority impact

impact - p2 - want for an upcoming milestone

Impact

No response

Calcite package

• @esri/calcite-components
• @esri/calcite-components-angular
• @esri/calcite-components-react
• @esri/calcite-design-tokens
• @esri/eslint-plugin-calcite-components

Esri team

ArcGIS Web Analysis

[nel11211]

@geospatialem
Is there any way to bump this issue for R3? See discussion here.

[geospatialem]

Is there any way to bump this issue for R3? See discussion here.

@nel11211 Responded in the internal thread for follow-up to re-assess the priority, if needed. 🤜🏻🤛🏻

[josercarcamo]

@geospatialem could the "Expected Behavior" section please be reduced to only one expectation, not an "or'?

[geospatialem]

@geospatialem could the "Expected Behavior" section please be reduced to only one expectation, not an "or'?

@josercarcamo I'm not sure what the ask is WRT the expected behavior, but either expectation should work for the solution. cc @jcfranco

[jcfranco]

Either seem fine to me, but will defer to @ashetland and @SkyeSeitz on this since this might need some design UXpertise™.

@josercarcamo If you have any thoughts on the implementation details we should consider for each approach, please share.

[gayukumar]

Either of the solution is fine. but rite now the behavior is inconsistent

[ashetland]

I think we should categorize this as a bug instead of an enhancement and move forward with:

the 'x' should return as soon as there are >1 tabs

[josercarcamo]

All, so each tab can be configured to be "closable". It is not by default. So, the "x" should be displayed on the first tab when there are more than one tabs and the first tab was originally closable, correct?

[jcfranco]

Based on the recent updates, I think this is what we need:

• for all closable tabs
  • if there's exactly one closable tab remaining, hide its closable affordance and prevent closing
  • if there's more than one closable tab, display its closable affordance

I don't recall if mixing closable and non-closable tabs is a supported use case. @ashetland @Elijbet Do you remember?

[ashetland]

recall if mixing closable and non-closable tabs is a supported use case

I don't recall, unfortunately.

• for all closable tabs
  • if there's exactly one closable tab remaining, hide its closable affordance and prevent closing
  • if there's more than one closable tab, display its closable affordance

Agreed.

[josercarcamo]

At the moment, the "closable" property is on the tab-title, so with this HTML:

It is possible to mix closable and non-closable tabs as seen here:

We probably should move the "closable" property to the tab-nav if we don't want to allow any mixing.

[jcfranco]

Yeah, the doc site's Tabs sample also subtly showcases the mixed case (i.e., closable is configurable on a single tab only).

We probably should move the "closable" property to the tab-nav if we don't want to allow any mixing.

We can revisit this once we have more feedback on closable use cases.