jira:customFieldType + Custom UI + isInline:true — edit resource iframe never loads eagerly on issue-view, only after user click

Forge Forge UI Kit and Custom UI
, ,
1

Summary

For a jira:customFieldType field using Custom UI with isInline: true and
edit.experience including issue-view, the edit resource’s iframe never mounts
on initial issue-view page load. It only mounts after the user clicks/interacts
with the field. Before that click, the field area renders completely blank
(no content, no Jira native fallback, nothing) — confirmed via DevTools Network
tab by tracking the unique content-hash of the compiled bundle.

This defeats the purpose of isInline (which per the docs should render the
field inline on issue-view without requiring a modal or a click), for any
use case where the field’s display depends on data that must be computed
before the user interacts with it (e.g. a background color driven by a rule
engine evaluating another field’s value).

Environment

  • Forge CLI: [paste your forge --version output]
  • Runtime: nodejs22.x (per manifest below — originally nodejs24.x, please confirm
    whichever you’re actually running)
  • App type: Custom UI (React 18, Create React App build), not UI Kit
  • Jira Cloud (arzenicstech.atlassian.net)

Manifest (relevant excerpt)

modules:
  jira:customFieldType:
    - key: conditional-color-type
      name: Conditional Color
      description: >
        Text field whose displayed color changes based on another field's
        value (Priority or Status). Configure the rule when adding this
        field to a project.
      type: string
      resolver:
        function: colorFieldResolver
      edit:
        resource: conditional-color-ui
        isInline: true
        experience:
          - issue-create
          - issue-transition
          - issue-view
      contextConfig:
        resource: cc-config-ui

  function:
    - key: colorFieldResolver
      handler: index.conditionalColorResolverHandler

resources:
  - key: conditional-color-ui
    path: static/conditional-color/build

permissions:
  scopes:
    - read:jira-work
    - storage:app
    - manage:jira-configuration
    - manage:jira-project

What we tried, and what we ruled out

  1. Originally had a separate view: block pointing to a different Custom UI
    resource (cc-view-ui), following the pattern shown in the manifest
    reference docs (edit + view both declaring “issue-view”):

    edit:
  resource: conditional-color-ui
  isInline: true
  experience: [issue-create, issue-transition, issue-view]
view:
  resource: cc-view-ui
  isInline: true
  experience: [issue-view]

    Confirmed via Network tab (tracking unique build hashes for each resource,
    e.g. main.9bdcb3f7.js for edit vs main.a0b2cb21.js for view) that the
    view: resource’s bundle never loaded, ever — not on page load, not on
    click, not in any state. Only the edit: resource’s bundle ever loaded
    into the DOM, and only after a click. Confirmed builds were genuinely
    different files (different SHA256 hashes), ruling out a build/deploy
    mistake on our end.

  2. Before adding the view resource, with no view block at all, the field on
    issue-view (pre-click) rendered Jira’s own generic native fallback
    (confirmed via data-component-selector="jira-issue-view-single-line-text -inline-edit-view-container" in the DOM inspector) instead of any Forge
    resource.

  3. Removed the view: block entirely (current manifest above, edit-only).
    Result: the pre-click blank state changed — Jira’s native fallback no
    longer renders either. Now nothing renders in the field area until click.
    On click, the edit resource’s iframe mounts (confirmed via Network tab,
    hosted-resources-iframe testid, matching the expected content-hash) and
    the field then displays correctly with its color logic.

Question

Is eager/inline rendering of a jira:customFieldType Custom UI edit resource
on issue-view (before any user interaction) actually supported today, or does
isInline: true for Custom UI only affect what happens after the user
initiates edit (i.e. inline-vs-modal), while the initial display state is
still gated behind interaction?

If eager rendering is supported, what are we missing in the manifest or
resource code to trigger it? If it’s not currently supported for Custom UI
(possibly UI Kit only — noted in an older community thread here:
Customfield Custom UI for render/view),
is there a supported pattern for showing a computed/dynamic background before
the user clicks the field (e.g. a separate module type that always renders,
like jira:issuePanel or jira:issueViewBackgroundScript combined with a custom
field)?

Any pointers appreciated — happy to share a minimal repro repo if useful.

2

Not supported, and that is documented. The custom field type reference carries a note under View mode: custom rendering currently cannot be implemented using Custom UI. The 2021 thread you linked is still the answer, KamilRichert there is Atlassian staff and edit only is what he said. The schema still accepts a Custom UI view: block (no render: native required), so lint stays quiet and the bundle is not requested at all. Matches your Network tab.

isInline does not touch that. CHANGE-2023 words it as inline rendering in edit mode. Inline vs modal, after the click.

Pre-click colour means a UI Kit view. The resource has to be a @forge/react entry, teh CRA build will not do:

view:
  resource: cc-view-kit
  render: native
  experience:
    - issue-view
resources:
  - key: cc-view-kit
    path: src/frontend/view.jsx

Value comes from useProductContext(). Keep the Custom UI edit as is, Kamil’s post 4 in that thread describes exactly that split. Untested on my side, so post what happens.

3

Thanks for the help Mihai !