please revert all the unrelated formatting changes throughout the PR.
Also, you can run the respective tests locally to check if they are passing (unit, openrewrite, etc) instead of pushing dummy commits for triggering ci. This causes unnecessary noise to those subscribed to the PR.

Hey, can you explain what the crux of Suppression as a class is? How exactly did you think of this as a solution?
And what does suppressionDepth convey, in simple terms?

It is evident that it works, but we need to brainstorm and ensure that there was no better way to achieve the same thing before going forward with this.

Did you try the two or three solution hints given in the issue? What problems did you face when implementing them?

hello @subhramit,
thank you for responding and for the questions.

The main crux of Suppression is that during a bulk import it increases suppressionDepth, which prevents entries from being added to the navigation history. I initially used a boolean flag, but switched to a depth-based approach because a boolean can fail in nested scenarios. For example, if importFile1() internally calls importFile2(), the boolean would be reset after importFile2() finishes, while importFile1() is still running.

As for the other approaches:

Clearing the imported entries afterward felt fragile — for example, if the import crashes midway, adding and then removing entries doesn't make sense .

Disabling auto-selection would break the existing behavior of showing the last imported entry.

Given these trade-offs, disabling history updates during bulk import felt like the most robust option. The main challenge I faced was deciding where this suppression should live architecturally , I implemented it as a runWithHistorySuppression() wrapper method in LibraryTab that bulk operation callers use like import handler , drag and drop .
i am open for making any changes and improving this further , if there’s a cleaner direction

For example, if importFile1() internally calls importFile2(), the boolean would be reset after importFile2() finishes, while importFile1() is still running.

Have you found any concrete examples of that happening in the code?
And if there is, wouldn't switching the boolean flag only at the level of the outermost import call solve it? That is, tracking only the completion of importFile1()?

where this suppression should live architecturally

History should not suppressed completely, it should "just" be collected into one NamedCompound.

Read on at https://apidia.net/java/OpenJDK/25/?pck=javax.swing.undo&cls=.CompoundEdit for nested undos/redos.

#14686

Maybe, I mixed it up - this PR is about navigation; I thought, it has a strong relation to undo/redo.

For example, if importFile1() internally calls importFile2(), the boolean would be reset after importFile2() finishes, while importFile1() is still running.

Have you found any concrete examples of that happening in the code? And if there is, wouldn't switching the boolean flag only at the level of the outermost import call solve it? That is, tracking only the completion of importFile1()?

I checked this and you’re right @subhramit — in ImportHandler, imports are performed in a loop, not in a recursive way.

switching the flag only at the outermost level works. A nesting-aware boolean like this would be enough:

boolean wasAlreadySuppressed = suppressNavigation;
suppressNavigation = true;
try {
    action.run();
} finally {
    if (!wasAlreadySuppressed) {
        suppressNavigation = false;
    }
}

This handles cases where multiple import batches might run sequentially - suppression stays on until all batches complete.

I went with the counter mostly as a defensive choice, but I agree the boolean is simpler and does the job here. Happy to switch to that if you prefer.

Please go ahead with it, let us know if you face issues.

sure on it !!

This comment is confusing - so selection happens in case of both single and multiple entries?
Where is the code for "leaving all entries selected"? Because it will neither trigger the if nor else case.

The side effect of this can be - check if earlier on bulk import all entries were actually selected, because otherwise now if they are not selected, lets say the user wants to remove all the entries imported just after the import action, they will have to manually select the imported entries again first instead of just clicking delete,

You’re right — my bad. I forgot to update the comment. I’ll fix it to accurately describe skipping clearAndSelect() for bulk imports.

check if earlier on bulk import all entries were actually selected, because otherwise now if they are not selected, lets say the user wants to remove all the entries imported just after the import action, they will have to manually select the imported entries again first instead of just clicking delete,

i checked this ,on bulk import all the entries were not selected , only the first entry was selected from the bulk import

You’re right — my bad. I forgot to update the comment. I’ll fix it to accurately describe skipping clearAndSelect() for bulk imports.

This is a final heads up to not use AI to communicate. You will be blacklisted from the project if you don't respect our guidelines on using AI.

@subhramit i used ai to refine my speech so i can communicate better , but from going forward i will be writing directly here .