Hmm, it looks like this was actually something semi-accidentally fixed by the changes in bug 1531289. The code to open a document with a middle-click doesn't actually go through the usual window opening machinery, instead it bounces out to chrome JS, which calls through tabbrowser to open the link in a specific location: (https://searchfox.org/mozilla-central/rev/8d722de75886d6bffc116772a1db8854e34ee6a7/browser/actors/ClickHandlerParent.jsm#117)
Because this goes through the parent process, not native window.open code, it never establishes either an opener or cross-group opener relationship between the original tab and the newly created one, so when the window closing logic looks for an opener window to parent the dialog to, it fails.
In the original approach we took in bug 1531289, the "fix" to the noopener window situation was to try to re-parent the dialog to the parent chrome window when the tab is going to be closed if no opener could be found. This unfortunately caused bug 1656753, as we'd immediately close that chrome window if a pop-up was created, and no dialog would be shown. To fix that I partially reverted back to the old
opener based behaviour, and added a new
CrossGroupOpener which would track the "opener" even in the case where a
noopener flag prevents one from existing. This avoided the issue where we would target the dialog to a doomed parent window.
Unfortunately the context menu and click handler code doesn't currently communicate this relationship to platform code, so we do not attempt to close the newly created tab, as we don't know who to parent the potential download dialog to. If we want to also close downloads started with "right click -> open in new window" (or middle-click with opening in a pop-up supported), we'll probably need frontend to identify the cross-group opener window for us, but we can perhaps "fix" it in the new-tab case by asking nsIDocShellTreeOwner for the current tab count, and reparenting to the chrome window if it is over 1, sorta like we did before bug 1656753.
How tricky would it be to start tracking that context through frontend? It seems like it might be good to be explicit about these relationships so we don't show download dialogs in front of the wrong window if the tab is opened some other way (e.g. from extensions?).