Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closing tabs jumps to first rather than next tab #58

Open
buethastum opened this issue Apr 8, 2020 · 4 comments · May be fixed by #502
Open

Closing tabs jumps to first rather than next tab #58

buethastum opened this issue Apr 8, 2020 · 4 comments · May be fixed by #502
Labels
help wanted Extra attention is needed

Comments

@buethastum
Copy link

Hi

Thanks for a nice and useful plugin. A minor bug (or maybe a feature request): When closing a tab after having opened a bunch, with link-fixer activated Firefox jumps back to the tab from which I've opened the other tabs, rather than to the next tab in line as is the normal behavior with the add-on activated. Would be nice to have that behavior with link-fixer on as well.

Regards,
Bue

@danielnixon
Copy link
Owner

Thanks @buethastum. I don't have time to work on this right now but PRs always welcome.

@danielnixon danielnixon added the help wanted Extra attention is needed label Jun 10, 2020
@jcaruso
Copy link

jcaruso commented Jul 25, 2022

I ran into this bug as well, reproduced it on both MacOS and Windows, and tracked down the cause. The problem is the openerTabId: sender.tab && sender.tab.id clause in the chrome.tabs.create() call in background-script.js; removing this clause fixes the problem. Apparently setting openerTabId causes all tabs that are opened to return to the originating tab when they're closed rather than returning to the next most-recently opened tab (as happens when you use vanilla Firefox without the extension).

I don't have enough familiarity with the relevant APIs to know why this clause was included or what side effects removing it might have (though I haven't run into any problems in my own testing), so I won't do a PR, but as I say the fix is extremely simple. I've included a patch below, and please feel free to roll a change like this into the official extension if you believe it won't cause any problems.

Thanks for the great extension!

diff --git a/background-script.js b/background-script.js
index a9b19fe..874317b 100644
--- a/background-script.js
+++ b/background-script.js
@@ -179,7 +179,7 @@ chrome.runtime.getPlatformInfo((info) => {
                   chrome.tabs.create({
                     url: message.url,
                     active: active,
-                    openerTabId: sender.tab && sender.tab.id,
+//                    openerTabId: sender.tab && sender.tab.id,
                     index: newTabIndex,
                   });
                 });

@jcaruso
Copy link

jcaruso commented Jul 25, 2022

By the way, these are the steps to reproduce the bug:

  1. Open a web page (aka tab 1)
  2. Open two tabs (tabs 2 and 3) from tab 1 using ctrl-click or cmd-click
  3. Navigate to tab 3 via keyboard or mouse
  4. Close tab 3. The focus will move back to tab 1 rather than to tab 2 (and note that it doesn't matter if you navigated through tab 2 to get to tab 3 in the previous step -- the focus will still return to tab 1).

If you disable the link-fixer extension and repeat this test, the focus will move to tab 2 in step 4.

This bug only occurs with Firefox, by the way -- link-fixer for Chrome appears to work as expected.

@zznidar
Copy link

zznidar commented Aug 20, 2023

After some quick testing, it seems that passing undefined instead of an actual tab index to the chrome.tabs.create (

index: newTabIndex,
) works as expected for me in Firefox 116.0.2 on Windows (same behaviour with addon and without addon).

Same result occurs if the index key is not passed at all.

If this is only an issue on Firefox, we might leave the old newTabIndex for Chrome users and set it to undefined in Firefox.

zznidar added a commit to zznidar/link-fixer that referenced this issue Aug 20, 2023
@zznidar zznidar linked a pull request Aug 20, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants