Project

General

Profile

Actions

Defect #44347

closed

Filter/query text input fields lose border and background (unscoped CSS injected by modal-issue feature)

Added by Julius Haman 1 day ago. Updated 1 day ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Resolution:
Invalid
Affected version:

Description

On the issue list "Filter" panel (and any other page with a plain <input type="text">, type="date", type="password", type="search" or type="number" element), the input has no visible border and no visible background. The typed value looks like plain floating text, so it is very hard to tell it is an editable field at all. Reproduced in Chrome, Firefox and Edge, so this is a CSS problem, not a browser rendering difference.

Dropdown/select filter fields (e.g. the operator selects) are not affected and render normally.

Steps to reproduce

  1. Open any issue list, e.g. /projects/<project>/issues.
  2. Expand the "Filter" panel if it is collapsed.
  3. Add a filter that uses a free-text value field, e.g. "Ticket" (issue id) with operator "is", or any text custom field with operator "contains".
  4. Type a value into the text field.

Expected behavior

The text input should render with the normal input styling: a visible border and background, as before and as again in 7.0.

Actual behavior

The input has border-style: none and outline: none and no distinguishable background, so it is visually indistinguishable from static text.

Root cause (found via DevTools)

Redmine 6.x loads a JS bundle for the newer "modal issue" quick-view/quick-edit feature (asset modal-issue-*.js). This bundle injects a <style> element directly into <head> at runtime, not scoped to the modal component (e.g. via a class prefix or Shadow DOM). Among its rules is this unscoped reset, presumably only intended for the modal's own form controls (other rules in the same injected stylesheet ARE scoped, e.g. .rm-input__input, .kanban-options__list input[type="number"], .realstatuses__select ...):

input[type="text"], input[type="date"], input[type="password"],
input[type="search"], input[type="number"] {
  border-style: none;
  outline: none;
}

Because this selector has no scoping class, it applies to every matching input on the page, including the classic server-rendered query filter fields, which have nothing to do with the modal-issue feature.

Confirmed the causal link in DevTools: disabling this specific injected stylesheet (document.styleSheets[N].disabled = true) immediately restored the filter input's border/background.

Additional notes

This already appears to be fixed in 7.0, most likely as a side effect of the general CSS cleanup done for that release rather than a dedicated fix for this exact symptom, since we could not find an existing tracker ticket describing it.

Workaround for a custom theme on 6.x installations:

#query_form input[type="text"],
#query_form input[type="date"],
#query_form input[type="search"],
#query_form input[type="number"] {
  border: 1px solid #bbb;
  background: #fff;
}
Actions #1

Updated by Go MAEDA 1 day ago

Thank you for the detailed report. However, I could not reproduce this on a clean installation of Redmine 6.1, and I believe this is not an issue with Redmine core. Redmine has never shipped an asset named modal-issue-*.js, nor does Redmine core provide a "modal issue quick-view/quick-edit" feature.

I suspect that the issue may be caused by a third-party plugin or theme. Could you please try removing them and see if the problem is resolved? If so, please contact the author of the plugin or theme.

Actions #2

Updated by Julius Haman 1 day ago

Thank you for looking into this. You were right - this is not a Redmine core issue.

We confirmed the root cause on our end: it is caused by the "Kanban" plugin (Enterprise edition, version 2.6.8) from redmine-kanban.com (https://redmine-kanban.com/de). On a fresh Redmine 6.1.3 installation without this plugin the problem does not occur; with the plugin installed on our instance, it reproduces every time. This also matches what we found in the injected stylesheet earlier (the unscoped input reset sat alongside plugin-specific selectors such as .kanban-options__list and .realstatuses__select).

We will report this to the plugin vendor instead. Feel free to close this ticket as "Not our bug" / invalid - sorry for the noise, and thanks again for the quick reply.

Actions #3

Updated by Go MAEDA 1 day ago

  • Status changed from New to Closed
  • Resolution set to Invalid

Thank you for your feedback. I am closing this issue.

Actions

Also available in: Atom PDF