LeptonX 5.3+ custom select breaks Bootstrap .input-group (wrapper margin-bottom: 1rem, no .input-group > .form-select sizing) #10824

4 Answer(s)

• 

  0

  AI-Bot created 2 months ago

  Support Team ABP Agent

  • Add a small LeptonX override in your app stylesheet to special-case Bootstrap .input-group (this fixes both the extra 1rem height and the lost flex sizing caused by .custom-select-wrapper becoming the flex item):

  /* LeptonX 5.3+ FormSelect inside Bootstrap input-group fix */
  .input-group > .custom-select-wrapper {
    flex: 1 1 auto;
    width: 1%;
    min-width: 0;
  
    /* prevent the wrapper's default spacing from increasing the flex row height */
    margin-bottom: 0;
  }
  
  /* optional: make the display fill the wrapper */
  .input-group > .custom-select-wrapper > .custom-select-display {
    width: 100%;
  }
  

  • If you also need sm/lg sizing to match form-select-sm / form-select-lg, add explicit sizing rules for the generated display (because LeptonX hides the native <select> and the size classes don’t affect the visible element):

  /* propagate Bootstrap select sizing to LeptonX display */
  .custom-select-wrapper > select.form-select-sm + .custom-select-display {
    padding-top: .25rem;
    padding-bottom: .25rem;
    font-size: .875rem;
  }
  
  .custom-select-wrapper > select.form-select-lg + .custom-select-display {
    padding-top: .5rem;
    padding-bottom: .5rem;
    font-size: 1.25rem;
  }
  

  • If you need to honor inline width constraints like style="max-width: 92px" applied on the native <select>, CSS alone can’t reliably “copy” inline styles to the generated .custom-select-display. In that case the only deterministic workaround is what you already discovered: restore the native select (or write a tiny JS hook that copies computed width/max-width from the <select> to .custom-select-display after LeptonX initializes).

  No verified source available for this specific .input-group + FormSelect wrapper issue/fix (it’s a theme CSS gap), but the override approach is consistent with ABP’s recommended UI overriding mechanism.

  • https://abp.io/docs/10.3/framework/architecture/modularity/extending/overriding-user-interface

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  brauerj@gc.adventist.org created 2 months ago

  Let me know if this is the right place to submit these types of bugs.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  brauerj@gc.adventist.org created 2 months ago

  Thanks — the workaround is understood; we already landed the equivalent on our side, and I agree that restoring the native select is the only deterministic option once inline widths on the <select> are involved.

  To be clear about the ask, though: this is a report of a gap in the shipped theme CSS, not a request for an app-side workaround. Can it be tracked as a theme bug?

  .custom-select-wrapper { margin-bottom: 1rem } with no .input-group counterpart means every Bootstrap input group containing a select renders misaligned out of the box, in an unmodified template. The CSS already special-cases div.dt-container div.dt-length, .is-invalid / .is-valid and .form-floating, so .input-group looks like an omission rather than a deliberate limitation. It is unchanged across 5.3.0, 5.4.0, 5.4.1, 5.5.0 and 5.6.0.

  Two things would close it properly:

  1. Ship the .input-group > .custom-select-wrapper rule in the theme, rather than having every application add it.
  2. An opt-out hook — a class or data- attribute that FormSelect.init skips — for applications that render selects through a component library (Blazorise, etc.) and need the native element's own classes and inline styles to apply.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 2 months ago

  Support Team Fullstack Developer

  Hi,

  Yes, this is the right place for these reports — thanks for the detailed analysis.

  You're right, this is a gap in the theme CSS: there is no rule integrating .custom-select-wrapper into .input-group, unlike the existing DataTables / validation / .form-floating special cases. We'll fix the custom select's .input-group integration in the theme (both the Blazor and MVC packages) in the next patch release, and we'll evaluate the opt-out hook for FormSelect.init together with it, since component-library scenarios like Blazorise need the native element.

  Until the patch is out, this app-side CSS keeps the custom select and restores the group layout:

  .input-group > .custom-select-wrapper {
    flex: 1 1 auto;
    width: 1%;
    min-width: 0;
    margin-bottom: 0;
  }
  
  /* match Bootstrap's corner flattening for grouped controls */
  .input-group > .custom-select-wrapper:not(:first-child) > .custom-select-display {
    border-top-left-radius: 0;
    border-bottom-left-radius: 0;
  }
  
  .input-group > .custom-select-wrapper:not(:last-child) > .custom-select-display {
    border-top-right-radius: 0;
    border-bottom-right-radius: 0;
  }
  

  Your native-select restore is still the right call where inline widths on the <select> matter, so feel free to keep that instead.

  One correction on the sizing point: the .input-group issue is still present in 5.6.0, but the separate form-select-sm / form-select-lg issue was fixed there — the generated display is now styled based on those classes. Inline styles on the native select are still not transferred; an opt-out hook would let those selects stay native and keep their own styles.

  Your ticket has been refunded.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel