Hyperlinks on Options page don't respond to middle-click

Add-ons Development
1

For IPvFoo v2.20, I added some plain old <a href> links to my extension’s Options page.

When running in Chrome, I’m able to open those links in a background tab using middle-click or ctrl-click, but in Firefox only left-click responds. I generally get annoyed when interacting with links that don’t behave like links, so is anyone aware of a workaround?

Edit: I reported a bug here: 1946972 - Can't middle-click hyperlinks from an extension's options_ui page.

2

The default options page opened in the browser “container” inside about:addons is just pure hell :smiley: , it’s full of strange issues / bugs / unexpected behaviors…
One example for all:

I would highly recommend not using it :slight_smile:
For example, all you need to do is change this in the manifest file:

  "options_ui": {
    "page": "popup/popup.html",
    "open_in_tab": true
  },

Plus tweak the CSS a bit since options page will be now on a much bigger page.

Alternatively, you could detect middle click (onauxclick) and stop default action and then use browser.tabs.create API to create the tab manually.

1 Like
3

Alternatively, you could detect middle click (onauxclick)

// existing code:
const a = document.createElement("a");
a.href = `https://${domain}`;
a.target = "_blank";
a.textContent = domain;
// added this as an experiment:
a.addEventListener("auxclick", (event) => {
  if (event.button == 1) {
    window.open(a.href);
  }
});

Interesting, the above auxclick handler seems like a sufficient workaround. So even though Firefox is not handling middle-click correctly, it still fires auxclick and sends window.open() to a background tab.

Note that I haven’t tried to fix Ctrl-click, or the Mac OS equivalent.

"open_in_tab": true

I don’t like this, because it makes the Options page nearly impossible to find.

4

If I do this, Firefox appears to work perfectly (middle-click or ctrl-click opens a background tab, shift-click opens a new window):

a.addEventListener("auxclick", (event) => {
  if (event.button == 1) {
    window.open(a.href);
    event.preventDefault();
  }
});
a.addEventListener("click", (event) => {
  if (event.ctrlKey || event.metaKey || event.shiftKey) {
    window.open(a.href);
    event.preventDefault();
  }
});

But running the same code in Chrome, window.open ignores the modifiers and always opens a new active tab. If I view the Options page in its own tab instead of under chrome://extensions, the links behave correctly.

So I think the ideal workaround is to run the above code in Firefox only.

Sigh, I can’t believe it’s 2025 and still feels like coding for IE vs. Netscape.

1 Like
5

Personally, I’d recommend against directly linking to other pages in your extension from the options page because navigating that frame is conceptually weird. In general, the options page allows users to interact with a statically defined set of controls. Interactions might change their state or visibility, but they don’t generally move you to a completely different page. If you do want to link to other pages, it might be best to default to setting target="_blank" on the anchor tags. End of strong personal opinion.

If you’re set on linking to other pages, you might want to replace window.open() in your event handler with browser.tabs.create() as the latter will always create a new tab. As you’ve seen, windows.open() suffers from inconsistent behavior across browsers and contexts. In Firefox, the embedded version of the options page doesn’t have navigation controls, so the user can’t go back after clicking a link.

1 Like