Contextual-Click on Folder Tab (Parent) with overly large list of subfolders collapses popup window immediately

[ScriptHippie]

This is a UI issue for folder tabs that are parent folders with a list of subfolders that is so long that the resulting popup-window extends above the click location.

Steps to reproduce:
Contextual-click (=right-click, Cmd-click) the parent folder. A long list of subfolders is displayed in a popup window for a split second. The list immediately closes and the subfolder which was under the mouse pointer shortly is selected (as if it was clicked).
(Exception: The screen top limit is low enough to push the popup window down so that mouse pointer is in the top three/command lines of the popup)

Expected behavior:
Popup window should remain open, and allow user interaction such as choosing a QuickFolder command or a subfolder.

Workaround:
Click and hold (right) mouse button to keep popup window open until a command/folder choice was made
OR
Click and hold (right) mouse button and move pointer out of the window area, then let go of click button. This keeps the window open like in normal UI behavior.

Drag-over works fine for such a parent folder.

macos 15.7.3 / TB 147.0.2 / QF 6.15pre108

[RealRaven2000]

I have seen this one reported time and time again. I am using a OS built in menu widget, and there is not too much I can do: have less subfolders?

[ScriptHippie]

Sorry for re-reporting. I did not find any open or closed issue about that, but might have looked with the wrong search terms.

OS-provided, makes sense, so nothing to pursue then. Let's just close it, it is just a small annoyance.

have less subfolders?

Yes, that is definitely the plan🙃 . It's just a staging folder at this point and shall be divided into several parent folders soon.

[RealRaven2000]

btw, I know it's kind of an antipattern - but if you drag mail on your overly long subfolder menu, can you still scroll down by dragging?

Ideally I would like the menu not to cover the originating tab (initial drop target) but I haven't found a way to prevent it, it just "goes up" automatically, and it's not really style-friendly, ideally it should break at the bottom of the screen instead and then become multi-column... maybe we can find some UX experiments along these lines?

[ScriptHippie]

btw, I know it's kind of an antipattern - but if you drag mail on your overly long subfolder menu, can you still scroll down by dragging?

Yes, that works as expected: At the bottom of the list, a little down arrow is displayed and dragging to the bottom makes the list scroll. (At which point, an up arrow is displayed at the top of the list). Typical macOS fashion.

Ideally I would like the menu not to cover the originating tab (initial drop target) but I haven't found a way to prevent it, it just "goes up" automatically,

Right – once the list becomes too long, the top starts to move up until screen upper limit. In "in between" situations, one of the top command menus can end up being located over the originating tab, and they do not open up their submenus immediately, but only if you move the pointer a bit, which is fine.

and it's not really style-friendly, ideally it should break at the bottom of the screen instead and then become multi-column... maybe we can find some UX experiments along these lines?

When I think about it, macOS style would not offer multi-column popup menus? Extra columns typically only happen for subfolders/submenus.
Not a bad idea, but I am not sure how each OS' GUI standards are. I notice that the long list reacts to keyboard letters to jump to a position, and even smartly so (if only one folder exists with the beginning letter, that subfolder opens immediately; if there are multiples, the list positions on the first matching subfolder, so you can choose the correct one. Cool!). That by itself is already more than sufficient, I'd say.