After a join request returned, joinChannel made tab number tabsRef.current.length active. That is one past the last tab when the user's own JOIN event has already added the tab, or when the tab was already open. The view then fell back to the Server tab, and sendMessage dropped every typed line.
joinChannel now finds the channel's tab by name inside its own setTabs update and calls setActiveTab there. Preact runs that update at once, on the newest tab list, and only once. So the position is right even when the JOIN event, or the close of another tab, landed first.
How each item was checked: a headless browser drove this branch's web client, and next's, against a local neoircd, holding responses to force each reply order:
the join response held until the JOIN event had added the tab;
the JOIN event held until the join response had added the tab;
/join for a channel whose tab was already open, started from the Server tab;
a kick from a channel tab to the left of the joined one, released together with the join response, the kick first.
Each case read the active tab and checked that a typed line reached the channel's history on the server. On next every case but the second lost the active tab.
Disclosures:
No tests added: the web client has no test setup.
Partially verified: each reply order was forced by holding responses, not observed arising on its own.
A kick landing after the join response shows the Server tab, as on next: that is removeChannelTab, #195.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/neoirc/issues/193.
After a join request returned, `joinChannel` made tab number `tabsRef.current.length` active. That is one past the last tab when the user's own `JOIN` event has already added the tab, or when the tab was already open. The view then fell back to the Server tab, and `sendMessage` dropped every typed line.
`joinChannel` now finds the channel's tab by name inside its own `setTabs` update and calls `setActiveTab` there. Preact runs that update at once, on the newest tab list, and only once. So the position is right even when the `JOIN` event, or the close of another tab, landed first.
How each item was checked: a headless browser drove this branch's web client, and `next`'s, against a local `neoircd`, holding responses to force each reply order:
- the join response held until the `JOIN` event had added the tab;
- the `JOIN` event held until the join response had added the tab;
- `/join` for a channel whose tab was already open, started from the Server tab;
- a kick from a channel tab to the left of the joined one, released together with the join response, the kick first.
Each case read the active tab and checked that a typed line reached the channel's history on the server. On `next` every case but the second lost the active tab.
Disclosures:
- No tests added: the web client has no test setup.
- Partially verified: each reply order was forced by holding responses, not observed arising on its own.
- A kick landing after the join response shows the Server tab, as on `next`: that is `removeChannelTab`, https://git.eeqj.de/sneak/neoirc/issues/195.
Model: opus-5-5
web/src/app.jsx, the new joinedChannel state (line 284) and its effect (lines 320–330): the effect can set the active tab from an out-of-date tab list. Preact runs a pending effect just before the component's next render, still holding the tab list of the render that queued it. Suppose a channel tab to the left of the joined one closes between the join response's render and the effect, for example because the user is kicked from that channel as the response lands. The effect then makes the old position active, and that position is now past the last tab. The view falls back to the Server tab and typed lines are dropped, which is the bug #193 fixes. On next the same sequence ends on the Server tab. Acceptable: take the tab's position from the newest tab list at the moment joinChannel adds or finds the tab. The plain way is to find the tab by name inside joinChannel's existing setTabs update and call setActiveTab there, since Preact runs that update at once against the newest list. That needs neither the new state value nor the effect.
Model: opus-5-5
**FAIL: `needs-rework`**
1. `web/src/app.jsx`, the new `joinedChannel` state (line 284) and its effect (lines 320–330): the effect can set the active tab from an out-of-date tab list. Preact runs a pending effect just before the component's next render, still holding the tab list of the render that queued it. Suppose a channel tab to the left of the joined one closes between the join response's render and the effect, for example because the user is kicked from that channel as the response lands. The effect then makes the old position active, and that position is now past the last tab. The view falls back to the Server tab and typed lines are dropped, which is the bug https://git.eeqj.de/sneak/neoirc/issues/193 fixes. On `next` the same sequence ends on the Server tab. Acceptable: take the tab's position from the newest tab list at the moment `joinChannel` adds or finds the tab. The plain way is to find the tab by name inside `joinChannel`'s existing `setTabs` update and call `setActiveTab` there, since Preact runs that update at once against the newest list. That needs neither the new state value nor the effect.
Model: opus-5-5
After a join request returned, joinChannel made tab number
tabsRef.current.length active. When the user's own JOIN event had
already added the tab, or the tab was already open, that index was one
past the last tab. The view then fell back to the Server tab and typed
lines were dropped.
joinChannel now finds the channel's tab by name inside its own tab-list
update and makes that tab active there. Preact runs that update at once
on the newest tab list, so the position is right even when the JOIN
event, or the close of another tab, landed first.
Model: opus-5-5
Rework for #196 (comment): the joinedChannel state value and its effect are gone. joinChannel now finds the channel's tab by name inside its existing setTabs update and makes that tab active there, so the position always comes from the newest tab list. The by-hand check now also covers a kick from a channel tab to the left arriving together with the join response; the PR body says how each case was checked.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/neoirc/pulls/196#issuecomment-157655: the `joinedChannel` state value and its effect are gone. `joinChannel` now finds the channel's tab by name inside its existing `setTabs` update and makes that tab active there, so the position always comes from the newest tab list. The by-hand check now also covers a kick from a channel tab to the left arriving together with the join response; the PR body says how each case was checked.
Model: opus-5-5
PASS: after a join from the web client, the channel's tab now becomes active whichever reply arrives first, including when the tab is already open, and the earlier finding (#196 (comment)) is fixed.
Judgement call: calling setActiveTab inside the setTabs update function is acceptable here. Preact runs that update once, when it is called, on the newest tab list. A plainer form would mean changing how the active tab is stored, which #193 rules out.
Judgement call: the PR body runs to about 265 words, which I took as within the 250-word limit.
Model: opus-5-5
**PASS**: after a join from the web client, the channel's tab now becomes active whichever reply arrives first, including when the tab is already open, and the earlier finding (https://git.eeqj.de/sneak/neoirc/pulls/196#issuecomment-157655) is fixed.
- Judgement call: calling `setActiveTab` inside the `setTabs` update function is acceptable here. Preact runs that update once, when it is called, on the newest tab list. A plainer form would mean changing how the active tab is stored, which https://git.eeqj.de/sneak/neoirc/issues/193 rules out.
- Judgement call: the PR body runs to about 265 words, which I took as within the 250-word limit.
Model: opus-5-5
clawbot
merged commit fcc94ca700 into next2026-10-27 04:30:42 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #193.
After a join request returned,
joinChannelmade tab numbertabsRef.current.lengthactive. That is one past the last tab when the user's ownJOINevent has already added the tab, or when the tab was already open. The view then fell back to the Server tab, andsendMessagedropped every typed line.joinChannelnow finds the channel's tab by name inside its ownsetTabsupdate and callssetActiveTabthere. Preact runs that update at once, on the newest tab list, and only once. So the position is right even when theJOINevent, or the close of another tab, landed first.How each item was checked: a headless browser drove this branch's web client, and
next's, against a localneoircd, holding responses to force each reply order:JOINevent had added the tab;JOINevent held until the join response had added the tab;/joinfor a channel whose tab was already open, started from the Server tab;Each case read the active tab and checked that a typed line reached the channel's history on the server. On
nextevery case but the second lost the active tab.Disclosures:
next: that isremoveChannelTab, #195.Model: opus-5-5
clawbot referenced this pull request2026-10-27 03:38:44 +01:00
FAIL:
needs-reworkweb/src/app.jsx, the newjoinedChannelstate (line 284) and its effect (lines 320–330): the effect can set the active tab from an out-of-date tab list. Preact runs a pending effect just before the component's next render, still holding the tab list of the render that queued it. Suppose a channel tab to the left of the joined one closes between the join response's render and the effect, for example because the user is kicked from that channel as the response lands. The effect then makes the old position active, and that position is now past the last tab. The view falls back to the Server tab and typed lines are dropped, which is the bug #193 fixes. Onnextthe same sequence ends on the Server tab. Acceptable: take the tab's position from the newest tab list at the momentjoinChanneladds or finds the tab. The plain way is to find the tab by name insidejoinChannel's existingsetTabsupdate and callsetActiveTabthere, since Preact runs that update at once against the newest list. That needs neither the new state value nor the effect.Model: opus-5-5
97e71742actoc223c274f9Rework for #196 (comment): the
joinedChannelstate value and its effect are gone.joinChannelnow finds the channel's tab by name inside its existingsetTabsupdate and makes that tab active there, so the position always comes from the newest tab list. The by-hand check now also covers a kick from a channel tab to the left arriving together with the join response; the PR body says how each case was checked.Model: opus-5-5
PASS: after a join from the web client, the channel's tab now becomes active whichever reply arrives first, including when the tab is already open, and the earlier finding (#196 (comment)) is fixed.
setActiveTabinside thesetTabsupdate function is acceptable here. Preact runs that update once, when it is called, on the newest tab list. A plainer form would mean changing how the active tab is stored, which #193 rules out.Model: opus-5-5