Describe the bug
When a DropDownList is dropped (expanded), the open list popup does not use a background attribute distinct from its SuperView's. Because the dropped list inherits/blends with the parent's scheme, the popup is hard to distinguish from the content behind/around it — it should "float" with its own background (e.g. the Menu/popover scheme, or at least a visibly different attribute) so the user can tell the list is open and where its bounds are.
This is especially visible when the parent View/Window uses a scheme whose Normal background matches the list's (e.g. an app that sets its top-level window to the Accent/Base scheme): the expanded DropDownList is nearly invisible against the SuperView.
I'm fairly sure I fixed this at some point — filing because it appears to be back (possible regression). Flagging so we can add a regression guard once fixed.
To Reproduce
Steps to reproduce the behavior:
- Place a
DropDownList inside a Window/View and give that container a scheme (or rely on the default) whose Normal background matches the list's.
- Expand the
DropDownList.
- Expected behavior: the dropped list renders with its own, distinct background attribute (clearly separated from the SuperView — like a popover/menu), so the open list is visually obvious.
- Actual behavior: the dropped list shares the SuperView's background attribute, so the open list blends into the surrounding content and its bounds are hard to see.
Environment
- Terminal.Gui: 2.4.7
- OS: macOS (Darwin 25.5.0)
- .NET: 10
- Terminal/host: seen under the
agg/sixel render path while driving a TUI, but it's a scheme/attribute issue independent of the host.
Notes / suggested fix
The dropped portion of DropDownList should resolve its own scheme (e.g. a Menu/popover scheme) rather than inheriting SuperView.GetScheme(), so its Normal attribute differs from the SuperView by construction. A golden/attribute test that asserts the expanded list's background attribute != the SuperView's would prevent regressions.
Describe the bug
When a
DropDownListis dropped (expanded), the open list popup does not use a background attribute distinct from itsSuperView's. Because the dropped list inherits/blends with the parent's scheme, the popup is hard to distinguish from the content behind/around it — it should "float" with its own background (e.g. theMenu/popover scheme, or at least a visibly different attribute) so the user can tell the list is open and where its bounds are.This is especially visible when the parent
View/Windowuses a scheme whoseNormalbackground matches the list's (e.g. an app that sets its top-level window to theAccent/Basescheme): the expandedDropDownListis nearly invisible against the SuperView.To Reproduce
Steps to reproduce the behavior:
DropDownListinside aWindow/Viewand give that container a scheme (or rely on the default) whoseNormalbackground matches the list's.DropDownList.Environment
agg/sixel render path while driving a TUI, but it's a scheme/attribute issue independent of the host.Notes / suggested fix
The dropped portion of
DropDownListshould resolve its own scheme (e.g. aMenu/popover scheme) rather than inheritingSuperView.GetScheme(), so itsNormalattribute differs from the SuperView by construction. A golden/attribute test that asserts the expanded list's background attribute!=the SuperView's would prevent regressions.