User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

1.Open Firefox Nighty
2.Download Anything from web
3.open download button from toolbar
4. right click and choose copy download link

Actual results:

Nothing is copied

Expected results:

The file download link must be copied

The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Hi Fros

I tried to replicate this on windows10 64 bit and also on Ubuntu 20 64 bit with latest Firefox nightly version 88.0a1

for example on windows i went to this site: https://www.winzip.com/win/en/landing/prodpagewz.html?gclid=EAIaIQobChMI8viove2P7wIVytSzCh3Ymw1eEAAYASAAEgJU5PD_BwE

downloaded winzip, and clicked the download button on the toolbar, right click and copy download link and this is what got copied:
copied https://download.winzip.com/gl/gad/winzip25.exe

Is there any specific link you ca provide that does not work?
can you test again with the latest version of firefox? and with a new profile?

thanks.

(In reply to Pablo from comment #2)

Hi Fros

I tried to replicate this on windows10 64 bit and also on Ubuntu 20 64 bit with latest Firefox nightly version 88.0a1

for example on windows i went to this site: https://www.winzip.com/win/en/landing/prodpagewz.html?gclid=EAIaIQobChMI8viove2P7wIVytSzCh3Ymw1eEAAYASAAEgJU5PD_BwE

downloaded winzip, and clicked the download button on the toolbar, right click and copy download link and this is what got copied:
copied https://download.winzip.com/gl/gad/winzip25.exe

Is there any specific link you ca provide that does not work?
can you test again with the latest version of firefox? and with a new profile?

thanks.

Hi Pablo,
My Specs-
Browser - firefox nighty 88.0.a1
Updated - (2021-03-01)
OS- windows 10 64 bit
Here what i found after recreating new profile and tested you winzip link.I enabled the proton in previous one and suspected that browser.proton.contextmenus.enabled cause this problem.
Anyway To reproduce issue:
Before do anything above follow below steps:
1.type about:config in urlbar
2.agree warning then type and enable the below commands:
---->browser.proton.contextmenus.enabled
---->proton
---->browser.proton.enabled
3. If step 2 failed In my browser these configs are also enabled so you can try if above contextmenu.enabled not work
---->browser.proton.appmenu.enabled
---->browser.proton.tabs.enabled
---->browser.proton.toolbar.version
---->browser.proton.urlbar.enabled

3.Now repeat all steps above to recreate situation.

I was able to replicate the issue with Windows10 64bit. (It works fine on MacOs10.15 and Ubuntu 20 64.bit)
Reproduceed on Firefox beta 87.0b5 and Firefox nightly 88.0a1

1. created a user.js with
   user_pref("browser.proton.contextmenus.enabled", true);
   user_pref("browser.proton.enabled", true);

2. Downloaded any file like this program https://www.winzip.com/win/en/landing/prodpagewz.html?gclid=EAIaIQobChMI8viove2P7wIVytSzCh3Ymw1eEAAYASAAEgJU5PD_BwE

3. opened the download menu, right click and copied download link.

the .exe link did not get copied.

This is broken because the downloads panel keeps track of selection based on mouse hover state, and the new context menu's big box shadow area is eating mouse events, which means that when the context menu opens, the hovered item in the downloads panel is no longer hovered, which means it is no longer selected, which means that when executing any of the commands in the menu, they don't work because the downloads panel does not know which item is selected.

Fixing bug 1692084 would likely fix this. We could also fix it orthogonally by changing the downloads view to "fixate" selection on the context menu'd item when opening the context menu, and then "release" the selection back to the mouse hover / keyboard behaviour when the context menu closes. In fact, this last thing is already what the code is trying to do, but it's not working -- Marco and me aren't sure off-hand precisely why the selection is being lost...

Fixed by bug 1699427.

Reproduced the initial issue using old Nightly from 2021-02-26, verified that all labels from download context menus work as expected in latest Nightly 88.0a1.