non-rounded borders for CDropdownToggle

[arikorn]

If a dropdown menu is made without the caret, only the left side of the toggler is rounded on hover (the darker background, here).

This appears to be due to the first selector in the rule:

.btn-group > .btn:not(:last-child):not(.dropdown-toggle),
.btn-group > .btn.dropdown-toggle-split:first-child,
.btn-group > .btn-group:not(:last-child) > .btn {
    border-start-end-radius: 0;
    border-end-end-radius: 0;
}

The problem is that in the standard order of coding dropdown menus:

		<CDropdown ...>
			<CDropdownToggle caret={false} ...>...</CDropdownToggle>
			<CDropdownMenu>...</CDropdownMenu>
		</CDropdown>

CDropdown, the parent, is a btn-group and it has two children and the toggler is the first one, but because caret={false}, the toggler is not assigned the class dropdown-toggle, so the selector is satisfied:

<div class="btn-group help-menu">
    <button class="btn btn-primary>...</button>
    <ul class="dropdown-menu">...</ul>
</div>

So it seems that there are two potential solutions:

• A simple fix may be to change .btn:not(:last-child) to .btn:not(:last-of-type) in coreui/scss, possibly in two places in that file.
• Alternatively, always assign togglers to the class dropdown-toggle?

I'm not sure of the consequences of each options, so am not posting this as a PR.

Also, as best as I can tell this is a recent problem, as it used to work correctly. [Edit: see next comment.]

Windows 11, Chrome, but this should be irrelevant.

[arikorn]

It turns out that the problem has probably been there for a long time. Some notes:

1. I found the following in my own code in Bitfocus Companion, apparently having left myself a note for just this occasion!

// technical detail: unlike the other elements, CDropdownToggle does not define a 'dropdown-toggle' CSS class,
// but worse, if you add it manually, caret={false} is ignored, ...

The first line of my note appears to have been based on the assumption that caret={true}; the second line indicates that my second suggestion above (always set caret true) would probably not work as desired here without further fixes.

2. I figured out why the problem recently appeared, and it's a bit complicated: previously, we had set overflow: hidden on a CSS .btn-group rule, perhaps to solve this very problem or its first-item-in-group relative. The result was that the btn-group div clipped the square corners that are set on the btn in the rule quoted above, so even though the btn rule was triggering, the border-radius defined in btn-group (by coreui) clipped those corners -- effectively overruling the child btn css. Unfortunately, overflow: hidden is a bit of a nuclear option, since it also completely clips any dropdowns in the btn-group. So I deleted the overflow line, which fixed the dropdowns while revealing the underlying bug.

3. On the good-news side, changing the CSS rule to .btn:not(:last-of-type) as in my first suggestion does solve the problem reported above. (Tested by patching coreui in Companion.) However,...

4. In looking through the Companion codebase/UI, there appear to be a number of failure points on both last-child and first child cases (all of which were "solved" by the untenable overflow: hidden rule).
   For example for the left-side rounding, the selector: .btn-group > :not(.btn-check) + .btn (which will override the rounding) is satisfied even though the first child is hidden. I.e, when the button-group contains two items, but the first has class d-xl-none and the window is wide enough.
   (There is at least one other edge-case but that may be fixable on our side)

So are these problems fixable? Are there known workarounds, for the "hidden first or last button" case?
Also, are there any unintended consequences of using .btn:not(:last-of-type) to solve the basic dropdown case (which is a problem all on its own, since dropdown creates a button-group.)