As far as I know this has never worked. See T6700. This is likely a duplicate on how we listen to clicks on all menus.

Almost certain it did. Updated last night and one of my users called this out first thing in the morning. Not sure exactly which version I updated from, but my database dump from the previous update was timestamped phab.20150407_034445Z.sql.gz

Do you all use the durable conpherence column perchance? (Hit "\" to check it out if you have no idea what I am talking about.)

It could be a gnarly interaction with Quicksand, some javascript infrastructure powering the durable column.

We've messed with a bit but do not actively use it. The ctrl-click and middle-click on notifications don't seem to work on secure.phab either (unless you're implying that maybe quicksand made them work?)

I was just guessing at a possible cause, especially as I am working to get Quicksand in a better state. Its only in play if the durable column is open. Basically, don't mind me. :D

The plot thickens...

Doesn't seem to be consistent. Sometimes middle-click causes navigvation within same page, sometimes it seems like a no-op.

I was trying on secure and on local install, and I could swear that once middle-clicking a notification on my local install navigated to a page that I had just visited on secure. Can't seem to repeat this though, so maybe I'm just crazy.

I wanted to test it and... Clicking Links in notifications work flawlessly regardless of durable column. Clicking notifications themselves opens in same tab regardless of durable colum state.

So - I assume that @chad is right abut this one.

Event listeners do, generally speaking, respect middle and right clicks. This isn't a case of event listeners just being too ambitious.

In these menus, the container is a <div />, not an <a />. If we didn't run any javascript, the click would just do nothing. We aren't capturing and discarding an otherwise perfectly good click because of sloppy event filtering.

These containers can both contain <a /> elements, which aren't valid inside an <a /> even in HTML5, which is why the containers are <div /> instead of <a />. We can possibly either add some sort of floating invisible <a /> under them to solve this in CSS/HTML, or implement additional behaviors in JS to simulate link clicks.

In T7897#108576, @epriestley wrote:

These containers can both contain <a /> elements, which aren't valid inside an <a /> even in HTML5, which is why the containers are <div /> instead of <a />. We can possibly either add some sort of floating invisible <a /> under them to solve this in CSS/HTML, or implement additional behaviors in JS to simulate link clicks.

You might very well not want to do this for philosophical reasons, but it is entirely possible to nest <a /> elements if you build the DOM with JavaScript (or if you use an XHTML doctype). All browsers back to IE 6 allow it and treat it sanely. MediaWiki's Echo extension (notifications) does this as a simple lazy solution to the same problem.