The vertical scrollbar takes up a bit of space at the side, so the 'remove' buttons have to come in a bit. Should this extra space still be shown when there's no need for the scrollbar? e.g.:

This is when there are more than 400px of participants:	When there are fewer, we can show a gap: Or a non-scroll scrollbar:

PR: https://github.com/wikimedia/grantmetrics/pull/102

Maybe @Prtksxna could take a look and help us decide about the gap on the side of the Remove buttons.

@Samwilson, would it be possible to have the scroll on #panelBodyParticipants, and keep the .event-add-participants and .save-participants-btn fixed? This way the scroll target will become larger, and the clutter of the scrollbar will move all the way to the right edge.

Just a quick note, Mac OS and Android don't show scrollbars till you're actually scrolling. They don't need extra space either IIRC.

Yes, I played with putting the scroll on the panel body; it works well I think. I'm not sure how to fix the textarea and button though (and still have them scroll with the outer page).

This is with an 80vh max height on the panel body:

In T200541#4540986, @Samwilson wrote:

This is with an 80vh max height on the panel body:

The scrollbar moved to the right edge looks nice!

Yes, I played with putting the scroll on the panel body; it works well I think. I'm not sure how to fix the textarea and button though (and still have them scroll with the outer page).

We could put wrappers around the textarea and button, then another wrapper around the list of participants. Something like:

<div class="col-sm-6 event-add-participants form-group">
    ...
</div>
<div class="col-sm-6 save-participants-btn">
    ...
</div>
<div class="participant-rows-wrapper">
    <div class="col-sm-6 participant-rows">
        ...
    </div>
</div>

.participant-rows-wrapper {
    clear: both;
    max-height: 400px;
    overflow-y: scroll;
}

This will move the scrollbar to the far right, and the textarea and save button won't move with it. I think it looks okay...? It's a little confusing on MacOS because you can't tell where the scrollbar starts (it's actually below of the textarea). You might also have that problem where you're scrolling within in the participant list when you mean to scroll the whole page (cursor/touch focus would need to be outside the panel).

In T200541#4543691, @MusikAnimal wrote:

It's a little confusing on MacOS because you can't tell where the scrollbar starts (it's actually below of the textarea). You might also have that problem where you're scrolling within in the participant list when you mean to scroll the whole page (cursor/touch focus would need to be outside the panel).

Yeah MacOS is notorious at showing scroll bars. But this still increases the overall scroll target, and that is good.

I've updated the PR to make that whole lower area of the panel scrollable with a max hight of 400px.

PR merged, and the staging site updated. I'm sure there's still room for discussion! :) And anyway, maybe we're going to move the participants editing into the event editing page (in T204009)? So this panel would be redone.

This looks good to me. Let's push it to production.

The overflow: auto CSS rule hides the autocompletion dropdown :(

In this example I had a single username that I was trying to edit.

In T200541#4581948, @MusikAnimal wrote:

The overflow: auto CSS rule hides the autocompletion dropdown :(

In this example I had a single username that I was trying to edit.

I see this happen only for the bottom-most name. Can we make the auto-complete dropdown appear on top of the dialog (increase the z-index)? Might be good to have this logged as a separate bug ticket.