External links in Trac tickets should open in a new tab

[jdahir0789]

When contributors include external reference links in Trac tickets (e.g., links to GitHub, Stack Overflow, or WordPress.org pages), clicking them currently opens the link in the same browser tab. This causes contributors and reviewers to lose their place in the ticket they're viewing or editing.

Proposed Enhancement:

Update the behavior so that any external links included in ticket descriptions or comments open in a new browser tab (target="_blank"). This improves workflow and preserves context, especially for contributors navigating between multiple resources.

Benefits:

• Improved usability for contributors and reviewers
• Prevents accidental navigation away from Trac
• Aligns with modern UX practices

Steps to Reproduce:

1. Go to any existing Trac ticket (e.g., https://meta.trac.wordpress.org/ticket/5190)
2. Click on an external link in the ticket description or comments
3. The link opens in the same tab, navigating away from the ticket

Suggested Solution:

• Use JavaScript or modify the HTML rendering layer to detect external links and apply target="_blank"

[dd32]

In general, WordPress.org (all except certain specific places) allows the user to select where to open links - through utilising the browser open in new tab/window when the user wishes for that behaviour.

external reference links in Trac tickets (e.g., links to GitHub, Stack Overflow, or WordPress.org pages),

I'd argue that WordPress.org pages are not external links personally, although technically they could be seen as such. But would navigating from make.wordpress.org to wordpress.org/plugins also therefor be an external link?

Consistency is more important here.

Aligns with modern UX practices

That's arguable, Modern UX practices also aim to reduce confusion, which a new tab/window causes for many. It's generally accepted that it should be kept to the same window and leave the user in control of the behaviour they're wanting.

UX experts are very split on what is best here.

---

Personally, the status-quo is user-control, and as the audience for Trac is Developers (who are more familiar with browsers behaviour) I feel that we can be conservative here and rely upon the user to choose their behaviour.
Changing this would also cause significant divergence from the existing behaviour that many are used to, and then ultimately diverge from the default link format on other sites (such as make.wordpress.org).

[dd32]

Closing as per agreeance in #7976