[Inspector Tabs] Highest priority tab selected on selection change

[jvigliotta]

Closes #7442

Describe your changes:

Whenever the selection changes, the first tab (highest priority) is auto selected.

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Is this a notable change that will require a special callout in the release notes? For example, will this break compatibility with existing APIs or projects that consume these plugins?

Author Checklist

• Changes address original issue?
• Tests included and/or updated with changes?
• Has this been smoke tested?
• Have you associated this PR with a type: label? Note: this is not necessarily the same as the original issue.
• Have you associated a milestone with this PR? Note: leave blank if unsure.
• Testing instructions included in associated issue OR is this a dependency/testcase change?

Reviewer Checklist

• Changes appear to address issue?
• Reviewer has tested changes by following the provided instructions?
• Changes appear not to be breaking changes?
• Appropriate automated tests included?
• Code style and in-line documentation are appropriate?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 55.39%. Comparing base (5be103e) to head (0912f5f).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7979      +/-   ##
==========================================
- Coverage   57.70%   55.39%   -2.31%     
==========================================
  Files         678      678              
  Lines       27428    27429       +1     
  Branches     2691     2691              
==========================================
- Hits        15826    15193     -633     
- Misses      11264    11896     +632     
- Partials      338      340       +2     

Flag	Coverage Δ
e2e-ci	55.76% <ø> (-7.06%)	⬇️
e2e-full	23.65% <ø> (-18.36%)	⬇️
unit	49.38% <100.00%> (-0.14%)	⬇️

Files with missing lines	Coverage Δ
src/ui/inspector/InspectorTabs.vue	100.00% <100.00%> (ø)

... and 91 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5be103e...0912f5f. Read the comment docs.

[charlesh88]

Not doing a formal PR review yet, but doccing the conversation I just had with @jvigliotta:

1. There's currently an unintended change where a priority really intended for editing is manifesting in browse mode in an undesired fashion. The best example of this is clicking an alphanumeric in a Display Layout: previously the "Properties" tab was displayed (which is desired) but now the "Format" tab is shown - which is very not desired during browse, but is more desirable while editing.

We should distinguish between browse and edit, and what tabs have priority for which views. @charlesh88 will compile a table of all views, how tabs should be prioritized for both browse and edit modes, and will implement (or help implement) the code across view providers to add this logic:

  priority() {
    if (this.openmct.editor.isEditing()) {
      return 1;
    }
    return this.openmct.priority.DEFAULT;
  }

2. As a real nice to have, the selected tab should be sticky across object selection; that is, if the user actively selects a particular tab, that tab should remain selected when clicking another object that also supports that tab type, despite priority. The use case here is being in the process of styling multiple objects in a Display Layout: if the user constantly has to keep selecting the Style tab every time they click the next thing to be styled, that's bad. If the Style tab isn't the priority tab for a view, and if the user then selects the Style tab, that tab should be tracked and should remain selected on clicking any further object views that also use a Style tab. This tracking should be maintained as long as the new view uses the same tab as the one being tracked; if it doesn't, the tracking var should be cleared out (in order to prevent confusion down the road as to why this other tab is now being selected). Here's some pseudo-code to further muddy the water; selectedTab stands in for the tracking var previously described:

object.onclick() {
  if (selectedTab && object.usesSelectedTab) {
     // The user has actively selected a tab, and the current view uses this tab too. Don't change the tab.
  } else {
    // No tab has been actively selected, so just show the priority tab for this view.
    // Also, clear out the value of selectedTab.
  }
}