Affected versions

• Nightly 79.0a1

Unaffected versions

• Firefox 78.0 Release Candidate

Affected platforms

• MacOS 10.15
• Windows 10 64bit
• Windows 7 64bit

Steps to reproduce

1. Start Firefox
2. Open a sample pdf in urlbar (eg: http://www.africau.edu/images/default/sample.pdf)
3. Click the download button and save the file
4. Open Download panel and use the following operation on the downloaded pdf: CTRL(CMD)+Shift+left click
5. Focus the second tab (opened in the correct place)
6. Repeat step 5 again.

Expected result

• The downloaded pdf is opened in a new tab, at the end of the tab strip (last from the right, if using LTR build and the other way around for RTL build)

Actual result

• The downloaded pdf is opened

Regression range

• This is not a regression since the key combination was introduced in bug 1638156 and the build with that patch also has this issue.

Additional notes

• If after step 7 from above STR some random webpages (until overflow tabs) are opened and the last one focused, following step 5 again will open a tab containing the pdf at the far left side of the tabs (worse for users which have dozens of tabs).
• IMHO this bug falls in severity S3 category.

probably in the tabshifted case we should set relatedToCurrent: true here
https://searchfox.org/mozilla-central/rev/21f2b48e01f2e14a94e8d39a665b56fcc08ecbdb/toolkit/components/downloads/DownloadUIHelper.jsm#129-134
Sam, wdyt?

Thanks for filing and the STR :bogdan_maris, I can reproduce this now.

(In reply to Marco Bonardo [:mak] from comment #1)

probably in the tabshifted case we should set relatedToCurrent: true here
https://searchfox.org/mozilla-central/rev/21f2b48e01f2e14a94e8d39a665b56fcc08ecbdb/toolkit/components/downloads/DownloadUIHelper.jsm#129-134

Yeah I'll give that a go, thanks for the pointer.

I think I've tracked down what is going on here, but not why or what is necessary to fix it. The short version is that in step 5 of the STR, selecting the tab clears out the gBrowser._lastRelatedTabMap so we no longer have the association between the new PDF tab and the tab we used to open it. So, when we repeat the steps, the opener-tab returns to being the tab used to create the download, and the new tab is created to its right.

1. Download a PDF from any document and keep that tab open.
2. Then, using the download panel, open the downloaded PDF. (At this point it doesnt matter if you use key modifiers.) Break in the debugger at https://searchfox.org/mozilla-central/source/browser/base/content/tabbrowser.js#3068, and confirm openerTab is the tab from step 1.
3. Step through to https://searchfox.org/mozilla-central/source/browser/base/content/tabbrowser.js#3084 where we add this newly created tab to a WeakMap which associates it with the openerTab.
   • This is what should prevent this current bug; when we again open the PDF from the download panel, lastRelatedTab should be this newly created tab, so we should get the correct index.
   • Confirm that gBrowser._lastRelatedTabMap now has an entry.
4. Next, break at in updateCurrentBrowser at https://searchfox.org/mozilla-central/source/browser/base/content/tabbrowser.js#1007, where the _lastRelatedTabMap entries are lost as we assign a new empty WeakMap.
5. Replaying the steps from step 2 results in lastRelatedTab being undefined, so previousTab is our original openerTab from step 1

So, maybe I'm missing something, or is this behavior is by design?

I'm also a bit confused and unsure about the expected behavior.
The worst part seems that adding many tabs and then ctrl+shift+clicking keeps opening very far on the other side of the tab strip, because it opens just after the originating tab. Though it's so edge case that I'm not sure it's worth doing anything... Lowering priority and marking as blocked-ux since I'm not sure what's the right behavior.

I agree on the lower severity and priority. And there's a risk that fixing this specific issue might well break some other workflow.
I'll unassign myself for now until we have clearer next steps.