Severe UI freeze (up to 5 min) opening a Select Custom Field with thousands of values (RT 6.0.3)

RT Users
1

Environment

  • RT version: 6.0.3
  • Database: PostgreSQL
  • Browsers tested: Firefox (severely affected), Chrome-based browsers (affected but less severely)
  • Deployment: nginx + rt-server.fcgi (Plack::Handler::FCGI)

Custom Field configuration

  • Type: Select one value
  • Render Type: Dropdown
  • Applies to: Tickets
  • Approximate number of values: several thousand (customer list)
  • We have two similarly-sized fields (e.g. “Customer” and a queue-specific variant), each applied to a different queue

Problem description

On a ticket display page, the custom field itself loads fine — the initial page/panel request (.../Views/Ticket/Widgets/Display/CustomFieldCustomGroupings?...) completes in ~400ms and all values are already present in the returned HTML.

The problem happens when the field is activated for inline edit (Render Type: Dropdown, panel behavior: click). No additional network request fires at all when clicking the field — everything needed is already in the DOM. However, the UI then freezes:

  • Firefox: up to ~5 minutes before the dropdown becomes usable
  • Chromium-based browsers: ~30 seconds

Other ticket operations (opening tickets, searching, other custom fields with few values) are unaffected and fast. This points specifically to the Select/Dropdown widget’s handling of large option lists, not to server or database performance (we’ve already ruled out backend bottlenecks — DB indexes, FastCGI worker count, etc. — via profiling on our end).

Interesting side observation

If we switch focus away from the Firefox tab (e.g. click into another application) while it’s “frozen” and then switch back, the dropdown appears to have finished rendering almost immediately. This suggests the browser deprioritizes/pauses the blocking work while the tab is in the background, and the accumulated work completes faster once resumed — consistent with a main-thread-blocking loop rather than a genuine network/server wait.

Firefox Profiler findings

We captured a Firefox Profiler recording while the field was “frozen.” The call stack shows a tight loop originating from RT’s own JS:

onFocus [.../NoAuth/js/squished-<hash>.js:309]
  -> focus [.../NoAuth/js/squished-<hash>.js:336]
    -> open [.../NoAuth/js/squished-<hash>.js:432]
      -> refreshOptions [.../NoAuth/js/squished-<hash>.js:341]
        -> HTMLElement.offsetWidth (getter)
          -> Element::GetOffsetRect
            -> Document::FlushPendingNotifications
              -> PresShell::DoFlushPendingNotifications
                -> PresShell::ProcessReflowCommands
                  -> [full nsBlockFrame / nsFlexContainerFrame reflow tree]

It looks like refreshOptions reads offsetWidth (likely per-option, or in a loop related to the option count), and each read forces a synchronous layout reflow of the whole page (classic “layout thrashing”). With only a handful of options this is unnoticeable; with several thousand it becomes a multi-second-to-multi-minute main-thread block, scaling with the size of the value list.

Question / ask

  • Is this a known scaling limitation of the Select/Dropdown custom field widget with very large value lists?
  • Is there an existing issue/fix for this, or a recommended workaround (batching the reflow-forcing measurement, caching offsetWidth, avoiding per-option width reads) beyond switching the field to a freeform Enter one value type backed by an external RT::CustomFieldValues::External source (which we understand avoids rendering the full list client-side, but requires custom Perl code)?
  • Would a bug report with the full profiler trace be useful, and if so what’s the best way to attach it (it’s fairly large)?

Happy to provide more details, HAR files, or the full profiler capture if that helps track this down.