starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Remove ability to force a custom link to open in a new window/tab #7481

New Issue
Closed
opened 2025-12-29 20:23:54 +01:00 by adam · 9 comments
adam commented 2025-12-29 20:23:54 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Jan 9, 2023).

NetBox version

v3.4.2

Feature type

Change to existing functionality

Proposed functionality

Remove the new_window boolean field from the CustomLink model, and do not modify the default behavior of rendered links.

Use case

By default, the user has the option of letting a link open in the current tab/window or (using ctrl/chift-click) a new one. Forcing the link to open in a new tab/window should be considered poor practice as it removes this choice from the user. It also raises concerns around ensuring accessibility for those using screen readers.

Here is some additional justification and discussion for why forcing links to open in a new tab should be avoided.

Database changes

No response

External dependencies

No response

Originally created by @jeremystretch on GitHub (Jan 9, 2023). ### NetBox version v3.4.2 ### Feature type Change to existing functionality ### Proposed functionality Remove the `new_window` boolean field from the CustomLink model, and do not modify the default behavior of rendered links. ### Use case By default, the user has the option of letting a link open in the current tab/window or (using ctrl/chift-click) a new one. Forcing the link to open in a new tab/window should be considered poor practice as it removes this choice from the user. It also raises concerns around ensuring accessibility for those using screen readers. Here is some [additional justification and discussion](https://diversity.wustl.edu/framework/advisory-best-practice-groups/website-accessibility/links-opening-new-tabs/) for why forcing links to open in a new tab should be avoided. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: under review labels 2025-12-29 20:23:54 +01:00
adam closed this issue 2025-12-29 20:23:54 +01:00
adam commented 2025-12-29 20:23:55 +01:00
Author
Owner
Copy Link

@stavr666 commented on GitHub (Jan 9, 2023):

NB in not public service, but IT-only. In most cases for NetBox:

  • users can contact directly with server owner/admin;
  • admins IS most active users of service.

Thus, I believe that the above arguments do not apply to NetBox (also, how many "those using screen readers" among NB users?).

For me, personally, holding CTRL to force open management links in new window (keeping pinned NB tab on it's place), instead of using current customizable functionality - is step back in usability.

As alternative, user-level option to override links behavior will work better, than system-wide removal of toggle.

@stavr666 commented on GitHub (Jan 9, 2023): NB in not public service, but IT-only. In most cases for NetBox: - users can contact directly with server owner/admin; - admins IS most active users of service. Thus, I believe that the above arguments do not apply to NetBox (also, how many "those using screen readers" among NB users?). For me, personally, holding CTRL to force open management links in new window (keeping pinned NB tab on it's place), instead of using current customizable functionality - is step back in usability. As alternative, user-level option to override links behavior will work better, than system-wide removal of toggle.
adam commented 2025-12-29 20:23:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 9, 2023):

how many "those using screen readers" among NB users?

One is enough.

As alternative, user-level option to override links behavior will work better, than system-wide removal of toggle.

What you're describing is the default browser behavior.

@jeremystretch commented on GitHub (Jan 9, 2023): > how many "those using screen readers" among NB users? One is enough. > As alternative, user-level option to override links behavior will work better, than system-wide removal of toggle. What you're describing is the default browser behavior.
adam commented 2025-12-29 20:23:55 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Jan 9, 2023):

Per the linked diversity and inclusion webpage
It is possible to force links to open in new tabs if you provide a notification method in addition to visual cues, such as typing inside the link text a cue like, “(opens in new tab).”
This solves the issue for screenreaders as the cue on the url can have a message warning of the new tab.

An additional safety could be a user preference to always open links in current context. that way for specific users could override that functionality if needed

@ITJamie commented on GitHub (Jan 9, 2023): Per the linked diversity and inclusion webpage `It is possible to force links to open in new tabs if you provide a notification method in addition to visual cues, such as typing inside the link text a cue like, “(opens in new tab).”` This solves the issue for screenreaders as the cue on the url can have a message warning of the new tab. An additional safety could be a user preference to always open links in current context. that way for specific users could override that functionality if needed
adam commented 2025-12-29 20:23:56 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jan 10, 2023):

I agree with the comments from both @stavr666 and @ITJamie. My user base seems to have a strong preference for external links to always open in a new tab and often get caught out when they don't, especially if they lose any state in the originating application. A lot of the users are not particularly tech savvy and don't understand that they can ctrl+click or middle click to perform that action as a one-off. It's also something that they have gotten used to in NetBox at this point, so I expect that removing that functionality is going to generate a lot of tickets in our app support queue, regardless of how much we communicate the change or provide training beforehand. I am a huge proponent of accessibility, but I think that can be accomplished by setting aria-label on links or, my personal preference, including an icon with mdi-open-in-new and an appropriate alt attribute on links that are set to open in a new window/tab. Including a user preference to override the new_window value would also be great.

I had to deal with a lot of fallout with the change that reversed the layout of all the create/save buttons and changed the default from Create & Add Another to just Create (#9437), which caught a number of people out (myself included). I ultimately had to add a local style override to put the buttons in a flex container with flex-direction: row-reverse to keep everyone from clicking Cancel all the time. I would love to see more things that create a significant impact on existing user experience turned into user preferences. It could also be paired with setting an application-level default preference to support workflows for users to either opt in to the new functionality or opt out of it, when it's enabled application-wide. That would also allow for a simpler upgrade process to be able to upgrade for added functionality and roll out the UX changes asynchronously.

@sleepinggenius2 commented on GitHub (Jan 10, 2023): I agree with the comments from both @stavr666 and @ITJamie. My user base seems to have a strong preference for external links to **always** open in a new tab and often get caught out when they don't, especially if they lose any state in the originating application. A lot of the users are not particularly tech savvy and don't understand that they can ctrl+click or middle click to perform that action as a one-off. It's also something that they have gotten used to in NetBox at this point, so I expect that removing that functionality is going to generate a lot of tickets in our app support queue, regardless of how much we communicate the change or provide training beforehand. I am a huge proponent of accessibility, but I think that can be accomplished by setting `aria-label` on links or, my personal preference, including an icon with `mdi-open-in-new` and an appropriate `alt` attribute on links that are set to open in a new window/tab. Including a user preference to override the `new_window` value would also be great. I had to deal with a lot of fallout with the change that reversed the layout of all the create/save buttons and changed the default from *Create & Add Another* to just *Create* (#9437), which caught a number of people out (myself included). I ultimately had to add a local style override to put the buttons in a flex container with `flex-direction: row-reverse` to keep everyone from clicking Cancel all the time. I would love to see more things that create a significant impact on existing user experience turned into user preferences. It could also be paired with setting an application-level default preference to support workflows for users to either opt in to the new functionality or opt out of it, when it's enabled application-wide. That would also allow for a simpler upgrade process to be able to upgrade for added functionality and roll out the UX changes asynchronously.
adam commented 2025-12-29 20:23:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 10, 2023):

A lot of the users are not particularly tech savvy and don't understand that they can ctrl+click or middle click to perform that action as a one-off.

This is solvable via user education, and IMO not sufficient justification for governing design decisions, particularly for an application acutely targeted to IT professionals.

Including a user preference to override the new_window value would also be great.

This is exactly the browser's default behavior, and what we want to achieve by removing the forced override.

By the way, we've already had a very similar conversation regarding links to devices in rack elevations, wherein there was a strong consensus that links should not force a new tab.

@jeremystretch commented on GitHub (Jan 10, 2023): > A lot of the users are not particularly tech savvy and don't understand that they can ctrl+click or middle click to perform that action as a one-off. This is solvable via user education, and IMO not sufficient justification for governing design decisions, particularly for an application acutely targeted to IT professionals. > Including a user preference to override the new_window value would also be great. This is exactly the browser's default behavior, and what we want to achieve by _removing_ the forced override. By the way, we've already had a very similar conversation regarding links to devices in rack elevations, wherein there was a strong consensus that links should **not** force a new tab.
adam commented 2025-12-29 20:23:56 +01:00
Author
Owner
Copy Link

@ShellBoyAFK commented on GitHub (Jan 10, 2023):

I've come up with a set of rules that describe our reactions to technologies:

  1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
  2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
  3. Anything invented after you're thirty-five is against the natural order of things.

Most of my NB User are over thirty-five......

@ShellBoyAFK commented on GitHub (Jan 10, 2023): > I've come up with a set of rules that describe our reactions to technologies: > 1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. > 2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. > 3. Anything invented after you're thirty-five is against the natural order of things. Most of my NB User are over thirty-five......
adam commented 2025-12-29 20:23:57 +01:00
Author
Owner
Copy Link

@stavr666 commented on GitHub (Jan 10, 2023):

we've already had a very similar conversation regarding links to devices in rack elevations

It can't be "same" conversation. With racks, by clicking link you keep user inside NB app.
With custom link you (always?) leading user outside of NB app.

For me, it's PWA logic vs Search Engine logic:

  • as long as you not changing site, by default you clicks will keep you on single tab;
  • as long as you leaving app-related site, by default your clicks will open new tab.

This is how (modern, familiar with mobile phones and tablets) users expect to interact. That's how I try to deliver our monitoring, managements and other infrastructure-related tools behavior.

Overriding it can be done at browser-level (are you sure it's not the extension? didn't find the override in Chrome/Edge settings/flags, middle-click and CTLR-click not equals overriding default clicks, imo), but like you described in motivation post, giving user more control is better then removing it. Thus, per-app customization (in User Preferences) is better, than "set it for all", similar to regional settings (date-time format not universal, have context like export, sorting, level of details etc.)

@stavr666 commented on GitHub (Jan 10, 2023): > we've already had a very similar conversation regarding links to devices in rack elevations It can't be "same" conversation. With racks, by clicking link you keep user inside NB app. With custom link you (always?) leading user outside of NB app. For me, it's PWA logic vs Search Engine logic: - as long as you not changing site, by default you clicks will keep you on single tab; - as long as you leaving app-related site, by default your clicks will open new tab. This is how (modern, familiar with mobile phones and tablets) users expect to interact. That's how I try to deliver our monitoring, managements and other infrastructure-related tools behavior. Overriding it **can** be done at browser-level (are you sure it's not the extension? didn't find the override in Chrome/Edge settings/flags, middle-click and CTLR-click not equals overriding default clicks, imo), but like you described in motivation post, giving user more control is better then removing it. Thus, per-app customization (in User Preferences) is better, than "set it for all", similar to regional settings (date-time format not universal, have context like export, sorting, level of details etc.)
adam commented 2025-12-29 20:23:57 +01:00
Author
Owner
Copy Link

@ShellBoyAFK commented on GitHub (Jan 10, 2023):

For me, it's PWA logic vs Search Engine logic:

as long as you not changing site, by default you clicks will keep you on single tab;
as long as you leaving app-related site, by default your clicks will open new tab.

me too

@ShellBoyAFK commented on GitHub (Jan 10, 2023): > For me, it's PWA logic vs Search Engine logic: > > as long as you not changing site, by default you clicks will keep you on single tab; > as long as you leaving app-related site, by default your clicks will open new tab. me too
adam commented 2025-12-29 20:23:58 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 10, 2023):

Alright, there's clearly enough opposition to this proposal that it's not worth discussing any further. We'll leave it as-is.

@jeremystretch commented on GitHub (Jan 10, 2023): Alright, there's clearly enough opposition to this proposal that it's not worth discussing any further. We'll leave it as-is.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: under review type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#7481
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?