fix: disappearing list of participants in dialog box

[BmBaczkowski]

Closes #217

Perhaps relates to #129

[smathot]

How do I trigger the original issue (so that I can test if it's fixed)?

[BmBaczkowski]

This is how the issue looks on my system (mouse click removes entries rather than untick the boxes). After the fix, the dialog box corresponds to the state of the database whether participants are "Assigned" or "Not assigned" .

[smathot]

Just so that I understand correctly, the screencast is supposed to illustrate the problem (not the fix), right? If so, then I'm simply seeing consistent behavior. If you view only assigned participants, then unassigning a participant causes the participant to disappear altogether. Do I understand correctly that this is the issue you've been addressing? Because I don't think it is: You can debate the usability of this behavior, but it's not a bug as such.

I think @nclaidiere experienced something very different, but based only on the description in #217 it's hard to tell.

@BmBaczkowski can you please specify exactly how you interpret the issue and what you've done to resolve it? Then (once @BmBaczkowski has replied) @nclaidiere please comment on this to (dis)confirm that this is indeed the issue you've been experiencing.

[nclaidiere]

I think this is unrelated to #219
participants should be assigned to a study independently of the state of participant data (this is the case right now).

[smathot]

@nclaidiere Can you clarify what you mean exactly and how it relates to #217? (I wrote 219 but that was a typo.)

[BmBaczkowski]

The screencast shows the bug. When switching from "All" to "Assigned" after unticking participants, those participants disappear from the list. This seems expected, but it leads to inconsistent and confusing interaction behavior if a user continues the selection (tick / untick), and moves between "All", "Assigned", "Not assigned".

The core issue was incorrect state handling in the component. The UI used the current (editable) selection state to do 2 things at once: (a) control which participants are shown (filtering), and (b) reflect user interaction (checkbox state). Because of this, intermediate changes (like unticking) immediately affected the filtered list, even though those changes were not yet confirmed by the user. This made the UI feel unstable -- for example, unticking an item removed it from the list instantly, leading eventually to an empty list.

The fix prevents duplicate event handling (so each click results in exactly one state change). It seperates concerns between (a) the original selection (used for filtering), and (b) the current UI selection (used for interaction).

As a result, the list of participants no longer changes based on intermediate edits. The list of participants is derived from the original (persisted) selection state (see these lines), while user changes are applied only when explicitly confirmed. This makes the UI behavior more predictable.

@smathot Have you checked how the UI behaves after the fix? Maybe seeing the difference after fix makes the issue more obvious. This is how i interpreted the issue because of this unpredictable UI behavior.

[smathot]

@BmBaczkowski Thanks. This looks like a real improvement, so that's great. But I don't think it's related to the issue that @nclaidiere reported, which he clarified in #217 (copied below):

Ah OK, that makes sense. It isn't related to the status. Simply, when you tick a box, the entire list just disappears. I'll make a video to show you ASAP.

@nclaidiere Can you indeed post a video to illustrate the issue (which I either misunderstand or haven't been able to reproduce) ? And then @BmBaczkowski and I can see whether this is related to the current fix or something different (that also happens to affect the participant selection dialog).

[nclaidiere]

Hi, that sounds great! and maybe this is fixing also this problem. The video is slow because my connexion is not great, but basically, I scroll down the list, select GIBUS and then everything goes white. You scroll up/down again, the names reappear and then I select another monkey, goes back to white again.

manage.participant.list.problem.2026-04-22.111958.mp4

[smathot]

@nclaidiere This looks like a visual artefact at the level of the browser (and unrelated to @BmBaczkowski 's fix). I have never seen this before. Therefore, one thing that comes to mind is that it somehow results from the remote desktop connection (I don't know why it would, but it's possible). Does it also happen when you're viewing it locally, i.e. not through a remote desktop?

[nclaidiere]

It happens without remote desktop, here on my windows laptop using chrome (instead of ubuntu and firefox)

manage.participant.list.problem.v2.mp4

[smathot]

Thanks. I'll see if I can reproduce this on Windows with the docker image. @BmBaczkowski do you agree that this looks like a visual glitch that happens somewhere at the level of the browser or Vue?

[BmBaczkowski]

I was able to reproduce the issue (linux, firefox). The list of participants is not visible when starting the dialog after page reload. Afterwards, it looks fine. I am currently not sure whether this has anything to do with the codebase, perhaps simply browser-level. @nclaidiere does the issue resolves for you when you close the dialog and reopens it without page reload? See the screencast:

[BmBaczkowski]

I think I managed to fix the issue (see the gif together with the other improvement) -- now the list of participants is fully rendered when the dialog window opens.

[nclaidiere]

This looks perfect!