Fix: Comprehensive page navigation for crossref entries in both internal and external viewers (#8128) by Sherry0121-AC · Pull Request #15504 · JabRef/jabref

Sherry0121-AC · 2026-04-07T13:27:12Z

Related issues and pull requests

PR Description

This PR fixes the issue where opening sub-entries (e.g., @InCollection) via the crossref field failed to navigate to the correct start page in external and internal viewers. By implementing a logical-to-physical page translation layer and optimizing the navigation pipeline, JabRef now correctly targets the intended page, gracefully handling PDF front-matter offsets when present. This ensures a consistent and accurate research experience across all desktop platforms.

Steps to test

Create a parent @Book entry in JabRef and link a local PDF file to it.
(Optional but recommended: Use a PDF with roman-numeral front matter to verify the new logical-to-physical page translation feature).
Create a child @InCollection entry. Set crossref pointing to the parent book's citation key, and set the pages field to a specific range (e.g., 186--206).
External Viewer Test: Select the child entry and press F4. The default browser should open the parent PDF and automatically land on the physical page corresponding to the printed page 186.
Internal Viewer Test: Go to View -> Show document viewer. The internal viewer should successfully resolve the parent file and navigate to page 186 for the selected child.

Screenshots:
![External Viewer Jump]

Screenshots: The external browser successfully navigating to physical page 200 (logical page 186) after pressing F4.

![Internal Viewer Jump]

Screenshots: The internal document viewer accurately resolving the parent file and jumping to the correct page.

Known Limitations

Internal Viewer State: Currently, when using the internal document viewer, navigating directly to a child entry might not jump to the specific page if the parent PDF hasn't been loaded into the viewer's cache yet (e.g., by clicking the parent entry first). The external viewer (F4) is unaffected and works perfectly. This appears to be related to the viewer's initialization lifecycle and can be addressed in a follow-up refinement.

Checklist

I own the copyright of the code submitted and I license it under the MIT license
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 added a screenshot in the PR description showing a library with a single entry with me as author and as title the issue number

- [x] I described the change in `CHANGELOG.md` in a way that can be understood by the average user (if change is visible to the user) - [/] I checked the [user documentation](https://docs.jabref.org/) for up to dateness and submitted a pull request to our [user documentation repository](https://github.com/JabRef/user-documentation/tree/main/en)

…nal and external viewers (JabRef#8128)

qodo-free-for-open-source-projects · 2026-04-07T13:27:40Z

Review Summary by Qodo

Add comprehensive page navigation for crossref entries across all platforms

✨ Enhancement 🐞 Bug fix

Walkthroughs

Description

• Implement logical-to-physical PDF page translation for crossref entries
• Add page number support across all desktop platforms (Windows, macOS, Linux)
• Enable internal and external viewers to navigate to correct pages in parent PDFs
• Support crossref fallback when child entries lack direct file attachments

Diagram

flowchart LR
  A["Child Entry with crossref"] -->|resolve parent| B["Parent Entry"]
  B -->|extract pages field| C["Parse Page Number"]
  C -->|PDF with labels| D["PdfPageLabelResolver"]
  D -->|logical to physical| E["Physical Page Number"]
  E -->|pass to OS| F["Platform-specific Viewer"]
  F -->|Windows| G["SumatraPDF/-page"]
  F -->|macOS| H["Adobe/Skim/Browser"]
  F -->|Linux| I["Evince/Okular/Zathura"]

File Changes

1. jabgui/src/main/java/org/jabref/gui/actions/ActionHelper.java ✨ Enhancement +10/-1

Check crossref field for file availability

jabgui/src/main/java/org/jabref/gui/actions/ActionHelper.java

2. jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java ✨ Enhancement +30/-13

Add pageNumber parameter to file opening methods

jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java

3. jabgui/src/main/java/org/jabref/gui/desktop/os/DefaultDesktop.java ✨ Enhancement +2/-2

Update method signatures with pageNumber parameter

jabgui/src/main/java/org/jabref/gui/desktop/os/DefaultDesktop.java

View more (16)

4. jabgui/src/main/java/org/jabref/gui/desktop/os/Windows.java ✨ Enhancement +57/-4

Implement Windows PDF page navigation with SumatraPDF

jabgui/src/main/java/org/jabref/gui/desktop/os/Windows.java

5. jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java ✨ Enhancement +93/-10

Implement macOS PDF page navigation for multiple viewers

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java

6. jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java ✨ Enhancement +76/-7

Implement Linux PDF page navigation for Evince/Okular/Zathura

jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java

7. jabgui/src/main/java/org/jabref/gui/util/PdfPageLabelResolver.java ✨ Enhancement +60/-0

New utility to resolve logical to physical PDF page numbers

jabgui/src/main/java/org/jabref/gui/util/PdfPageLabelResolver.java

8. jabgui/src/main/java/org/jabref/gui/documentviewer/DocumentViewerViewModel.java ✨ Enhancement +73/-3

Support crossref parent PDF and page label resolution

jabgui/src/main/java/org/jabref/gui/documentviewer/DocumentViewerViewModel.java

9. jabgui/src/main/java/org/jabref/gui/documentviewer/ShowDocumentViewerAction.java ✨ Enhancement +1/-1

Update action to check for crossref linked files

jabgui/src/main/java/org/jabref/gui/documentviewer/ShowDocumentViewerAction.java

10. jabgui/src/main/java/org/jabref/gui/fieldeditors/LinkedFileViewModel.java ✨ Enhancement +38/-1

Extract and pass page numbers when opening PDF files

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

11. jabgui/src/main/java/org/jabref/gui/maintable/OpenSelectedEntriesFilesAction.java ✨ Enhancement +17/-1

Support opening parent files via crossref field

jabgui/src/main/java/org/jabref/gui/maintable/OpenSelectedEntriesFilesAction.java

12. jabgui/src/main/java/org/jabref/gui/openoffice/StyleSelectDialogViewModel.java ✨ Enhancement +1/-1

Update file opening call with pageNumber parameter

jabgui/src/main/java/org/jabref/gui/openoffice/StyleSelectDialogViewModel.java

13. jabgui/src/main/java/org/jabref/gui/preferences/protectedterms/ProtectedTermsTabViewModel.java ✨ Enhancement +1/-1

Update file opening call with pageNumber parameter

jabgui/src/main/java/org/jabref/gui/preferences/protectedterms/ProtectedTermsTabViewModel.java

14. jabgui/src/test/java/org/jabref/gui/actions/ActionHelperTest.java 🧪 Tests +48/-0

Test crossref detection in file availability check

jabgui/src/test/java/org/jabref/gui/actions/ActionHelperTest.java

15. jabgui/src/test/java/org/jabref/gui/desktop/os/OSXTest.java 🧪 Tests +72/-0

Test macOS PDF page navigation with browser hash jump

jabgui/src/test/java/org/jabref/gui/desktop/os/OSXTest.java

16. jabgui/src/test/java/org/jabref/gui/documentviewer/DocumentViewerViewModelTest.java 🧪 Tests +165/-0

Test crossref parent PDF resolution and page label mapping

jabgui/src/test/java/org/jabref/gui/documentviewer/DocumentViewerViewModelTest.java

17. jabgui/src/test/java/org/jabref/gui/fieldeditors/LinkedFileViewModelTest.java 🧪 Tests +57/-0

Test page number parsing and passing for PDF files

jabgui/src/test/java/org/jabref/gui/fieldeditors/LinkedFileViewModelTest.java

18. jabgui/src/test/java/org/jabref/gui/util/PdfPageLabelResolverTest.java 🧪 Tests +65/-0

Test logical to physical page number resolution

jabgui/src/test/java/org/jabref/gui/util/PdfPageLabelResolverTest.java

19. CHANGELOG.md 📝 Documentation +1/-0

Document fix for crossref page navigation issue

CHANGELOG.md

qodo-free-for-open-source-projects · 2026-04-07T13:27:41Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (3) 📎 Requirement gaps (0)

1. ~~macOS viewer preference bypass~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

OSX.openFile short-circuits for PDFs with pageNumber>1 and opens via Chrome/Edge or browser URL,
skipping the configured ExternalFileType application entirely. This changes user-visible behavior by
ignoring the preferred PDF viewer even when one is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R29-47]

+    public void openFile(String filePath, String fileType, ExternalApplicationsPreferences externalApplicationsPreferences, int pageNumber) throws IOException {
+        if (isPdf(fileType) && pageNumber > 1) {
+            String fileUrlWithPage = Path.of(filePath).toUri().toString() + "#page=" + pageNumber;
+
+            String chromeBinary = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome";
+            String edgeBinary = "/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge";
+
+            if (Files.exists(Path.of(chromeBinary))) {
+                new ProcessBuilder(chromeBinary, fileUrlWithPage).start();
+                return;
+            }
+            if (Files.exists(Path.of(edgeBinary))) {
+                new ProcessBuilder(edgeBinary, fileUrlWithPage).start();
+                return;
+            }
+
+            NativeDesktop.openBrowser(fileUrlWithPage, externalApplicationsPreferences);
+            return;
+        }

Evidence

The early-return branch for PDFs with pageNumber>1 executes before ExternalFileTypes lookup;
therefore the configured openWithApplication is never consulted for page jumps. The configured
application path is only reached after this early return, making it unreachable for the page-jump
case.

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[28-59]

Agent prompt

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

## Issue description
On macOS, `OSX.openFile(..., pageNumber)` bypasses the user-configured PDF application when `pageNumber > 1`, forcing Chrome/Edge or a browser-based `file://...#page=` open.
### Issue Context
The preference-respecting logic (`ExternalFileTypes.getExternalFileTypeByExt` and `openFileWithApplication`) is currently unreachable in the `pageNumber > 1` PDF case due to an early return.
### Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[28-59]
### Suggested fix approach
1. Resolve the configured `ExternalFileType` first.
2. If an `openWithApplication` is configured, attempt `openFileWithApplication(filePath, application, pageNumber)`.
3. Only fall back to the browser hash jump strategy if no app is configured (or if you explicitly decide the configured app cannot support page jumps).

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

2. openFileWithApplication adds -a twice ✓ Resolved 📎 Requirement gap ≡ Correctness

Description

In OSX.openFileWithApplication, the command list appends -a  and filePath twice, which can
produce an invalid open invocation. This can prevent opening the PDF (and thus page-jump behavior)
when a non-browser, non-Skim application is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R57-80]

+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+
+        if (pageNumber > 1 && appNameLower.contains("skim")) {
+            String appleScript = String.format(
+                    "tell application \"Skim\"\n" +
+                            "  activate\n" +
+                            "  set myDoc to open POSIX file \"%s\"\n" +
+                            "  tell myDoc to go to page %d\n" +
+                            "end tell", filePath, pageNumber);
+
+            new ProcessBuilder("/usr/bin/osascript", "-e", appleScript).start();
+            return;
+        }
+
+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+        new ProcessBuilder(command).start();

Evidence
Compliance requires PDF opening to support jumping to the first page derived from pages; if the
external-viewer command construction is wrong, the open-and-jump flow can fail entirely. The added
code builds the open command by adding -a  and filePath twice before starting the process.
PDF opening: offer jump-to-first-page based on the entry's pages field
Cross-referenced PDF opening: open parent's attached PDF and jump to child's pages target
jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[57-80]

Agent prompt

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

## Issue description
`OSX.openFileWithApplication` builds the `/usr/bin/open` command by adding the application (`-a <application>`) and `filePath` twice, producing a duplicated argument list.
## Issue Context
This method is used for opening files with a configured application, including the new page-jump behavior. Duplicated args can cause the external open to fail or behave unpredictably.
## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[57-80]

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

3. ~~Evince page-label mismatch~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

NativeDesktop converts logical page numbers to physical page numbers for PDFs, but Linux passes
that (physical) number to evince using --page-label, which targets page labels rather than
physical indices. For PDFs with front-matter/custom labels, this opens the wrong page (or fails to
find the intended label).

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[R118-132]

+    private static void addPdfPageArguments(List<String> command, String application, String filePath, int pageNumber) {
+        if (pageNumber <= 1 || !isPdfPath(filePath)) {
+            return;
+        }
+
+        String executable = Path.of(application).getFileName().toString().toLowerCase(Locale.ROOT);
+        if (executable.contains("evince")) {
+            command.add("--page-label=" + pageNumber);
+        } else if (executable.contains("okular")) {
+            command.add("-p");
+            command.add(String.valueOf(pageNumber));
+        } else if (executable.contains("zathura")) {
+            command.add("-P");
+            command.add(String.valueOf(pageNumber));
+        }

Evidence
NativeDesktop.resolvePageNumberForOpen uses PdfPageLabelResolver which is explicitly defined as
logical→physical conversion. Linux then uses evince’s --page-label= flag, which (by its naming and
usage) expects a label string; passing a physical page number after conversion breaks the mapping
when labels differ from physical order.
jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java[187-203]
jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[118-132]
jablib/src/main/java/org/jabref/logic/pdf/PdfPageLabelResolver.java[20-42]

Agent prompt

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

## Issue description
Linux uses `--page-label` for evince, but the page number is pre-resolved to a *physical* page in `NativeDesktop`. That means evince receives the wrong value when labels != physical indices (exactly the scenario this PR aims to improve).
### Issue Context
- `NativeDesktop.resolvePageNumberForOpen` currently always converts logical→physical for PDFs.
- Linux/evince path uses `--page-label`, which should be fed the logical label, not the physical page.
### Fix Focus Areas
- Move the logical→physical translation decision into the OS/viewer-specific layer (so evince can keep logical labels while okular/zathura can use physical indices), OR
- Keep `NativeDesktop` as-is but change evince invocation to use an argument that targets physical indices (if available in your supported command set).
- jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java[193-203]
- jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[118-142]
- jablib/src/main/java/org/jabref/logic/pdf/PdfPageLabelResolver.java[20-42]

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

View more (17)

4. ~~macOS viewer preference bypass~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

OSX.openFile short-circuits for PDFs with pageNumber>1 and opens via Chrome/Edge or browser URL,
skipping the configured ExternalFileType application entirely. This changes user-visible behavior by
ignoring the preferred PDF viewer even when one is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R29-47]

+    public void openFile(String filePath, String fileType, ExternalApplicationsPreferences externalApplicationsPreferences, int pageNumber) throws IOException {
+        if (isPdf(fileType) && pageNumber > 1) {
+            String fileUrlWithPage = Path.of(filePath).toUri().toString() + "#page=" + pageNumber;
+
+            String chromeBinary = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome";
+            String edgeBinary = "/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge";
+
+            if (Files.exists(Path.of(chromeBinary))) {
+                new ProcessBuilder(chromeBinary, fileUrlWithPage).start();
+                return;
+            }
+            if (Files.exists(Path.of(edgeBinary))) {
+                new ProcessBuilder(edgeBinary, fileUrlWithPage).start();
+                return;
+            }
+
+            NativeDesktop.openBrowser(fileUrlWithPage, externalApplicationsPreferences);
+            return;
+        }

Evidence

The early-return branch for PDFs with pageNumber>1 executes before ExternalFileTypes lookup;
therefore the configured openWithApplication is never consulted for page jumps. The configured
application path is only reached after this early return, making it unreachable for the page-jump
case.

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[28-59]

Agent prompt

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

## Issue description
On macOS, `OSX.openFile(..., pageNumber)` bypasses the user-configured PDF application when `pageNumber > 1`, forcing Chrome/Edge or a browser-based `file://...#page=` open.
### Issue Context
The preference-respecting logic (`ExternalFileTypes.getExternalFileTypeByExt` and `openFileWithApplication`) is currently unreachable in the `pageNumber > 1` PDF case due to an early return.
### Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[28-59]
### Suggested fix approach
1. Resolve the configured `ExternalFileType` first.
2. If an `openWithApplication` is configured, attempt `openFileWithApplication(filePath, application, pageNumber)`.
3. Only fall back to the browser hash jump strategy if no app is configured (or if you explicitly decide the configured app cannot support page jumps).

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

5. openFileWithApplication adds -a twice ✓ Resolved 📎 Requirement gap ≡ Correctness

Description

In OSX.openFileWithApplication, the command list appends -a  and filePath twice, which can
produce an invalid open invocation. This can prevent opening the PDF (and thus page-jump behavior)
when a non-browser, non-Skim application is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R57-80]

+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+
+        if (pageNumber > 1 && appNameLower.contains("skim")) {
+            String appleScript = String.format(
+                    "tell application \"Skim\"\n" +
+                            "  activate\n" +
+                            "  set myDoc to open POSIX file \"%s\"\n" +
+                            "  tell myDoc to go to page %d\n" +
+                            "end tell", filePath, pageNumber);
+
+            new ProcessBuilder("/usr/bin/osascript", "-e", appleScript).start();
+            return;
+        }
+
+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+        new ProcessBuilder(command).start();

Evidence
Compliance requires PDF opening to support jumping to the first page derived from pages; if the
external-viewer command construction is wrong, the open-and-jump flow can fail entirely. The added
code builds the open command by adding -a  and filePath twice before starting the process.
PDF opening: offer jump-to-first-page based on the entry's pages field
Cross-referenced PDF opening: open parent's attached PDF and jump to child's pages target
jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[57-80]

Agent prompt

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

## Issue description
`OSX.openFileWithApplication` builds the `/usr/bin/open` command by adding the application (`-a <application>`) and `filePath` twice, producing a duplicated argument list.
## Issue Context
This method is used for opening files with a configured application, including the new page-jump behavior. Duplicated args can cause the external open to fail or behave unpredictably.
## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[57-80]

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

6. ~~Evince page-label mismatch~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

NativeDesktop converts logical page numbers to physical page numbers for PDFs, but Linux passes
that (physical) number to evince using --page-label, which targets page labels rather than
physical indices. For PDFs with front-matter/custom labels, this opens the wrong page (or fails to
find the intended label).

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[R118-132]

+    private static void addPdfPageArguments(List<String> command, String application, String filePath, int pageNumber) {
+        if (pageNumber <= 1 || !isPdfPath(filePath)) {
+            return;
+        }
+
+        String executable = Path.of(application).getFileName().toString().toLowerCase(Locale.ROOT);
+        if (executable.contains("evince")) {
+            command.add("--page-label=" + pageNumber);
+        } else if (executable.contains("okular")) {
+            command.add("-p");
+            command.add(String.valueOf(pageNumber));
+        } else if (executable.contains("zathura")) {
+            command.add("-P");
+            command.add(String.valueOf(pageNumber));
+        }

Evidence
NativeDesktop.resolvePageNumberForOpen uses PdfPageLabelResolver which is explicitly defined as
logical→physical conversion. Linux then uses evince’s --page-label= flag, which (by its naming and
usage) expects a label string; passing a physical page number after conversion breaks the mapping
when labels differ from physical order.
jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java[187-203]
jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[118-132]
jablib/src/main/java/org/jabref/logic/pdf/PdfPageLabelResolver.java[20-42]

Agent prompt

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

## Issue description
Linux uses `--page-label` for evince, but the page number is pre-resolved to a *physical* page in `NativeDesktop`. That means evince receives the wrong value when labels != physical indices (exactly the scenario this PR aims to improve).
### Issue Context
- `NativeDesktop.resolvePageNumberForOpen` currently always converts logical→physical for PDFs.
- Linux/evince path uses `--page-label`, which should be fed the logical label, not the physical page.
### Fix Focus Areas
- Move the logical→physical translation decision into the OS/viewer-specific layer (so evince can keep logical labels while okular/zathura can use physical indices), OR
- Keep `NativeDesktop` as-is but change evince invocation to use an argument that targets physical indices (if available in your supported command set).
- jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java[193-203]
- jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[118-142]
- jablib/src/main/java/org/jabref/logic/pdf/PdfPageLabelResolver.java[20-42]

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

7. ~~macOS viewer preference bypass~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

OSX.openFile short-circuits for PDFs with pageNumber>1 and opens via Chrome/Edge or browser URL,
skipping the configured ExternalFileType application entirely. This changes user-visible behavior by
ignoring the preferred PDF viewer even when one is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R29-47]

+    public void openFile(String filePath, String fileType, ExternalApplicationsPreferences externalApplicationsPreferences, int pageNumber) throws IOException {
+        if (isPdf(fileType) && pageNumber > 1) {
+            String fileUrlWithPage = Path.of(filePath).toUri().toString() + "#page=" + pageNumber;
+
+            String chromeBinary = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome";
+            String edgeBinary = "/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge";
+
+            if (Files.exists(Path.of(chromeBinary))) {
+                new ProcessBuilder(chromeBinary, fileUrlWithPage).start();
+                return;
+            }
+            if (Files.exists(Path.of(edgeBinary))) {
+                new ProcessBuilder(edgeBinary, fileUrlWithPage).start();
+                return;
+            }
+
+            NativeDesktop.openBrowser(fileUrlWithPage, externalApplicationsPreferences);
+            return;
+        }

Evidence

The early-return branch for PDFs with pageNumber>1 executes before ExternalFileTypes lookup;
therefore the configured openWithApplication is never consulted for page jumps. The configured
application path is only reached after this early return, making it unreachable for the page-jump
case.

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[28-59]

Agent prompt

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

## Issue description
On macOS, `OSX.openFile(..., pageNumber)` bypasses the user-configured PDF application when `pageNumber > 1`, forcing Chrome/Edge or a browser-based `file://...#page=` open.
### Issue Context
The preference-respecting logic (`ExternalFileTypes.getExternalFileTypeByExt` and `openFileWithApplication`) is currently unreachable in the `pageNumber > 1` PDF case due to an early return.
### Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[28-59]
### Suggested fix approach
1. Resolve the configured `ExternalFileType` first.
2. If an `openWithApplication` is configured, attempt `openFileWithApplication(filePath, application, pageNumber)`.
3. Only fall back to the browser hash jump strategy if no app is configured (or if you explicitly decide the configured app cannot support page jumps).

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

8. openFileWithApplication adds -a twice ✓ Resolved 📎 Requirement gap ≡ Correctness

Description

In OSX.openFileWithApplication, the command list appends -a  and filePath twice, which can
produce an invalid open invocation. This can prevent opening the PDF (and thus page-jump behavior)
when a non-browser, non-Skim application is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R57-80]

+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+
+        if (pageNumber > 1 && appNameLower.contains("skim")) {
+            String appleScript = String.format(
+                    "tell application \"Skim\"\n" +
+                            "  activate\n" +
+                            "  set myDoc to open POSIX file \"%s\"\n" +
+                            "  tell myDoc to go to page %d\n" +
+                            "end tell", filePath, pageNumber);
+
+            new ProcessBuilder("/usr/bin/osascript", "-e", appleScript).start();
+            return;
+        }
+
+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+        new ProcessBuilder(command).start();

Evidence
Compliance requires PDF opening to support jumping to the first page derived from pages; if the
external-viewer command construction is wrong, the open-and-jump flow can fail entirely. The added
code builds the open command by adding -a  and filePath twice before starting the process.
PDF opening: offer jump-to-first-page based on the entry's pages field
Cross-referenced PDF opening: open parent's attached PDF and jump to child's pages target
jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[57-80]

Agent prompt

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

## Issue description
`OSX.openFileWithApplication` builds the `/usr/bin/open` command by adding the application (`-a <application>`) and `filePath` twice, producing a duplicated argument list.
## Issue Context
This method is used for opening files with a configured application, including the new page-jump behavior. Duplicated args can cause the external open to fail or behave unpredictably.
## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[57-80]

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

9. ~~Evince page-label mismatch~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

NativeDesktop converts logical page numbers to physical page numbers for PDFs, but Linux passes
that (physical) number to evince using --page-label, which targets page labels rather than
physical indices. For PDFs with front-matter/custom labels, this opens the wrong page (or fails to
find the intended label).

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[R118-132]

+    private static void addPdfPageArguments(List<String> command, String application, String filePath, int pageNumber) {
+        if (pageNumber <= 1 || !isPdfPath(filePath)) {
+            return;
+        }
+
+        String executable = Path.of(application).getFileName().toString().toLowerCase(Locale.ROOT);
+        if (executable.contains("evince")) {
+            command.add("--page-label=" + pageNumber);
+        } else if (executable.contains("okular")) {
+            command.add("-p");
+            command.add(String.valueOf(pageNumber));
+        } else if (executable.contains("zathura")) {
+            command.add("-P");
+            command.add(String.valueOf(pageNumber));
+        }

Evidence
NativeDesktop.resolvePageNumberForOpen uses PdfPageLabelResolver which is explicitly defined as
logical→physical conversion. Linux then uses evince’s --page-label= flag, which (by its naming and
usage) expects a label string; passing a physical page number after conversion breaks the mapping
when labels differ from physical order.
jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java[187-203]
jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[118-132]
jablib/src/main/java/org/jabref/logic/pdf/PdfPageLabelResolver.java[20-42]

Agent prompt

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

## Issue description
Linux uses `--page-label` for evince, but the page number is pre-resolved to a *physical* page in `NativeDesktop`. That means evince receives the wrong value when labels != physical indices (exactly the scenario this PR aims to improve).
### Issue Context
- `NativeDesktop.resolvePageNumberForOpen` currently always converts logical→physical for PDFs.
- Linux/evince path uses `--page-label`, which should be fed the logical label, not the physical page.
### Fix Focus Areas
- Move the logical→physical translation decision into the OS/viewer-specific layer (so evince can keep logical labels while okular/zathura can use physical indices), OR
- Keep `NativeDesktop` as-is but change evince invocation to use an argument that targets physical indices (if available in your supported command set).
- jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java[193-203]
- jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[118-142]
- jablib/src/main/java/org/jabref/logic/pdf/PdfPageLabelResolver.java[20-42]

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

10. ~~macOS viewer preference bypass~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

OSX.openFile short-circuits for PDFs with pageNumber>1 and opens via Chrome/Edge or browser URL,
skipping the configured ExternalFileType application entirely. This changes user-visible behavior by
ignoring the preferred PDF viewer even when one is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R29-47]

+    public void openFile(String filePath, String fileType, ExternalApplicationsPreferences externalApplicationsPreferences, int pageNumber) throws IOException {
+        if (isPdf(fileType) && pageNumber > 1) {
+            String fileUrlWithPage = Path.of(filePath).toUri().toString() + "#page=" + pageNumber;
+
+            String chromeBinary = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome";
+            String edgeBinary = "/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge";
+
+            if (Files.exists(Path.of(chromeBinary))) {
+                new ProcessBuilder(chromeBinary, fileUrlWithPage).start();
+                return;
+            }
+            if (Files.exists(Path.of(edgeBinary))) {
+                new ProcessBuilder(edgeBinary, fileUrlWithPage).start();
+                return;
+            }
+
+            NativeDesktop.openBrowser(fileUrlWithPage, externalApplicationsPreferences);
+            return;
+        }

Evidence

The early-return branch for PDFs with pageNumber>1 executes before ExternalFileTypes lookup;
therefore the configured openWithApplication is never consulted for page jumps. The configured
application path is only reached after this early return, making it unreachable for the page-jump
case.

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[28-59]

Agent prompt

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

## Issue description
On macOS, `OSX.openFile(..., pageNumber)` bypasses the user-configured PDF application when `pageNumber > 1`, forcing Chrome/Edge or a browser-based `file://...#page=` open.
### Issue Context
The preference-respecting logic (`ExternalFileTypes.getExternalFileTypeByExt` and `openFileWithApplication`) is currently unreachable in the `pageNumber > 1` PDF case due to an early return.
### Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[28-59]
### Suggested fix approach
1. Resolve the configured `ExternalFileType` first.
2. If an `openWithApplication` is configured, attempt `openFileWithApplication(filePath, application, pageNumber)`.
3. Only fall back to the browser hash jump strategy if no app is configured (or if you explicitly decide the configured app cannot support page jumps).

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

11. openFileWithApplication adds -a twice ✓ Resolved 📎 Requirement gap ≡ Correctness

Description

In OSX.openFileWithApplication, the command list appends -a  and filePath twice, which can
produce an invalid open invocation. This can prevent opening the PDF (and thus page-jump behavior)
when a non-browser, non-Skim application is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R57-80]

+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+
+        if (pageNumber > 1 && appNameLower.contains("skim")) {
+            String appleScript = String.format(
+                    "tell application \"Skim\"\n" +
+                            "  activate\n" +
+                            "  set myDoc to open POSIX file \"%s\"\n" +
+                            "  tell myDoc to go to page %d\n" +
+                            "end tell", filePath, pageNumber);
+
+            new ProcessBuilder("/usr/bin/osascript", "-e", appleScript).start();
+            return;
+        }
+
+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+        new ProcessBuilder(command).start();

Evidence
Compliance requires PDF opening to support jumping to the first page derived from pages; if the
external-viewer command construction is wrong, the open-and-jump flow can fail entirely. The added
code builds the open command by adding -a  and filePath twice before starting the process.
PDF opening: offer jump-to-first-page based on the entry's pages field
Cross-referenced PDF opening: open parent's attached PDF and jump to child's pages target
jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[57-80]

Agent prompt

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

## Issue description
`OSX.openFileWithApplication` builds the `/usr/bin/open` command by adding the application (`-a <application>`) and `filePath` twice, producing a duplicated argument list.
## Issue Context
This method is used for opening files with a configured application, including the new page-jump behavior. Duplicated args can cause the external open to fail or behave unpredictably.
## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[57-80]

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

12. ~~Evince page-label mismatch~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

NativeDesktop converts logical page numbers to physical page numbers for PDFs, but Linux passes
that (physical) number to evince using --page-label, which targets page labels rather than
physical indices. For PDFs with front-matter/custom labels, this opens the wrong page (or fails to
find the intended label).

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[R118-132]

+    private static void addPdfPageArguments(List<String> command, String application, String filePath, int pageNumber) {
+        if (pageNumber <= 1 || !isPdfPath(filePath)) {
+            return;
+        }
+
+        String executable = Path.of(application).getFileName().toString().toLowerCase(Locale.ROOT);
+        if (executable.contains("evince")) {
+            command.add("--page-label=" + pageNumber);
+        } else if (executable.contains("okular")) {
+            command.add("-p");
+            command.add(String.valueOf(pageNumber));
+        } else if (executable.contains("zathura")) {
+            command.add("-P");
+            command.add(String.valueOf(pageNumber));
+        }

Evidence
NativeDesktop.resolvePageNumberForOpen uses PdfPageLabelResolver which is explicitly defined as
logical→physical conversion. Linux then uses evince’s --page-label= flag, which (by its naming and
usage) expects a label string; passing a physical page number after conversion breaks the mapping
when labels differ from physical order.
jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java[187-203]
jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[118-132]
jablib/src/main/java/org/jabref/logic/pdf/PdfPageLabelResolver.java[20-42]

Agent prompt

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

## Issue description
Linux uses `--page-label` for evince, but the page number is pre-resolved to a *physical* page in `NativeDesktop`. That means evince receives the wrong value when labels != physical indices (exactly the scenario this PR aims to improve).
### Issue Context
- `NativeDesktop.resolvePageNumberForOpen` currently always converts logical→physical for PDFs.
- Linux/evince path uses `--page-label`, which should be fed the logical label, not the physical page.
### Fix Focus Areas
- Move the logical→physical translation decision into the OS/viewer-specific layer (so evince can keep logical labels while okular/zathura can use physical indices), OR
- Keep `NativeDesktop` as-is but change evince invocation to use an argument that targets physical indices (if available in your supported command set).
- jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java[193-203]
- jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[118-142]
- jablib/src/main/java/org/jabref/logic/pdf/PdfPageLabelResolver.java[20-42]

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

13. ~~macOS viewer preference bypass~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

OSX.openFile short-circuits for PDFs with pageNumber>1 and opens via Chrome/Edge or browser URL,
skipping the configured ExternalFileType application entirely. This changes user-visible behavior by
ignoring the preferred PDF viewer even when one is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R29-47]

+    public void openFile(String filePath, String fileType, ExternalApplicationsPreferences externalApplicationsPreferences, int pageNumber) throws IOException {
+        if (isPdf(fileType) && pageNumber > 1) {
+            String fileUrlWithPage = Path.of(filePath).toUri().toString() + "#page=" + pageNumber;
+
+            String chromeBinary = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome";
+            String edgeBinary = "/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge";
+
+            if (Files.exists(Path.of(chromeBinary))) {
+                new ProcessBuilder(chromeBinary, fileUrlWithPage).start();
+                return;
+            }
+            if (Files.exists(Path.of(edgeBinary))) {
+                new ProcessBuilder(edgeBinary, fileUrlWithPage).start();
+                return;
+            }
+
+            NativeDesktop.openBrowser(fileUrlWithPage, externalApplicationsPreferences);
+            return;
+        }

Evidence

The early-return branch for PDFs with pageNumber>1 executes before ExternalFileTypes lookup;
therefore the configured openWithApplication is never consulted for page jumps. The configured
application path is only reached after this early return, making it unreachable for the page-jump
case.

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[28-59]

Agent prompt

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

## Issue description
On macOS, `OSX.openFile(..., pageNumber)` bypasses the user-configured PDF application when `pageNumber > 1`, forcing Chrome/Edge or a browser-based `file://...#page=` open.
### Issue Context
The preference-respecting logic (`ExternalFileTypes.getExternalFileTypeByExt` and `openFileWithApplication`) is currently unreachable in the `pageNumber > 1` PDF case due to an early return.
### Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[28-59]
### Suggested fix approach
1. Resolve the configured `ExternalFileType` first.
2. If an `openWithApplication` is configured, attempt `openFileWithApplication(filePath, application, pageNumber)`.
3. Only fall back to the browser hash jump strategy if no app is configured (or if you explicitly decide the configured app cannot support page jumps).

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

14. openFileWithApplication adds -a twice ✓ Resolved 📎 Requirement gap ≡ Correctness

Description

In OSX.openFileWithApplication, the command list appends -a  and filePath twice, which can
produce an invalid open invocation. This can prevent opening the PDF (and thus page-jump behavior)
when a non-browser, non-Skim application is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R57-80]

+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+
+        if (pageNumber > 1 && appNameLower.contains("skim")) {
+            String appleScript = String.format(
+                    "tell application \"Skim\"\n" +
+                            "  activate\n" +
+                            "  set myDoc to open POSIX file \"%s\"\n" +
+                            "  tell myDoc to go to page %d\n" +
+                            "end tell", filePath, pageNumber);
+
+            new ProcessBuilder("/usr/bin/osascript", "-e", appleScript).start();
+            return;
+        }
+
+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+        new ProcessBuilder(command).start();

Evidence
Compliance requires PDF opening to support jumping to the first page derived from pages; if the
external-viewer command construction is wrong, the open-and-jump flow can fail entirely. The added
code builds the open command by adding -a  and filePath twice before starting the process.
PDF opening: offer jump-to-first-page based on the entry's pages field
Cross-referenced PDF opening: open parent's attached PDF and jump to child's pages target
jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[57-80]

Agent prompt

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

## Issue description
`OSX.openFileWithApplication` builds the `/usr/bin/open` command by adding the application (`-a <application>`) and `filePath` twice, producing a duplicated argument list.
## Issue Context
This method is used for opening files with a configured application, including the new page-jump behavior. Duplicated args can cause the external open to fail or behave unpredictably.
## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[57-80]

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

15. ~~Evince page-label mismatch~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

NativeDesktop converts logical page numbers to physical page numbers for PDFs, but Linux passes
that (physical) number to evince using --page-label, which targets page labels rather than
physical indices. For PDFs with front-matter/custom labels, this opens the wrong page (or fails to
find the intended label).

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[R118-132]

+    private static void addPdfPageArguments(List<String> command, String application, String filePath, int pageNumber) {
+        if (pageNumber <= 1 || !isPdfPath(filePath)) {
+            return;
+        }
+
+        String executable = Path.of(application).getFileName().toString().toLowerCase(Locale.ROOT);
+        if (executable.contains("evince")) {
+            command.add("--page-label=" + pageNumber);
+        } else if (executable.contains("okular")) {
+            command.add("-p");
+            command.add(String.valueOf(pageNumber));
+        } else if (executable.contains("zathura")) {
+            command.add("-P");
+            command.add(String.valueOf(pageNumber));
+        }

Evidence
NativeDesktop.resolvePageNumberForOpen uses PdfPageLabelResolver which is explicitly defined as
logical→physical conversion. Linux then uses evince’s --page-label= flag, which (by its naming and
usage) expects a label string; passing a physical page number after conversion breaks the mapping
when labels differ from physical order.
jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java[187-203]
jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[118-132]
jablib/src/main/java/org/jabref/logic/pdf/PdfPageLabelResolver.java[20-42]

Agent prompt

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

## Issue description
Linux uses `--page-label` for evince, but the page number is pre-resolved to a *physical* page in `NativeDesktop`. That means evince receives the wrong value when labels != physical indices (exactly the scenario this PR aims to improve).
### Issue Context
- `NativeDesktop.resolvePageNumberForOpen` currently always converts logical→physical for PDFs.
- Linux/evince path uses `--page-label`, which should be fed the logical label, not the physical page.
### Fix Focus Areas
- Move the logical→physical translation decision into the OS/viewer-specific layer (so evince can keep logical labels while okular/zathura can use physical indices), OR
- Keep `NativeDesktop` as-is but change evince invocation to use an argument that targets physical indices (if available in your supported command set).
- jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java[193-203]
- jabgui/src/main/java/org/jabref/gui/desktop/os/Linux.java[118-142]
- jablib/src/main/java/org/jabref/logic/pdf/PdfPageLabelResolver.java[20-42]

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

16. ~~macOS viewer preference bypass~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

OSX.openFile short-circuits for PDFs with pageNumber>1 and opens via Chrome/Edge or browser URL,
skipping the configured ExternalFileType application entirely. This changes user-visible behavior by
ignoring the preferred PDF viewer even when one is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R29-47]

+    public void openFile(String filePath, String fileType, ExternalApplicationsPreferences externalApplicationsPreferences, int pageNumber) throws IOException {
+        if (isPdf(fileType) && pageNumber > 1) {
+            String fileUrlWithPage = Path.of(filePath).toUri().toString() + "#page=" + pageNumber;
+
+            String chromeBinary = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome";
+            String edgeBinary = "/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge";
+
+            if (Files.exists(Path.of(chromeBinary))) {
+                new ProcessBuilder(chromeBinary, fileUrlWithPage).start();
+                return;
+            }
+            if (Files.exists(Path.of(edgeBinary))) {
+                new ProcessBuilder(edgeBinary, fileUrlWithPage).start();
+                return;
+            }
+
+            NativeDesktop.openBrowser(fileUrlWithPage, externalApplicationsPreferences);
+            return;
+        }

Evidence

The early-return branch for PDFs with pageNumber>1 executes before ExternalFileTypes lookup;
therefore the configured openWithApplication is never consulted for page jumps. The configured
application path is only reached after this early return, making it unreachable for the page-jump
case.

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[28-59]

Agent prompt

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

## Issue description
On macOS, `OSX.openFile(..., pageNumber)` bypasses the user-configured PDF application when `pageNumber > 1`, forcing Chrome/Edge or a browser-based `file://...#page=` open.
### Issue Context
The preference-respecting logic (`ExternalFileTypes.getExternalFileTypeByExt` and `openFileWithApplication`) is currently unreachable in the `pageNumber > 1` PDF case due to an early return.
### Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[28-59]
### Suggested fix approach
1. Resolve the configured `ExternalFileType` first.
2. If an `openWithApplication` is configured, attempt `openFileWithApplication(filePath, application, pageNumber)`.
3. Only fall back to the browser hash jump strategy if no app is configured (or if you explicitly decide the configured app cannot support page jumps).

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

17. openFileWithApplication adds -a twice ✓ Resolved 📎 Requirement gap ≡ Correctness

Description

In OSX.openFileWithApplication, the command list appends -a  and filePath twice, which can
produce an invalid open invocation. This can prevent opening the PDF (and thus page-jump behavior)
when a non-browser, non-Skim application is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R57-80]

+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+
+        if (pageNumber > 1 && appNameLower.contains("skim")) {
+            String appleScript = String.format(
+                    "tell application \"Skim\"\n" +
+                            "  activate\n" +
+                            "  set myDoc to open POSIX file \"%s\"\n" +
+                            "  tell myDoc to go to page %d\n" +
+                            "end tell", filePath, pageNumber);
+
+            new ProcessBuilder("/usr/bin/osascript", "-e", appleScript).start();
+            return;
+        }
+
+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+        new ProcessBuilder(command).start();

Evidence
Compliance requires PDF opening to support jumping to the first page derived from pages; if the
external-viewer command construction is wrong, the open-and-jump flow can fail entirely. The added
code builds the open command by adding -a  and filePath twice before starting the process.
PDF opening: offer jump-to-first-page based on the entry's pages field
Cross-referenced PDF opening: open parent's attached PDF and jump to child's pages target
jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[57-80]

Agent prompt

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

## Issue description
`OSX.openFileWithApplication` builds the `/usr/bin/open` command by adding the application (`-a <application>`) and `filePath` twice, producing a duplicated argument list.
## Issue Context
This method is used for opening files with a configured application, including the new page-jump behavior. Duplicated args can cause the external open to fail or behave unpredictably.
## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[57-80]

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

18. openFileWithApplication adds -a twice ✓ Resolved 📎 Requirement gap ≡ Correctness

Description

In OSX.openFileWithApplication, the command list appends -a  and filePath twice, which can
produce an invalid open invocation. This can prevent opening the PDF (and thus page-jump behavior)
when a non-browser, non-Skim application is configured.

Code

jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java[R57-80]

+        if (application != null && !application.isEmpty()) {
+            command.add("-a");
+            command.add(application);
+        }
+        command.add(filePath);
+
+        if (pageNumber > 1 && appNameLower.contains("skim")) {
+            String appleScript = String.format(
+                    "tell application \"Skim\"\n" +
+                            "  activate\n" +
...

…21-AC/jabref into fix-8128-crossref-pages

Sherry0121-AC · 2026-04-08T16:19:44Z

Hi @koppor @calixtus , just a gentle ping on this PR as all CI checks are green now. Please let me know if any further changes are required from my side. Thanks for your time!

koppor

For what is this PR? University credits or GSoC?

Siedlerchr · 2026-04-15T08:41:42Z

A lot of slop int his. PR

Sherry0121-AC · 2026-04-15T09:47:16Z

The Windows CI failed in :jablib:test (FileUtilTest.java), but this seems to be an existing flaky test on Windows regarding non-atomic file copying, and is entirely unrelated to my changes in this PR. Could you help trigger a re-run, or should I just ignore it for now?

Sherry0121-AC · 2026-04-15T09:52:13Z

Hi @calixtus and @Siedlerchr ,

First of all, huge apologies for the "slop" and the messy commits!

To give a bit of context: when I ran the test suite locally, a few unrelated tests failed on my machine (mostly due to macOS/Windows environment differences or flaky setups). My initial thought was just to fix them along the way to make the test suite more robust and get a clean local build.

I completely understand now that this was out of scope and made the PR hard to review. I have just reverted all those unrelated test modifications. The PR is now clean and strictly focused only on the original crossref page navigation issue.

Thanks for your patience, and the PR is ready for review again!

subhramit · 2026-04-18T20:46:49Z

Windows tests should pass now.

Sherry0121-AC · 2026-04-19T03:42:40Z

@subhramit Thanks! Yes, the Windows tests are passing perfectly now.

@calixtus @koppor I have updated the code based on your previous review comments, and all CI checks are currently green. Could you please take another look? Please let me know if there are any further issues to address. Thank you!

github-actions · 2026-04-25T04:04:35Z

Your pull request conflicts with the target branch.

Please merge with your code. For a step-by-step guide to resolve merge conflicts, see https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line.

Sherry0121-AC · 2026-04-26T08:53:09Z

Hi @calixtus @koppor @subhramit @Siedlerchr , the merge conflicts have been resolved and all checks are green. Are there any further issues to address, or is this ready to be merged? Thanks!

subhramit · 2026-05-07T14:59:04Z

Hi <...> , the merge conflicts have been resolved and all checks are green. Are there any further issues to address, or is this ready to be merged? Thanks!

We'll take a look soon. Currently we are a bit busy with other commitments.

…21-AC/jabref into fix-8128-crossref-pages

Sherry0121-AC added 3 commits April 7, 2026 18:46

Fix: Comprehensive page navigation for crossref entries in both inter…

cd48dee

…nal and external viewers (JabRef#8128)

Test: Add unit tests for crossref page resolution and navigation logic

7046ca5

Changelog: Add entry for JabRef#8128

46d5205

github-actions Bot added good third issue component: ui component: import-load component: external-files labels Apr 7, 2026

qodo-free-for-open-source-projects Bot reviewed Apr 7, 2026

View reviewed changes

Comment thread jabgui/src/main/java/org/jabref/gui/desktop/os/OSX.java Outdated

github-actions Bot added the status: changes-required Pull requests that are not yet complete label Apr 7, 2026

github-actions Bot mentioned this pull request Apr 7, 2026

Support for multi-paper PDFs (AKA proceedings) #8128

Open

4 tasks

Sherry0121-AC added 3 commits April 7, 2026 21:56

Fix format, checkstyle, and module dependencies

f605552

respect macOS user app preferences and fix checkstyle/module issues

78a4e52

Fix: respect macOS app preferences and refine code style

969f699

Sherry0121-AC force-pushed the fix-8128-crossref-pages branch from fe94d90 to 969f699 Compare April 7, 2026 16:10

Sherry0121-AC added 8 commits April 8, 2026 00:13

Chore: trigger CI to clear force push warning

4edd3a9

Fix: correct indentation and remove unnecessary pdfbox requirement

d98ebdd

Merge branch 'main' into fix-8128-crossref-pages

65c4c5a

Refactor: Address Qodo review suggestions

6d569f9

Merge branch 'fix-8128-crossref-pages' of https://github.com/Sherry01…

703d39b

…21-AC/jabref into fix-8128-crossref-pages

Merge branch 'main' into fix-8128-crossref-pages

65a0a8e

modefied test

a45bdee

Merge branch 'fix-8128-crossref-pages' of https://github.com/Sherry01…

e3d96f7

…21-AC/jabref into fix-8128-crossref-pages

github-actions Bot added status: no-bot-comments and removed status: changes-required Pull requests that are not yet complete labels Apr 8, 2026

Sherry0121-AC added 2 commits April 8, 2026 23:53

Fix: Correct module directives for pdfbox in jabgui

ba05997

Merge branch 'main' into fix-8128-crossref-pages

bffe519

koppor requested changes Apr 10, 2026

View reviewed changes

Comment thread bug.txt Outdated

Comment thread jabgui/src/main/java/org/jabref/gui/desktop/os/NativeDesktop.java Outdated

calixtus reviewed Apr 15, 2026

View reviewed changes

Comment thread jablib/src/main/java/org/jabref/logic/ai/models/OpenAiCompatibleModelProvider.java

Sherry0121-AC added 2 commits April 15, 2026 17:12

reverting ALL unrelated files

ee1ca19

Merge branch 'main' into fix-8128-crossref-pages

163ca84

Sherry0121-AC requested a review from calixtus April 15, 2026 09:52

Sherry0121-AC and others added 2 commits April 15, 2026 21:37

revert unrelated test changes

374afe0

Merge branch 'main' into fix-8128-crossref-pages

91d06e2

Merge branch 'main' into fix-8128-crossref-pages

d7cdbb7

Merge branch 'main' into fix-8128-crossref-pages

99e6b9b

github-actions Bot added status: changes-required Pull requests that are not yet complete and removed status: no-bot-comments labels Apr 25, 2026

Merge branch 'main' into fix-8128-crossref-pages

657c429

github-actions Bot added status: no-bot-comments and removed status: changes-required Pull requests that are not yet complete labels Apr 26, 2026

Merge branch 'main' into fix-8128-crossref-pages

61ff59d

github-actions Bot added status: changes-required Pull requests that are not yet complete and removed status: no-bot-comments labels May 5, 2026

Merge branch 'main' into fix-8128-crossref-pages

f73dace

Sherry0121-AC added 3 commits May 7, 2026 23:16

clean

6150171

Merge branch 'fix-8128-crossref-pages' of https://github.com/Sherry01…

bcb7e0f

…21-AC/jabref into fix-8128-crossref-pages

Fix errors

d80cd80

github-actions Bot added status: no-bot-comments and removed status: changes-required Pull requests that are not yet complete labels May 7, 2026

Uh oh!

Conversation

Sherry0121-AC commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Related issues and pull requests

PR Description

Steps to test

Known Limitations

Checklist

Uh oh!

qodo-free-for-open-source-projects Bot commented Apr 7, 2026

Review Summary by Qodo

Walkthroughs

File Changes

Uh oh!

qodo-free-for-open-source-projects Bot commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

Sherry0121-AC commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

koppor left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Siedlerchr commented Apr 15, 2026

Uh oh!

Sherry0121-AC commented Apr 15, 2026

Uh oh!

Sherry0121-AC commented Apr 15, 2026

Uh oh!

subhramit commented Apr 18, 2026

Uh oh!

Sherry0121-AC commented Apr 19, 2026

Uh oh!

github-actions Bot commented Apr 25, 2026

Uh oh!

Sherry0121-AC commented Apr 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

subhramit commented May 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Sherry0121-AC commented Apr 7, 2026 •

edited

Loading

qodo-free-for-open-source-projects Bot commented Apr 7, 2026 •

edited

Loading

Sherry0121-AC commented Apr 8, 2026 •

edited

Loading

Sherry0121-AC commented Apr 26, 2026 •

edited

Loading