Desktop rename box: white text on a hardcoded white gradient with any dark theme (also black caret)

Nemo 6.0.2, Cinnamon 6.x, Ubuntu 24.04, GTK theme Adwaita-dark

What happens

Renaming an icon on the desktop (F2) shows the filename as near-white text on a
white background — unreadable. The text caret is black on a dark background, so it is
invisible too. Renaming inside a Nemo window is fine; it is desktop-only, and only with
a dark GTK theme.

Cause

Two stylesheets shipped in the gresource fight over the same node, and each one only
wins part of the properties:

nemo-style-application.css:

.nemo-desktop.view .entry,
.nemo-desktop.view .entry:active,
.nemo-desktop.view .entry:focus,
.nemo-desktop.view .entry:backdrop {
    color: #000000;
    caret-color: #000000;
    background-image: -gtk-gradient(linear, ... rgba(255,255,255,1) ...);
}

nemo-style-fallback-mandatory.css:

.nemo-window .nemo-window-pane widget.entry {
    color: @theme_fg_color;
    background-color: @theme_bg_color;
}

The desktop window carries both .nemo-window/.nemo-window-pane and
.nemo-desktop, so the mandatory rule matches there as well, and it has higher
specificity (0,3,1 vs 0,3,0). It therefore overrides color and background-color —
but it never declares background-image or caret-color, so those two keep the
hardcoded light-theme values from the application sheet.

Result with a dark theme:

property	resolved	from
color	#eeeeec	mandatory (@theme_fg_color)
background-color	#353535	mandatory (@theme_bg_color)
background-image	white gradient	application sheet, not overridden — painted over the background-color
caret-color	#000000	application sheet, not overridden

So the visible result is #eeeeec text on a white gradient, with a #000000 caret.
With a light theme @theme_fg_color is dark, which is why the bug has gone unnoticed.

Reproducing the resolved values

Loading the two shipped stylesheets at GTK_STYLE_PROVIDER_PRIORITY_APPLICATION and
querying a GtkStyleContext built on the desktop node path
(window.nemo-window.nemo-desktop-window > box.nemo-window-pane > box.nemo-desktop.view > widget.entry)
returns exactly the table above under Adwaita-dark. Removing .nemo-desktop from the
path returns background-image: None, confirming the in-window case is unaffected.

Suggested fix

Have the mandatory rule neutralize the two leftovers, so the themed colors are the ones
that actually get painted:

.nemo-window .nemo-window-pane widget.entry {
    border: 1px solid;
    border-radius: 3px;
    color: @theme_fg_color;
    caret-color: @theme_fg_color;     /* + */
    border-color: @theme_selected_bg_color;
    background-color: @theme_bg_color;
    background-image: none;           /* + */
}

Alternatively, drop the hardcoded color/caret-color/white gradient from
.nemo-desktop.view .entry in nemo-style-application.css and let the theme provide
them.

Workaround

In ~/.config/gtk-3.0/gtk.css (user CSS outranks the application-priority sheet):

.nemo-desktop.view .entry,
.nemo-desktop.view .entry:active,
.nemo-desktop.view .entry:focus,
.nemo-desktop.view .entry:backdrop {
    background-image: none;
    caret-color: @theme_fg_color;
}

then restart nemo-desktop.

Start by comparing the matching rules in nemo-style-application.css and nemo-style-fallback-mandatory.css, then reproduce the desktop rename field with GTK Adwaita-dark. Update the stylesheet rule so the desktop field uses themed colors without the leftover gradient or black caret, and verify that desktop renaming is readable while renaming inside a Nemo window remains unaffected.