Ctrl+clicking a notification closes the notifications menu


#1

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


#4

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.


#6

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.


#8

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?


#10

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