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 Marco and me aren't sure off-hand precisely why the selection is being lost...
Bug 1695383 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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...