[Bug]: Collapse all items on inital Document Outline

[a2zaustin]

Is the feature relevant to the Firefox PDF Viewer?

Yes

Feature description

Currently when the document outline is opened it is completely expanded so I manually close everything so my navigation can be cleaner. My suggested change would be, upon initial navigation to the document outline all items should be collapsed by default.

I have not labelled this as a bug, as I am not sure but I am on the following:

OS: Windows 11 Home
OS Version: 10.0.26200

Firefox Version: 146.0
Default PDF viewer

Other PDF viewers

No response

[a2zaustin]

Working Example:
rust-design-patterns.pdf

Failing Example:
CPlusPlusNotesForProfessionals.pdf

Since I was able to find a working example I am going to mark this as a bug instead.

[a2zaustin]

Steps to reproduce the problem:

1. Open in PDF viewer.
2. Navigate to document outline.

What is the expected behavior?

The outline should be collapsed completely.

What went wrong?

Everything is currently expanded by default.

[Riya-chandra]

Hi @timvandermeij,
I'd like to work on this issue, which also addresses the long-standing #7713.
After reviewing the codebase, I plan to modify the PDFOutlineViewer class in web/pdf_outline_viewer.js. Specifically, I'll locate the initialization logic that sets the default expansion behavior (likely in the constructor or _addToggleButton method) and change it to collapse all outline items initially. This will involve setting the appropriate CSS classes (treeItem elements should have the collapsed state by default) and ensuring the _setOpen method correctly handles the initial state. The existing toggle functionality through _bindLink will remain intact, allowing users to expand items on demand. I'll also check if there's a configuration parameter like this.maxExpandLevel or similar that controls the default expansion depth and set it to 0.
For testing, I'll verify the behavior with PDFs containing various outline structures (single-level, deeply nested, and no outline), run npx gulp unittest and npx gulp integrationtest, and test across different browsers to ensure consistency. If you have any specific implementation preferences or know the exact property/method I should modify, please let me know.
I'm ready to start immediately if you'd like to assign this to me. Thanks!

[BellYun]

Hi @timvandermeij, @Riya-chandra, and @a2zaustin,

I've been analyzing the code to contribute to this issue, and I'd like to share some findings regarding the root cause and propose a solution that balances user experience with spec compliance.

1. Root Cause Analysis (PDF Specification)

@a2zaustin, the difference you observed between the "Working Example" and "Failing Example" is actually due to internal properties set by the PDF authors, strictly followed by the PDF specification.

According to ISO 32000-1:2008, specifically Section 12.3.3 (Outline Items), Table 153 (Page 368), the Count entry determines the initial state:

Count: "If the entry is negative, the item is closed [...]. If the entry is positive, the item is open."

• Failing Example (CPlusPlus...pdf): Likely has a positive Count, instructing the viewer to expand it by default.
• Working Example (rust...pdf): Likely has a negative Count, instructing the viewer to collapse it.

Currently, web/pdf_outline_viewer.js respects these spec-defined values correctly.

2. Proposal

If we simply enforce hidden = true in the code, we would be breaking spec compliance by ignoring the document author's explicit settings. To resolve @a2zaustin's pain point without violating the spec, I propose two possible solutions:

Option A: User Preference (Recommended)
Implement a User Preference (e.g., "Always collapse outline on load").

• Pros: Users can override the document's default behavior globally.
• Cons: Requires adding a new setting to AppOptions.

Option B: UI Improvement ("Collapse All" Button)
Add a "Collapse All / Expand All" button (or context menu item) in the outline sidebar header.

• Pros: Allows users to instantly clean up the view on demand (manual control) while keeping the initial state spec-compliant.
• Cons: Requires UI changes in the sidebar.

Conclusion

I believe Option A (User Preference) might be the most robust solution for this specific request, but Option B is also a great UX enhancement.

I am happy to help implement either of these solutions. @timvandermeij, which direction do you think is best for the project?