The web client loses its active tab when the JOIN event arrives before the join request returns #193

New Issue

2026-10-27T02:59:44+01:00

clawbot commented

2026-10-27 02:59:44 +01:00

In web/src/app.jsx, joinChannel sends the JOIN, adds the channel's tab if it is not there yet, and then makes tab number tabsRef.current.length the active one. That is the new tab's index only when the tab list has not changed in the meantime. Since the server queues the user's own JOIN event to every client of the session, the sending web client included, that event can arrive and add the tab before the JOIN request returns. tabsRef.current.length is then one past the last tab. The same happens when the user joins a channel whose tab is already open.

The active tab then points at no tab. The view falls back to the Server tab, and sendMessage returns at if (!tab) return; after clearing the input line, so everything the user types is silently dropped until they click a tab. Found while fixing #185; read from the code on 76ef8ff.

Fix: after a join from the web client, make the channel's own tab active, found by its name in the tab list, whichever arrives first, the JOIN event or the request's response. Change nothing else in the web client.

Definition of done

After /join #chan from the web client, the #chan tab is active and what the user types next is sent to #chan, whether the JOIN event or the request's response arrives first.
Joining a channel whose tab is already open makes that tab active.
The PR says how each item was checked, since the web client has no test setup.
One reviewed PR against next.

Model: opus-5-5

In `web/src/app.jsx`, `joinChannel` sends the `JOIN`, adds the channel's tab if it is not there yet, and then makes tab number `tabsRef.current.length` the active one. That is the new tab's index only when the tab list has not changed in the meantime. Since the server queues the user's own `JOIN` event to every client of the session, the sending web client included, that event can arrive and add the tab before the `JOIN` request returns. `tabsRef.current.length` is then one past the last tab. The same happens when the user joins a channel whose tab is already open. The active tab then points at no tab. The view falls back to the Server tab, and `sendMessage` returns at `if (!tab) return;` after clearing the input line, so everything the user types is silently dropped until they click a tab. Found while fixing https://git.eeqj.de/sneak/neoirc/issues/185; read from the code on `76ef8ff`. Fix: after a join from the web client, make the channel's own tab active, found by its name in the tab list, whichever arrives first, the `JOIN` event or the request's response. Change nothing else in the web client. ## Definition of done 1. After `/join #chan` from the web client, the `#chan` tab is active and what the user types next is sent to `#chan`, whether the `JOIN` event or the request's response arrives first. 2. Joining a channel whose tab is already open makes that tab active. 3. The PR says how each item was checked, since the web client has no test setup. 4. One reviewed PR against `next`. Model: opus-5-5

clawbot referenced this issue

2026-10-27 03:00:25 +01:00

1.0: what stands between next and a release candidate #140

clawbot referenced this issue from a commit

2026-10-27 03:18:55 +01:00

Show a joined channel's web tab whichever reply comes first (closes #193)

clawbot referenced a pull request that will close this issue

2026-10-27 03:23:24 +01:00

Show a joined channel's web tab whichever reply comes first (closes #193) #196

clawbot commented

2026-10-27 03:23:36 +01:00