SystemBrowser posts a redundant loadMethodCategories render with no selection before selecting the method's category

[claude]

Summary

When SystemBrowser navigates to a method, applyClassSelection (client/src/systemBrowser.ts:771)
posts loadMethodCategories twice: once with no selection, then again with the method's
actual category selected. Only the second post is needed — the first is a redundant
render that the webview has to process and repaint for.

Environment

• Jasper: 1.7.4
• GemStone server: N/A (pure client-side rendering issue)

Steps to reproduce

1. Open the System Browser and navigate to any method (e.g. via SystemBrowser.navigateTo).
2. Observe the sequence of loadMethodCategories messages posted to the webview.

Expected behavior

A single loadMethodCategories post with the method's category already selected.

Actual behavior

Two posts: { selected: null } followed by { selected: 'Accessing' } (or whatever the
method's actual category is) — confirmed by the test assertion
expect(categorySelections).toEqual([null, 'Accessing']).

Potential fix

applyClassSelection calls this.loadMethodCategories() with no argument before the
caller later re-invokes it with the resolved category (see client/src/systemBrowser.ts:777
and the later call sites around lines 891/929/1095). One approach could be to have
applyClassSelection accept/thread the target category through so it only posts once,
rather than posting an empty selection first.

---

Migrated from GitLab: GemStone/grail#54

[ericwinger]

Closing — the System Browser is frozen and not being worked on, so this will not be fixed.

The behaviour is still exactly as described: applyClassSelection (client/src/systemBrowser.ts) posts loadMethodCategories with no selection, and a later call re-posts it with the resolved category. client/src/__tests__/systemBrowser.test.ts still asserts expect(categorySelections).toEqual([null, 'Accessing']), so the double post is pinned by a test rather than being an accident that might drift.

Leaving it that way deliberately. It is a redundant repaint inside a frozen webview, not a correctness problem — the final render has the right category selected. Threading the target category through applyClassSelection would touch the several call sites that currently rely on the no-argument form, which is not work worth doing on a surface that is being retired. #421 already hid the System Browser button on session rows so the GemStone Explorer is the discovered default.

#289 remains the place to track anything still live under the Browser convergence theme. Reopen if the shared backend work ends up inheriting this posting pattern, since that would make it worth fixing once, in the converged browser, rather than here.