Ctrl+clicking a notification closes the notifications menu


A few days ago the bug where middle-clicking a notification would close the notifications menu was solved. I can no longer find that topic to drop a link to it. No matter.

This is a variation of the same bug: left-clicking a link while holding Ctrl should also open a new background tab and not close the notifications menu.

This is particularly important for touchpad users (yes, there are still a few of us; and no, pressing both touchpad buttons doesn’t always work).

(Alan Tan) #2

I’ll look into the fix for this.

(Alan Tan) #3

Will probably have to cover cmd + click and all other variants of opening in a new tab/window


I’ve thought about what the behaviour should be when opening a new window (shift-clicking), but I’m not so sure about that case since you are opening a new foreground page.

Giving it some more thought, I think for consistency with opening via the context menu I’d leave the notifications menu open in that case also.

(Alan Tan) #5

Fixed in FIX: Let users open header links in new tab without dismissing dropdown. · discourse/discourse@5be258d · GitHub.


Why is the condition («modifier held» || e.which === 2)?

Won’t that break the middle mouse button again?

(Alan Tan) #7

That conditions translates to if ctrl || CMD || shift || middle click is pressed, do not hide the dropdown.


Ok. I thought which == 2 was the right button. I should have asked whether this won’t break the context menu then.

(Alan Tan) #9

:smiley_cat: Context menu?


When you right-click. Won’t that trigger click with e.which === 3 and fail that condition?

I ask without being sure.

(Alan Tan) #11

From what I know, right click doesn’t trigger a click event. This might help to explain it.

(Alan Tan) #12

This bug has been fixed. :smiley_cat:

(Jeff Atwood) #13