Skip to content

fix(angular): stop a selected field-picker option rendering white-on-panel - #58

Merged
duguankui merged 1 commit into
mainfrom
fix/select-option-selected-contrast
Sep 4, 2026
Merged

fix(angular): stop a selected field-picker option rendering white-on-panel#58
duguankui merged 1 commit into
mainfrom
fix/select-option-selected-contrast

Conversation

@duguankui

Copy link
Copy Markdown
Member

Description

A selected option in the field picker's dropdown rendered white text on the panel background once
the mouse left it. Same defect, same shape, as dignite-projects/abp-modules#222 — this picker carried
an identical copy of the rule.

The rule meant to give a selected option a --lpx-brand fill carried !important on its colour but
not on its background:

::ng-deep .field-picker-dropdown .ant-select-item-option-selected:not(.ant-select-item-option-disabled) {
  background-color: var(--lpx-brand);        // ← no !important
  color: var(--bs-white) !important;
}

while the .ant-select-item rule below it zeroes every option background with !important, to stop
ant-design's own idle-state default painting through. !important beats specificity, so the
background never applied and the white text always did — invisible while the panel was still #fff,
merely illegible once it started following --bs-secondary-bg. The hover rule directly above has
!important on both halves, which is why hovering a selected option looked right and moving off it
did not.

Rather than adding the missing !important, the rule is removed. A selected option now reads
exactly like an unselected one, with ant-design's own checkmark (.ant-select-item-option-state) as
the indicator. The picker is nzMode="multiple" — several options are selected at once, so filling
each of their rows competes with the hover state for attention rather than adding information.

The page-parent picker is untouched: it is single-select, and its own selected-node rule already
carries !important on both halves, so it never had this problem.

How to test it?

Open the content-type editor's field picker, select two or three fields, and move the mouse off the
dropdown. Every option should read the same, with checkmarks marking the selected ones; hovering
should still give the blue --bs-primary row with white text.

ng build site passes. The compiled output no longer carries the selected-option rule and keeps the
panel, hover and idle-option rules unchanged. No tests added — this is emitted CSS, and the repo has
no stylesheet coverage to extend.

…panel

The rule meant to give a selected option a --lpx-brand fill carried !important on its colour but not
on its background, while the .ant-select-item rule below it zeroes every option background with
!important to stop ant-design's own idle-state default painting through. !important beats
specificity, so the background never applied and the white text always did: a selected option
rendered white on whatever the panel was - invisible while that was still #fff, and merely illegible
once the panel started following --bs-secondary-bg. The hover rule directly above has !important on
both halves, which is why hovering a selected option looked right and moving off it did not.

Rather than adding the missing !important, the rule is removed. A selected option now reads exactly
like an unselected one and ant-design's own checkmark (.ant-select-item-option-state) is the
indicator. This picker is nzMode="multiple": several options are selected at once, so filling each of
their rows competes with the hover state for attention rather than adding information.

@dignite/ng.flex-fields' Select control carried an identical copy of the same rule and gets the same
fix.
@duguankui
duguankui merged commit 17fd31c into main Sep 4, 2026
1 check passed
duguankui added a commit that referenced this pull request Sep 4, 2026
Moves @dignite/ng.flex-fields, its -ckeditor and -file-explorer adapters and
@dignite/ng.file-explorer from ^10.0.0-rc.13 to ^10.0.0-rc.14, in both the Host dev app and the
published library.

The library-side change in rc.14 is CSS only - the Tree control's config and search components stop
painting hardcoded light-mode ng-zorro chrome and follow the host theme instead, matching what #57
and #58 did for this repository's own pickers. No API surface moved.

The release-side change is the one that matters here. Through rc.13 the two adapter packages
declared their intra-repo siblings at "^10.0.0-rc.4"; that range admits an older sibling, and Yarn
Classic prefers the latest-tagged version for any range that admits it, so a plain install produced
two copies of @dignite/ng.flex-fields - which, FLEX_FIELD_TYPES being a module-scoped
InjectionToken, is two distinct DI keys and every field type absent at runtime. rc.14 declares those
siblings at the released version.

Verified rather than assumed, because abp-modules' own post-publish single-copy check never ran
green against rc.14 - it failed on an unrelated npmrc bug in the release workflow, fixed after the
tag was cut and never re-run against it. A full re-resolve here with no lockfile and the
"resolutions" block removed installs exactly one copy of each of the four packages at rc.14, so the
upstream fix does hold. yarn test (29 tests), ng build site and ng build Host all pass.

The "resolutions" block is bumped rather than dropped: only the manifest half of the problem is
gone. abp-modules still publishes pre-releases under the "next" dist-tag alone, so npmjs' "latest"
keeps lagging, and the block makes the single-copy guarantee independent of a dist-tag this
repository does not control. check-angular-package-duplicates.mjs is what will say when it has
become redundant.
@duguankui
duguankui deleted the fix/select-option-selected-contrast branch September 5, 2026 00:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant