Fix Jump to field (ctrl + j) in the entry editor doesn't work

[adeifv]

Summary

The jump-to-field dialog now searches all known field names instead of only currently shown fields, and adds the field to the view if it isn't already visible (the same behaviour as clicking a "+" chip).

IMPORTANT:
Additionally,

1. field editor focus was broken for non-required fields.
2. fields were not scrolled into view when jumped to.
3. fields inside collapsed sections could not be focused at all.
4. dialog was not opened after left-clicking on another entry in the main entry table.

All four issues are fixed too.

jabref-contrib-policy:4.2:reviewed​:ok

Steps to test

As described in #16593

Screencast.from.2026-08-20.22-18-03.webm

Related issues and pull requests

Closes #16593

AI usage

---

GitHub Copilot by Student Pack, which only provides the Auto option, to assist with understanding certain concepts and implementing few parts. I also used the free tier of Claude Sonnet 5 available on its website.

Checklist

• I own the copyright of the code submitted and I license it under the MIT license
• If AI tools were used, I disclosed them in the "AI usage" section and reviewed, understood, and take full ownership of all AI-generated code
• I manually tested my changes in running JabRef (always required)
• I added JUnit tests for changes (if applicable)
• I added screenshots in the PR description (if change is visible to the user)
• I described the change in CHANGELOG.md describing the change from the user's point of view (if the change is visible to the user)
• I checked the user documentation for up to dateness and submitted a pull request to our user documentation repository

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Fix jump-to-field (Ctrl+J) to add and focus hidden entry editor fields

🐞 Bug fix 📝 Documentation 🕐 20-40 Minutes

AI Description

• Make jump-to-field search all known field names, not just currently visible editors.
• When a target field is hidden, add it to the All Fields tab and focus it.
• Ensure focused fields expand collapsed sections and scroll into view.

Diagram

graph TD
  A["Jump-to-field dialog"] --> B["JumpToFieldViewModel"] --> C["FieldFactory (all fields)"]
  A --> D["EntryEditorFocusUtils"] --> E["AllFieldsTab"] --> F["FieldEditorFX (focus+scroll)"]

Loading

High-Level Assessment

The chosen approach is appropriate for JabRef’s entry editor architecture: use the global field registry for discovery, and route focus through AllFieldsTab so it can materialize hidden fields and expand collapsed UI sections. Alternatives like keeping a cached AllFieldsTab reference or limiting the search list to entry-type fields are either minor refactors or change the intended UX.

Files changed (5) +90 / -20

Bug fix (4) +89 / -20

AllFieldsTab.javaExpand collapsed sections and add-and-focus fields on demand +29/-6

Expand collapsed sections and add-and-focus fields on demand

• Tracks section TitledPanes so requestFocus can expand collapsed sections before focusing a field. Defers focus/linked-file dialog opening via Platform.runLater and introduces addFieldAndFocus to materialize a missing field and immediately focus it.

jabgui/src/main/java/org/jabref/gui/entryeditor/AllFieldsTab.java

EntryEditorFocusUtils.javaFallback to All Fields tab when the target field is not shown +17/-1

Fallback to All Fields tab when the target field is not shown

• Extends jump-to-field focus logic: if the field (or its alias) is not currently shown in any tab, it selects the All Fields tab and adds the field (only if it is a known non-internal field) before focusing.

jabgui/src/main/java/org/jabref/gui/entryeditor/EntryEditorFocusUtils.java

JumpToFieldViewModel.javaList all known field names for jump-to-field search +6/-8

List all known field names for jump-to-field search

• Switches the dialog’s searchable field list from ‘currently shown fields’ to all known non-internal fields via FieldFactory, ensuring fields can be found even when not currently displayed.

jabgui/src/main/java/org/jabref/gui/entryeditor/JumpToFieldViewModel.java

FieldEditorFX.javaFix focus targeting and scroll focused editors into view +37/-5

Fix focus targeting and scroll focused editors into view

• Improves focus behavior by locating the first TextInputControl within an editor (fixing cases where focusing the container did nothing) and scrolls the focused node into view by adjusting the nearest ScrollPane’s vvalue.

jabgui/src/main/java/org/jabref/gui/fieldeditors/FieldEditorFX.java

Documentation (1) +1 / -0

CHANGELOG.mdDocument improved Jump-to-field behavior +1/-0

Document improved Jump-to-field behavior

• Adds a changelog entry noting that Jump to field now searches all known fields and auto-adds the selected field if it is not currently visible.

CHANGELOG.md

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. showFieldEditor missing staleness recheck ✓ Resolved 📘 Rule violation ☼ Reliability

Description

AllFieldsTab#showFieldEditor(...) schedules a nested Platform.runLater that performs focus
changes and may open the add-file dialog without re-checking that the tab is still bound to the
original entry, allowing UI changes to apply to stale state. If the entry changes between the
initial guard and the nested callback’s execution, the wrong entry’s editor can be focused and the
add-file dialog can be opened for the wrong entry, violating the runLater staleness-guard
requirement.

Code

jabgui/src/main/java/org/jabref/gui/entryeditor/AllFieldsTab.java[R595-598]

+            Platform.runLater(() -> {
+                requestFocus(field);
+                // Adding the File field via its "+" chip should immediately open the add-file dialog,
+                // since an empty File editor has no other purpose than to receive a file.

Evidence

PR Compliance ID 34 requires deferred JavaFX callbacks to guard against stale state at execution
time. In showFieldEditor, there is an entry-identity guard (`if (getCurrentEntry() != entry)
return;) before scheduling additional deferred work, but the newly added inner Platform.runLater`
runs later than that check and performs requestFocus / addNewFile actions without re-validating
getCurrentEntry() against the original entry, so the entry can change between the check and when
the UI mutation/dialog action actually executes.

jabgui/src/main/java/org/jabref/gui/entryeditor/AllFieldsTab.java[588-602]
jabgui/src/main/java/org/jabref/gui/entryeditor/AllFieldsTab.java[585-603]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`AllFieldsTab#showFieldEditor(...)` uses a nested `Platform.runLater` where the inner callback performs UI mutations (e.g., `requestFocus(...)` and potentially `linkedFilesEditor.addNewFile()`) without verifying that the scheduled work is still current (i.e., the tab is still bound to the same `entry`). Because the guard (`if (getCurrentEntry() != entry) return;`) runs before the nested scheduling, the `entry` can change between the outer check and the inner runnable’s execution, causing focus/actions (including opening the add-file dialog) to apply to the wrong entry.
## Issue Context
There is already an outer deferred block intended to wait for UI rebuild and it checks `getCurrentEntry() != entry` before proceeding, but then it enqueues another deferred callback that can run after the entry/tab state changes again; this weakens the staleness guard and violates the requirement (PR Compliance ID 34) to re-check state at the time deferred work executes.
## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/entryeditor/AllFieldsTab.java[585-604]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. focus() runLater unguarded ✓ Resolved 📘 Rule violation ☼ Reliability

Description

FieldEditorFX.focus() schedules scrollToVisible(target) via Platform.runLater without checking
that target is still attached/current when the callback runs. This risks applying UI mutations to
stale controls and violates the runLater staleness-guard requirement.

Code

jabgui/src/main/java/org/jabref/gui/fieldeditors/FieldEditorFX.java[R143-146]

+        Node target = findTextInput(getNode()).map(input -> (Node) input).orElseGet(this::getNode);
+        target.requestFocus();
+        Platform.runLater(() -> scrollToVisible(target));
+    }

Evidence

PR Compliance ID 34 requires guarding deferred JavaFX callbacks against stale state. The new
Platform.runLater(() -> scrollToVisible(target)) mutates scroll position later without any
validation that target is still current.

jabgui/src/main/java/org/jabref/gui/fieldeditors/FieldEditorFX.java[142-146]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`FieldEditorFX.focus()` defers scrolling with `Platform.runLater` but does not verify that the `target` node is still valid/attached when the callback executes.
## Issue Context
The compliance rule requires stale-state guards for deferred UI mutations. A simple guard like `if (target.getScene() == null) return;` (or equivalent) inside the callback can prevent stale updates.
## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/fieldeditors/FieldEditorFX.java[142-176]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Alias adds wrong field ✓ Resolved 🐞 Bug ≡ Correctness

Description

When a field isn’t currently shown, EntryEditorFocusUtils#setFocusToField falls back to
addFieldViaAllFieldsTab(field) even if an alias exists (e.g., journal↔journaltitle). In
BibLaTeX mode this can add the deprecated BibTeX field (journal) instead of the canonical BibLaTeX
field (journaltitle), leading users to edit the wrong field.

Code

jabgui/src/main/java/org/jabref/gui/entryeditor/EntryEditorFocusUtils.java[R75-77]

+                    getTabContainingField(aliasField).ifPresentOrElse(
+                            tab -> selectTabAndField(tab, aliasField),
+                            () -> addFieldViaAllFieldsTab(field));

Evidence

The fallback calls addFieldViaAllFieldsTab(field) after alias lookup fails, but alias mappings
explicitly map BibTeX to BibLaTeX field names (e.g., JOURNAL -> JOURNALTITLE) and BibLaTeX entry
types require the BibLaTeX variant, so adding the original BibTeX field in BibLaTeX mode is
incorrect/deprecated.

jabgui/src/main/java/org/jabref/gui/entryeditor/EntryEditorFocusUtils.java[70-102]
jablib/src/main/java/org/jabref/model/entry/EntryConverter.java[20-39]
jablib/src/main/java/org/jabref/model/entry/types/BiblatexEntryTypeDefinitions.java[17-25]
jablib/src/main/java/org/jabref/model/entry/types/BibtexEntryTypeDefinitions.java[21-25]
jablib/src/main/java/org/jabref/model/entry/BibEntryType.java[88-109]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`EntryEditorFocusUtils#setFocusToField` checks `EntryConverter.FIELD_ALIASES` but if neither the requested field nor its alias is currently shown, it always falls back to `addFieldViaAllFieldsTab(field)` using the **original** field. For BibTeX↔BibLaTeX alias pairs, this can add a deprecated/non-canonical field in the current database mode (e.g., adding `StandardField.JOURNAL` in BibLaTeX mode where `StandardField.JOURNALTITLE` is the required canonical field).
### Issue Context
- Aliases are explicitly defined as BibTeX→BibLaTeX (`JOURNAL -> JOURNALTITLE`) and inverted.
- BibLaTeX article requires `JOURNALTITLE`, BibTeX article requires `JOURNAL`.
- In BibLaTeX mode, BibTeX-source fields are treated as deprecated.
### Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/entryeditor/EntryEditorFocusUtils.java[70-102]
- jablib/src/main/java/org/jabref/model/entry/EntryConverter.java[20-39]
### Suggested fix
- Decide which field to add based on active `BibDatabaseMode`:
- If mode is BibLaTeX and `field` is a key in `FIELD_ALIASES_BIBTEX_TO_BIBLATEX`, add the mapped BibLaTeX field.
- If mode is BibTeX and `field` is a key in `FIELD_ALIASES_BIBLATEX_TO_BIBTEX`, add the mapped BibTeX field.
- Otherwise add `field`.
- This likely requires passing `BibDatabaseMode` (or a `StateManager`/context supplier) into `EntryEditorFocusUtils`, since it currently doesn’t know the mode.
- Keep existing behavior when the requested field is already shown (don’t remap in that case).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View medium (1)

4. Scroll-to-visible is fragile ✓ Resolved 🐞 Bug ☼ Reliability

Description

FieldEditorFX.scrollToVisible assumes the first ScrollPane ancestor has non-null content and
computes offsets by summing layoutY, which is brittle and can NPE if ScrollPane#getContent() is
null. The repo already contains a safer scroll-into-view implementation using scene/local bounds
transforms.

Code

jabgui/src/main/java/org/jabref/gui/fieldeditors/FieldEditorFX.java[R165-170]

+            if (currentNode instanceof ScrollPane scrollPane) {
+                double contentHeight = scrollPane.getContent().getLayoutBounds().getHeight();
+                double viewportHeight = scrollPane.getViewportBounds().getHeight();
+                if (contentHeight > viewportHeight) {
+                    double target = (offsetY - viewportHeight / 2) / (contentHeight - viewportHeight);
+                    scrollPane.setVvalue(Math.clamp(target, 0, 1));

Evidence

The new implementation dereferences scrollPane.getContent() without a null check and uses a
simpler geometry computation than an existing proven approach in WalkthroughScroller that
explicitly guards null content and uses coordinate transforms.

jabgui/src/main/java/org/jabref/gui/fieldeditors/FieldEditorFX.java[142-177]
jabgui/src/main/java/org/jabref/gui/walkthrough/utils/WalkthroughScroller.java[93-112]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`FieldEditorFX.scrollToVisible` may throw an NPE (`scrollPane.getContent().getLayoutBounds()`) when encountering a `ScrollPane` with null content, and its `layoutY` accumulation is less correct across nested layouts/skins/transforms.
### Issue Context
There is already a robust implementation in `WalkthroughScroller#scrollIntoScrollPane` that:
- null-checks `scrollPane.getContent()`
- uses `localToScene`/`sceneToLocal` bounds transforms
- clamps vValue safely via `Math.max/min`
### Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/fieldeditors/FieldEditorFX.java[142-177]
- jabgui/src/main/java/org/jabref/gui/walkthrough/utils/WalkthroughScroller.java[93-112]
### Suggested fix
- Replace the `layoutY`-sum approach with the bounds-based approach used in `WalkthroughScroller#scrollIntoScrollPane` (or extract a shared utility).
- At minimum:
- guard `Node content = scrollPane.getContent(); if (content == null) return;`
- compute target position using `Bounds targetBounds = node.localToScene(node.getBoundsInLocal())` and `content.sceneToLocal(targetBounds)`
- clamp with `Math.max(0, Math.min(1, ...))`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[subhramit]

Thank you for the clean PR, the video, and the honest writeups. We will review this soon.

[ThiloteE]

Tried this PR on my machine. Mostly works.

If users have custom entry-editor tabs with duplicated fields in the main tab, it will jump to the custom tab first, which I like.

I found one problem: ctrl+j only works, if an entry editor tab is actually selected (e.g. by left-click). Maybe this was also the reason why I thought it was broken.

How to reproduce:

1. Start JabRef and open a library containing an entry
2. Double click on an entry
3. Press ctrl + j
4. See that the dialog opens (good). Cancel with ESC
5. Left-click on another entry in the main entry table
6. Press ctrl + j
7. See that the dialog does NOT open (bad).

The keybinding doesn't seem to be global or maybe this is a listener / sync issue between currently opened editor tab.

[adeifv]

Tried this PR on my machine. Mostly works.

If users have custom entry-editor tabs with duplicated fields in the main tab, it will jump to the custom tab first, which I like.

I found one problem: ctrl+j only works, if an entry editor tab is actually selected (e.g. by left-click). Maybe this was also the reason why I thought it was broken.
...

@ThiloteE , Thanks for the feedback.
This issue is inherited from main too.
After double-clicking an entry, then left-clicking another entry or moving with the arrow keys, it moves keyboard focus into the main table. As the ctrl+j handler was registered locally, the shortcut silently stops working whenever focus sits outside the editor.
also the next/previous-entry shortcuts (alt+up/alt+down) fail for the same reason. this is barely noticeable, as in practice for navigating entries one mostly uses the plain up/down arrows anyway.
and the only way to use ctrl+j again is to double-click the entry once more, which isn't practical during normal browsing.

After the fix, the handler now lives at the frame level. It stays a no-op while the entry editor is hidden, so behavior is otherwise unchanged.

Could you give it another try?

[LoayTarek5]

Solid work @adeifv.
just small things, also i see that no requirement exists for jump-to-field, so i think it worth adding

[koppor]

🤖 Generated with Claude Code

I pushed 7def69b to this branch: with the entry editor closed, Ctrl+J did nothing at all. The new global handler in JabRefFrame required editorShowing to already be true; it now opens the editor first when an entry is selected, and then shows the dialog.

Repro that was broken: open Chocolate.bib → close the entry editor → select an entry in the main table → Ctrl+J.

Verified against the branch that the "Files and links" case from #16593 also works now: jumping to file expands the collapsed section and scrolls it into view.

[koppor]

JabCon: This is on the milestone, thus we (hopefully) fix for ourselves.

[koppor]

🤖 Generated with Claude Code

Pushed 190841e: Enter in the dialog did nothing on the first press.

While the autocompletion popup is open it is the popup's list that receives Enter (ControlsFX fires its "suggestion chosen" handler there), so searchField's onAction — the only thing that fires the OK button — never ran. The dialog just stayed open, which is why "I key in volume, I press Enter, nothing happens" reproduces for any field name that has a suggestion. Pressing Enter a second time worked, because by then the popup was gone.

Two changes in JumpToFieldDialog:

• confirm the dialog from the completion event as well, so the first Enter jumps (clicking a suggestion now jumps too);
• match suggestions by prefix instead of ControlsFX' default substring matching. The popup always preselects its first suggestion, so with substring matching typing file offered dayfiled first and Enter would have jumped there.

Verified on this branch with Chocolate.bib / Hooper_2012, starting from the "biblatex source" tab: pages, volume and file each jump on the first Enter (file expands the collapsed "Files and links" section). Before the change, the same three attempts left the dialog open and the text accumulating.

[koppor]

🤖 Generated with Claude Code

Pushed 3a30381: a "Field will be created" hint under the input, shown while the typed name is not one of the offered fields.

The hint would have been a lie on its own: addFieldViaAllFieldsTab bailed out for anything outside FieldFactory.getAllFieldsWithOutInternal(), so a custom field name did nothing at all. That guard is gone — the jump now creates the field the same way the Main tab's free-form add row does.

Verified with Chocolate.bib / Hooper_2012: no hint for volume, hint for a name that does not exist, and Enter on that name adds the field to the Main tab with its editor focused.

[jabref-machine]

You ticked that you modified CHANGELOG.md, but no new entry was found there.

If you made changes that are visible to the user, please add a brief description to the CHANGELOG.md file, along with the issue number when one exists; otherwise link the pull request. If you did not, please replace the cross ([x]) by a slash ([/]) to indicate that no CHANGELOG.md entry is necessary. More details can be found in our Developer Documentation about the changelog.

[koppor]

🤖 Generated with Claude Code

False alarm — your CHANGELOG.md entry is fine. The check greps the pull request description for the template's checklist line and, since #16901 (merged this morning), only accepts its literal wording - [x] I added **one sentence (max 20 words)** to `CHANGELOG.md` .... Your description rephrases it as "I described the change in CHANGELOG.md", so the grep found nothing; the bot then posted a message that on top of that describes the opposite failure direction.

#16932 fixes the check. Until it lands, restoring the template wording of that one checklist line turns the job green.