Why SharePoint Modern Pages Break the Middle-Click: A Developer’s Deep Dive into This Frustrating Design Choice

1,945 words, 10 minutes read time.

When middle-click betrays you: the SharePoint Modern experience every developer dreads.

There’s a reason the middle mouse button is practically sacred ground for developers. Whether you’re a seasoned backend engineer, a front-end specialist, or a SharePoint guy living neck-deep in document libraries, that middle-click is like a secret handshake. It opens new tabs, lets you multi-task, keep your mental stack organized, and chase down rabbit holes without losing your place. It’s the digital equivalent of putting bookmarks in five chapters at once while writing your own novel.

So imagine the frustration when a platform we use every day—like SharePoint Modern Pages—decides to rewrite the rules. Suddenly, that trusty middle-click doesn’t open a page in a new tab anymore. Instead, it brings up a scroll icon, or worse, does absolutely nothing. As a developer who’s neck-deep in SharePoint for building intranets, corporate portals, and digital workspaces, this seemingly tiny shift feels like the UI equivalent of someone swapping your wrench for a banana.

In this deep dive, we’re going to unpack why SharePoint Modern Pages break the default browser behavior you and I grew up on, why it’s more than just an annoyance, and what we might do about it. Along the way, we’ll nerd out over JavaScript event handling, explore some real developer war stories, and hopefully come away with a few laughs (and maybe fewer hair-pulls).

The Classic Behavior: Why Middle-Click is Practically Muscle Memory

Think back to your first time realizing that you could middle-click a link. For most of us, it was like stumbling onto a cheat code for the web. On Chrome, Firefox, Edge—pretty much any mainstream browser—the middle mouse button is your passport to multitasking. It quietly spawns a new tab in the background, letting you keep your current context while teeing up new adventures.

This is fundamental stuff. It’s built into the way browser engines like Chromium and Gecko implement the DOM’s default actions for click events. The browser assumes: if it’s a link (<a href="...">), a middle-click means “open this somewhere else so you don’t blow up your current work.” That default is so ingrained it’s almost subconscious. I’d wager most developers hit middle-click as often as they breathe.

So when something breaks that expectation—when middle-click suddenly fails to open a new tab—it’s not just a UI quirk. It’s a direct hit to our flow, the mental rhythm we rely on to juggle dozens of tabs, terminal sessions, and Stack Overflow threads.

Enter SharePoint Modern Pages: New Tech, New Trade-offs

Now let’s step into the world of SharePoint. Microsoft’s behemoth of a platform has been the backbone of countless enterprise intranets for two decades. Originally, SharePoint sites were rendered largely server-side, with classic pages sending back full HTML payloads. Middle-click worked flawlessly because it was the browser, not SharePoint, managing those link behaviors.

But then came the modern era. Starting around 2016, Microsoft began a massive overhaul. They rolled out SharePoint Modern Pages—shiny, responsive, JavaScript-heavy constructs powered by frameworks like React, orchestrated via the SharePoint Framework (SPFx). Instead of reloading entire pages, they started routing content dynamically on the client side. It’s faster, more fluid, easier to theme, and plays nicely with the broader Microsoft 365 ecosystem.

Sounds great, right? And it is—mostly. But here’s the catch: when you move navigation to the client side, you inevitably take on responsibility for handling what would normally be default browser behavior. Suddenly it’s up to JavaScript, not the browser, to decide what a click does. And more often than not, that means middle-click gets the short end of the stick.

The JavaScript Culprit: How SharePoint Hijacks Your Clicks

Let’s dig into the technical guts. In modern SharePoint sites, when you click on a link to another page—say, a Site Page inside a Hero web part or a custom Quick Links block—JavaScript intercepts that event. The routing framework looks at the click, calls preventDefault() to stop the browser from doing what it normally would, and then updates the page content via client-side APIs. This is how SharePoint achieves snappy transitions without full page reloads.

But the problem is, these interceptors often don’t check which mouse button you used. They might just run on every click event indiscriminately. So when you middle-click, which would normally spawn a new tab, SharePoint’s JavaScript says, “Hold on buddy—I’ll handle that,” and effectively does… nothing. Or worse, it tries to route the page inside your current tab, wrecking your expected flow.

Here’s a simple illustration for the coders in the back:

document.querySelectorAll('a').forEach(link => {
    link.addEventListener('click', e => {
        e.preventDefault();
        customNavigate(link.href);
    });
});

Looks innocent enough, right? But there’s no check here for e.button, which tells us if it was a left-click (0), middle-click (1), or right-click (2). The developer who wrote this probably never imagined someone would middle-click inside their beautiful React router. Meanwhile, devs like us are trying to open four site pages at once to verify JSON configurations, left fuming.

A Day in the Life: Why This Breaks Our Developer Groove

Let’s get a little more personal for a moment. I recently needed to open five different SharePoint Site Pages. My plan? Open the Pages library, middle-click each one, and let them spin up in background tabs while I sipped my coffee and basked in my own productivity.

Instead, the first middle-click brought up the dreaded scroll icon. The second did absolutely nothing. The third—by some arcane mystery—actually opened in a new tab. By the fourth, I was mashing my mouse like an angry teenager on a lagging Xbox controller. Not exactly the zen flow state we all chase.

This might sound trivial, but for developers, these micro-frustrations add up. We rely on predictability. The whole reason we use keyboard shortcuts, quick tabbing, multi-monitor setups, is to minimize friction. When a platform like SharePoint Modern Pages disrupts these expectations, it’s like a subtle productivity tax we pay over and over.

So Is This a Browser Problem or a SharePoint Problem?

Short answer: it’s squarely on SharePoint’s shoulders. Browsers like Chrome and Firefox go to great lengths to preserve default behaviors for middle-click. The W3C UI Events spec even explicitly states that default actions—like opening a link in a new tab—should only be canceled by JavaScript with explicit calls to preventDefault().

What’s happened here is that SharePoint Modern Pages, in their quest for smooth SPA (Single Page Application) transitions, grab every click they see. They override the browser’s built-in handling. In effect, SharePoint says: “Don’t worry, I’ve got this,” and then completely ignores your middle-click intention.

This is technically allowed by web standards. After all, developers can build whatever event logic they want. But just because you can override middle-click doesn’t mean you should. It’s the classic Spider-Man rule of web development: with great power comes great responsibility.

Trying Workarounds: Why They’re Never Quite Satisfying

Alright, so what do we do about it? Like most devs, I’ve tried everything. Right-click and select “Open Link in New Tab” works, but it’s slower and awkward when you’re deep in flow. Ctrl+click sometimes does the trick, because many JavaScript routers only look at direct clicks. But that’s hit or miss, depending on how the handlers were coded.

You could restructure your links. Some SharePoint architects recommend using external-style links or adding target="_blank" manually in certain web parts. That forces a new tab. But it’s inconsistent, and for things like Hero web parts or Quick Links designed to stay internal, it feels like duct-taping a solution.

Browser extensions offer another route. Tools that forcibly restore middle-click behavior by ignoring preventDefault() calls exist. They’re clever hacks, but come with their own maintenance headaches and potential security caveats—since they effectively override site scripts.

At the end of the day, none of these really restore that simple, bulletproof confidence we had when middle-click just… worked. And for developers, confidence in our tools is everything.

Why This Matters for Developer Productivity (and Sanity)

Some might call this a nitpick. But anyone who’s lived inside a SharePoint project for weeks—juggling multiple lists, libraries, Power Automate flows, JSON view formats—knows it’s the small things that pile up. Each time your hand does a familiar move and the software fails to respond, it’s a tiny crack in your mental focus. Multiply that by dozens of clicks a day, across hundreds of days, and it’s no wonder we all look slightly more haggard by year’s end.

Good developer UX isn’t just about flashy IDEs or auto-complete tricks. It’s respecting the basics: consistent scrolling, predictable tabbing, honoring native browser behaviors. When those break, it’s like building a race car but forgetting to tighten the lug nuts. Looks great on the surface. Try driving it at speed and see what happens.

What Microsoft Could Do (Hint: It’s Not Rocket Science)

The simplest fix? SharePoint Modern Pages should conditionally intercept clicks. Before calling preventDefault(), check if it was a left-click (e.button === 0) and if no modifier keys are pressed. That way, middle-clicks and Ctrl+clicks would pass through to the browser, behaving exactly as every dev expects.

Some SharePoint web parts already respect this, or offer a toggle for “Open in New Tab.” But it’s spotty, and inconsistent across different modules. Ideally, Microsoft would adopt a unified policy across all Modern Pages to let the browser handle middle-clicks by default unless the user explicitly chooses otherwise.

Lessons for All of Us Building Web Apps

This isn’t just a SharePoint gripe. It’s a cautionary tale for anyone building modern web apps. As developers, we wield powerful frameworks—React, Angular, Vue, you name it—that love to hijack routing for faster UX. But in doing so, we risk trampling on well-established user expectations.

Before wiring up that click event, pause and think: are you about to override something the browser already does well? Does your code account for middle-clicks, Ctrl+clicks, or long-press behavior on mobile? Or are you unintentionally rewriting decades of muscle memory?

Great web applications respect the fundamentals. They let the browser handle what it does best, only stepping in when there’s a clear improvement to be made.

Wrapping It Up (And Inviting You to Rant With Me)

So yeah—middle-click on SharePoint Modern Pages might seem like a tiny quirk on the surface. But dig a little deeper, and it reveals a fascinating intersection of developer ergonomics, JavaScript event systems, and the delicate balance of power between browsers and frameworks.

If you’ve ever found yourself jabbing your middle mouse button at a SharePoint link with growing annoyance—welcome to the club. You’re in good company. I’d love to hear your horror stories, clever hacks, or even your disagreements if you think I’m being too grumpy about it.

Drop a comment below, subscribe to our newsletter for more deep dives like this, or shoot me a message directly. Let’s keep pushing for better, saner developer experiences—because at the end of the day, we’ve all got enough to debug already without our browsers forgetting how to open a damn tab.

bdking71

Sources

Disclaimer:

The views and opinions expressed in this post are solely those of the author. The information provided is based on personal research, experience, and understanding of the subject matter at the time of writing. Readers should consult relevant experts or authorities for specific guidance related to their unique situations.